Isolated Test Mode

Isolated Test Mode lets you dry-run your write integration against your real connected data. Reads with a ps_test_ key return the same data your ps_live_ key would. Writes are validated exactly like production — same validation, same error shapes — then return a mocked success response and are never processed or delivered to your integrations or any downstream destination. Nothing real is mutated.

"Isolated" refers to write effects being sealed off, not to the data being different. Test mode and live mode hit the same host, the same endpoints, and the same real connected data. The only difference is the key prefix and whether writes take effect.

Keys and base URL

Both key types authenticate against the same host, https://api.propsocket.io/v1. The mode is carried by the key prefix, not the URL:

Key prefixReadsWrites
ps_test_Real connected dataValidated, mocked success, never delivered
ps_live_Real connected dataValidated and committed to your integrations

Getting a test key

A ps_test_ key is scoped to your Organization and reads the data from your connected integrations, so test mode is useful once you have a live integration. Issue or rotate keys fromDashboard → Settings → API keys; the prefix tells you which mode a key is in. Test mode is included on the trial and all paid tiers.

Store the key in an environment variable and point your client at the single base URL:

.env.example
# .env.example for a test-mode app
PROPSOCKET_BASE_URL=https://api.propsocket.io/v1
PROPSOCKET_API_KEY=ps_test_YOUR_TEST_KEY
PROPSOCKET_SIGNING_SECRET=whsec_YOUR_SIGNING_SECRET

Smoke-test the key with a read — it returns your real connected data:

GET /v1/properties
curl https://api.propsocket.io/v1/properties \
  -H "Authorization: Bearer ps_test_YOUR_TEST_KEY"

Dry-running writes

Send a write with a ps_test_ key and PropSocket runs the same validation pipeline it runs in production. A valid request returns a mocked success response in the normal envelope; the operation is never queued, processed, or delivered to your integrations. An invalid request returns the same error shape you would get in live mode, so you can exercise both the happy path and your error handling without mutating anything.

POST /v1/leases (dry-run)
# A write with a ps_test_ key: validated like production,
# returns a mocked success, never delivered to your integrations.
curl -X POST https://api.propsocket.io/v1/leases \
  -H "Authorization: Bearer ps_test_YOUR_TEST_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "unit_id": "unt_01HX0G5T8N3KEWBYV2QMR4DCFA", "start_date": "2026-07-01" }'

Because validation and error shapes match production exactly, a request that succeeds in test mode is the same request that would commit in live mode — swap ps_test_ forps_live_ and nothing else changes.

Test mode vs. live

There is exactly one behavioral difference. Everything else — host, endpoints, response envelope, error shapes, reads, and rate limits — is identical.

AspectTest modeLive
WritesValidated, mocked success, never delivered (dry-run)Validated and committed to your integrations
ReadsIdentical — real connected data either way
Hostapi.propsocket.io
Endpoints, envelope, error shapesIdentical
Rate limit150 req/min per Organization

Next

Run the five-step quickstart with your ps_test_ key, or read the Common Data Model overview to know what the data you read looks like.