Sending and pulling files over SFTP

For systems that exchange files rather than calling an API, HousingSurvey Pro connects out to a server your team already runs — it never listens for inbound connections itself.

What it is

SFTP lets HousingSurvey Pro send files to your server — EDI exports, survey and works-completed PDFs, resident letters, invoices, your tenancy register — and pull specific data types from your server: property/UPRN stock, Schedule of Rates schedules, and tenancy records. You stay in control of the server throughout; there’s nothing to install beyond adding one public key, or a password, to an account you already manage. This is a Platform-tier feature.

Before you start

Configuring a server requires organisation-admin access to Settings, and an SFTP account your organisation already controls.

How to do it

1. Open Settings → SFTP servers → Add server and enter the host, port, username and remote path.
2. Choose authentication: an SSH key (recommended) or a password, or both. For a key, click Mint key — the public half is shown once, with the exact line to add to your server’s authorized_keys; the private key stays on HousingSurvey Pro’s backend and is never shown again.
3. Click Test connection to run a real handshake and a read-only check of the remote path — it never writes a file. On the first successful test, confirm the shown host-key fingerprint matches what your IT team expects, then pin it.
4. To send files, use the Send to SFTP option that appears next to survey reports, works-completed records, resident letters and invoices, or configure the nightly EDI export to deliver automatically.
5. To pull data in, open a server’s Inbound imports, set a folder path for the data type you want, and click Pull now — this only previews what would happen. Review the preview, then Confirm to write the import; the files are re-checked for changes before anything is written.

How it integrates

Once a fingerprint is pinned, any future connection presenting a different host key is refused until a human re-confirms it — this catches both a legitimate re-key and a compromised connection, and treats both the same way. Every outbound file is written to a temporary, hidden name first, then renamed into its final filename, so nothing downstream ever sees a partially written file. Inbound imports are CSV only, reuse the same validation as their manual-upload equivalents, and are always a manual pull — there is no scheduled automatic import. Every test, delivery and pull is logged to your organisation’s SFTP activity feed.

Common problems

• Test connection fails at the handshake step with a fingerprint mismatch. Your server presented a different host key than the one previously pinned — verify the new fingerprint with your IT team out of band before re-pinning; never re-pin on trust alone.
• Test connection fails at the authentication step. The username or password is wrong, or the public key isn’t installed (or was removed) from the server account’s authorized_keys.
• An inbound row didn’t import. A row that can’t be matched to an existing property or tenancy is flagged for manual review rather than silently dropped or guessed at.