Glossary

Words we use,
defined plainly.

PropTech has its own dialect, and so does PropSocket. Below: the terms that show up in our docs, our payloads, and our pricing — with no jargon-on-jargon. Each entry is one to three sentences and links inward to where the term actually matters.

Jump to a term

PMS — Property Management System
The system of record
The application a property manager uses day-to-day to run leases, residents, charges, and work orders. Entrata, Yardi, RealPage, and AppFolio are the four big ones. A PMS is the first kind of source PropSocket connects to — it reads from one and normalizes what it finds into a single schema.
#pms
CDM — Common Data Model
One schema across every source
PropSocket's normalized representation of your source data: Property, Unit, Resident, Lease, LeaseResident. Every connector — Entrata today, Yardi/RealPage/AppFolio next — maps into the same CDM, so your integration code looks the same across sources.
#cdm
Sync cadence
How often we pull
How often PropSocket's sync engine polls a connected source for changes. Tier-controlled: a daily sync on Starter, then customizable — up to every 4 hours on Growth, every hour on Scale, and every 15 minutes on Enterprise. Webhooks fire within the cadence as changes are detected.
#sync-cadence
Webhook
A push instead of a pull
An HTTP POST PropSocket sends to a URL you control the moment the sync engine sees a data change. Instead of polling for "what changed?", your endpoint gets told. Webhooks are available on the Scale plan and above. See the full event catalog on the webhooks page.
#webhook
Signed webhook
A webhook you can authenticate
A webhook whose body is cryptographically signed so you can verify it actually came from PropSocket and wasn't tampered with in transit. PropSocket signs every webhook with HMAC-SHA256 and ships the digest in X-PropSocket-Signature. Webhooks are a Scale-plan-and-above feature.
#signed-webhook
HMAC-SHA256 signature verification
How to trust a webhook
A keyed-hash message authentication code using SHA-256. You compute HMAC-SHA256 over the raw request body with your signing secret, then constant-time compare against the value in X-PropSocket-Signature. If they match, the webhook is authentic. Webhooks are a Scale-plan-and-above feature. Code samples on the webhooks page.
#hmac-sha256
Soft delete / deleted_at
We never physically remove rows
When a connected source removes a record, PropSocket sets the record's deleted_at timestamp instead of deleting the row. List endpoints exclude soft-deleted rows by default — pass ?include_deleted=true to see them. This keeps historical analytics coherent and audit trails complete.
#soft-delete
Idempotency key
Safe to retry
A unique identifier you attach to a request so it can be safely retried without performing the side-effect twice. PropSocket's webhooks carry an id (ULID, prefixed evt_) you can use as the idempotency key in your handler — store processed IDs and short-circuit on repeats.
#idempotency-key
Pagination envelope
PropSocket's { meta, results } shape
Every list endpoint responds with {"meta": {"limit", "offset", "hasMore"}, "results": [...]}. Offset-based pagination, default limit=25, max 100. Sorting via ?order-by=field:asc|desc.
#pagination-envelope
Money as integer cents
No float drift
Every money value in the CDM is an integer count of the smallest currency unit paired with a currency field. {"amount": 125000, "currency": "USD"} means $1,250.00. We never store money as a float — rounding drift in financial fields is a silent corruption you don't want.
#money-as-cents
x_id
The external source identifier
Every CDM record carries an x_id field holding the identifier the source system uses for that record (e.g., "entrata-resident-44218"). Use it to cross-reference back to the source, to deduplicate against legacy systems, or to build idempotent upserts from PropSocket into your own database.
#x-id
ILS — Internet Listing Service
A multifamily marketplace
A consumer-facing rental marketplace — Apartments.com, Zillow Rentals, and the like — that aggregates availability and pricing from many operators. ILSes are one of three audiences PropSocket is explicitly built for; see use cases for the fit and non-fit cases.
#ils
ETL (in PropTech context)
Extract, Transform, Load
The classic data-pipeline pattern: pull data out of the source, reshape it, land it in a destination. PropSocket handles the "extract" (from the source) and a large chunk of "transform" (normalize into the CDM). What you do with the resulting clean data — load it into a warehouse, push it to a downstream service — is up to you.
#etl
Integration / Connector
One source connection, scoped to one org
In PropSocket, an Integration is a single configured connection from an Organization (a PropSocket customer) to a specific source system — today, a PMS instance such as one Entrata tenant. The Connector is the per-source code that knows how to talk to that system. One Connector serves many Integrations; the source type lives on Integration.pms_type.
#integration
Organization
The multi-tenancy boundary
The top-level tenancy unit in PropSocket. Every row in every CDM table is scoped to an organization_id, and every API request runs in the context of exactly one Organization. Cross-org access is not a configuration option — it doesn't exist.
#organization
Test key vs. live key
ps_test_ and ps_live_
Both keys authenticate against the same production host and read your real connected data. A test key (prefixed ps_test_) gives you real reads plus dry-run writes: writes are validated exactly like production and return a mocked success response, but nothing is delivered downstream. A live key (prefixed ps_live_) reads and writes both commit. Same data — the only difference is whether writes take effect. See Isolated Test Mode.
#sandbox-vs-live

Set up your first integration this week.

Vocabulary checked. Time to wire it up. Start the 30-day free trial — talk to the engineers, not a funnel.