Migrating from a raw Entrata integration

You built directly against Entrata's JSON-RPC API, and you're tired of it — the method/version envelopes (r1 vs r2), the responses where a single record comes back as an object but many come back as an array, the per-property calls, the hand-rolled retry and pagination. This guide maps Entrata's surface to PropSocket's REST API, then itemizes the code you get to delete. PropSocket runs the connector so you consume one normalized REST shape instead of Entrata's native one.

Endpoint mapping

PropSocket's Entrata connector reads each entity from Entrata and normalizes it into the CDM. Your code stops calling Entrata and calls one PropSocket REST endpoint per entity instead.

Entrata entity	Entrata JSON-RPC method	PropSocket REST	Normalization
Property / Community	getProperties POST /v1/properties	GET /v1/properties	native multi-building flattened into the `type` enum
Unit	getPropertyUnits POST /v1/propertyunits	GET /v1/units	floor plans arrive inside the `getPropertyUnits` response; resolved and folded onto the unit during mapping
Resident / Tenant	getCustomers POST /v1/customers	GET /v1/residents	contact/demographic fields mapped directly; extras to `custom_data`
Lease	getLeases (r2) POST /v1/leases	GET /v1/leases	multi-resident leases; resident associations resolved into PropSocket ids

Entrata is a JSON-RPC API — every call is a POST to a service endpoint with a { method: { name, version, params } } body — and it authenticates with a single API key (no Basic auth, no session or token refresh). Reads resolve to getAccessibleServices for discovery, then the four get*methods above. If you also write back to Entrata, those methods collapse the same way: updateCustomers and updateLease /updateScheduledCharges (r2) for edits, sendLeases andsendPropertyUnits to create — each becomes one PropSocket write instead of a hand-built RPC envelope.

Entrata quirks PropSocket absorbs

Money. Entrata's financial fields land as integer minor units plus a currency ({ "amount": 285000, "currency": "USD" }) — no float parsing, no rounding drift on your side.
Identifiers. Entrata's native ids are preserved as x_id (a string) alongside PropSocket's own prefixed-ULID id. Keep joining onx_id if your downstream already keys on Entrata ids.
Floor plans. Separate entities in Entrata; resolved during mapping so unit records carry their floor-plan attributes directly.
Deletes. A record that disappears from Entrata is soft-deleted, not dropped —deleted_at goes non-null and the record stays queryable with?include_deleted=true.
Non-standard fields. Anything Entrata returns that doesn't map to a CDM field is preserved under custom_data rather than discarded.

What you can delete from your codebase

The point of switching is the code you stop maintaining:

You were maintaining	Now
JSON-RPC envelope construction + version (r1/r2) juggling + single-vs-array response coercion	flat JSON over REST
Entrata API-key auth threaded through every RPC call	one bearer token, env-scoped
Hand-rolled retry/backoff against Entrata's per-service rate limits	PropSocket runs the connector; you honor one `Retry-After`
Per-property fan-out (one call per property for units/residents/leases)	one offset envelope with `hasMore`
Polling on a cron to detect changes	signed webhooks on change
Floor-plan join logic, money-type coercion, id reconciliation	normalized in the CDM

What you keep: your business logic. The deserialization, transport, and freshness plumbing is what moves to PropSocket.

One thing that doesn't change: it's a cache

You're no longer hitting Entrata in real time — you're reading PropSocket's normalized cache, refreshed on your tier's sync cadence (4 hours down to 5 minutes). If your raw integration relied on synchronous, on-demand reads straight from Entrata, redesign around the cache plus webhooks: react to *_UPDATED events instead of polling. Thearchitecture overview spells out the freshness model.

Cutover playbook

Dual-read. Stand up PropSocket reads next to your existing Entrata reads. Run apaginated backfill into a shadow store.
Validate the mapping. Diff the shadow store against your Entrata-sourced data, entity by entity. Watch money (integer vs float), ids (x_id vs id), and enum casing — those are where raw-Entrata code most often disagrees with the CDM.
Add webhooks. Subscribe, verify signatures, anddedupe on the event id. Replace your polling cron. Webhooks are on the Scale plan and above; on Starter or Growth, keep polling the API (pricing).
Switch reads, then cut the RPC client. Flip the read path to PropSocket once the shadow data agrees, then delete the Entrata JSON-RPC client, auth, retry, and per-property fan-out code.

To start the dual-read in 15 minutes, run the quickstart.