Events and sync

A platform that keeps its own copy of your records (Palantir Foundry, Data 360, a warehouse, your own system) keeps it in step with Cypress in four parts. Each uses what the API already offers; the records, their ids and their links are in Domain model.

1. Backfill

Read each list once, page by page (limit up to 100, then nextHref). Record the time you started: the next step begins there.

GET /api/v1/vehicles?limit=100
GET /api/v1/listings?limit=100
GET /api/v1/offers?limit=100
GET /api/v1/closings?limit=100
GET /api/v1/contacts?limit=100
GET /api/v1/businesses?limit=100
GET /api/v1/deals?limit=100
GET /api/v1/tasks?limit=100

Keep each record by its id, and by your own ids (externalIds) where it has them.

2. Follow every change

Every change is an event, whoever made it: a person in the app, an agent, an automation, an import. Hear them one of two ways, or both:

• Pushed, by webhook: Cypress posts each event to your address, signed, and retries for a while if your address is down.
• Pulled, from the event log: GET /api/v1/events?after=<cursor> answers the events since a cursor, oldest first, kept for 30 days. Page with nextCursor while hasMore is true. Use it if your platform cannot take webhooks, and to catch up after downtime either way. Since 1.9.0 the opt-in plan, buy-plan and insight events are in the log even when no subscription lists them.

On each event:

• Dedupe on cursor. A retry or a replay carries the same one.
• Order by cursor. It grows with every event; deliveries can arrive out of order.
• Read href for the latest state. An event's body is the record when it was delivered; href always serves it now.
• Follow relatedResources for the records it touched beside its own (a sale's vehicle and listing).

A subscription can list entityIds to hear about some records only, and POST /api/v1/webhooks/subscriptions/{id}/replay delivers the log again from a cursor. Some event families are opt-in, each on its read scope; the Webhooks page lists them.

3. Reconcile

Now and then, ask each list for what changed since your last reconcile, to mend anything your copy missed:

GET /api/v1/vehicles?updatedAfter=2026-10-18T06:00:00Z

updatedAfter answers the records changed at or after that time, the newest change first, on vehicles, listings, offers, closings, contacts, companies, deals and tasks. A record that changes while you page moves to the first page, which you have read already: start each reconcile from the time the previous one began, so the next pass reads it. Others may come twice: keep records by id.

4. Mirror what waits for a person

Mission Control is the list of what needs a person now: offers to answer, closings waiting on your side, listings and valuations to look at, billing, campaigns and CRM tasks. GET /api/v1/mission-control (read_mission_control over MCP) reads it, each item with its links.app. A platform with a review queue of its own can show these items there; the decision is still made in Cypress, at the link.

When an agent asks for a decision Cypress keeps for a person (a price below the floor, approving a quarter, an email in your organization's name), it gets NEEDS_PERSON with a decisionLink instead of an error, and nothing is added to Mission Control by itself. The agent hands the link to a person, best as a task with a due day (log with kind: task and dueDate): an open task shows in Mission Control from its due day. See What an agent can and cannot do.

Scopes

Reading the event log and managing subscriptions take the webhooks scope; each list takes its area's read scope (vehicles, listings, offers:read, closing:read, crm:read, tasks:read); Mission Control takes mission-control:read. The events of planning, buy planning, tasks and the other opt-in families are in the log only for a credential that may read them. See Key scopes.