Isolated Test Mode · Included on every plan
Swap a ps_live_key for a ps_test_key and dry-run every write. Reads return your real connected data. Writes validate exactly like production — same checks, same error shapes — then get a mocked success response and are never delivered to your integrations. Nothing downstream changes.
How it works
Test mode isn't a separate environment. Aps_test_key authenticates against the same api.propsocket.ioas your live key and reads your real connected data. The only thing "isolated" is the effect of a write: it gets validated, then stops before it can change anything real.
Step 01
Send your request with a ps_test_key instead of ps_live_. Same base URL, same endpoints, same auth header. No new environment to stand up.
Step 02
Your payload runs the exact production validation path. A bad field gets the same 422 you'd get live, with the same error shape. If the call would fail in production, it fails here too.
Step 03
A valid write returns a mocked success response so your client code sees the full happy path — but the operation is never delivered to your integrations or any downstream destination. It mutates nothing.
Reads vs. writes
This is the whole model. Reads behave exactly as they do live; writes look and validate exactly like live but stop short of taking effect.
Reads
A GET with a test key returns exactly what a live key would — the same Property, Unit, Resident, Lease, and LeaseResident records from your connected integration. Nothing is mocked, nothing is fabricated. Page, filter, and diff against the data you actually run on.
Writes
A POST,PATCH, orDELETE runs the full production validation, returns the same error shapes on failure and a mocked success on pass — and then stops. Nothing reaches your PMS or any downstream destination.
Use it for
Anywhere you'd want to exercise a write path against real data without the risk of mutating it.
Wire up your create and update flows against real records and real validation before a single write ever reaches your PMS. Catch the 422s on your machine, not in production.
Point your staging environment and integration tests at aps_test_ key. Your suite hits real reads and exercises real write validation on every run, with zero chance of a test mutating your PMS.
Before flipping a risky write to live, send it with a test key first. If it validates clean here, it'll validate clean in production — same path, same rules.
Hand a new teammate a test key and let them work against the real API end to end. They learn the write contract for real, and nothing they send can touch your PMS.
The only difference
Test and live keys hit the same host, the same data, and the same code paths. The single difference: with a live key, writes commit; with a test key, writes dry-run.
ps_test_ | ps_live_ | |
|---|---|---|
| Host | api.propsocket.io | api.propsocket.io |
| Reads | Your real connected data | Your real connected data |
| Write validation | Full production path, same error shapes | Full production path, same error shapes |
| Write effect | Mocked success, never delivered | Committed and delivered downstream |
Test mode is included on the Starter free trial and every paid tier. It needs a connected integration to read from — that's what makes the dry-runs meaningful.
Start the Starter free trial, connect an integration, then dry-run every write against real data with a ps_test_key. Talk to the engineers, not a funnel — we reply within one business day.