Skip to main content
The /api/v1/sync/changes endpoint returns a ordered list of change events that occurred in a dataset after the point represented by a since cursor. This is the second half of the two-phase sync pattern: you call /api/v1/sync/snapshot once to load all current records and obtain an initial cursor, then poll /api/v1/sync/changes on a schedule to apply only the rows that have been inserted, updated, or deleted since your last poll. Each response includes a latest_cursor — replace your stored cursor with this value after every successful call so your next request picks up exactly where this one left off. Each change object carries an operation field (upsert, delete, or supersede) and a payload containing the full new record state for upserts. For deletions, payload is null and you should remove the record identified by record_id from your local store.

Request

Authentication

All requests must include your API key in the x-api-key header. The required access tier matches that of the corresponding snapshot endpoint for the requested dataset.

Query Parameters

string
required
The dataset to fetch changes for. Must be one of the valid dataset keys:finance_fees, finance_products, finance_eligibility, equipment_pricing, utility_territory, electricity_rates, hvac_incentives, hvac_climate, hvac_labor, hvac_ahri_matches.See Sync Snapshot for full dataset descriptions.
string
required
Cursor string from a previous snapshot or changes response. Use sync.cursor from a snapshot response or latest_cursor from a previous changes response. If you do not have a cursor yet, call /api/v1/sync/snapshot first to obtain one. Passing an invalid or expired cursor returns a 400 error.
string
Optional trade filter. When provided, only change events for that trade category are returned. Must be one of solar, hvac, roofing, plumbing, or electrical. Should match the trade filter you used when taking the original snapshot.
integer
Maximum number of change records to return per page. The ceiling varies by dataset. When the response sync.has_more is true, follow sync.next_url to retrieve the next page of changes before advancing your cursor.

Change Operations

Each item in the changes array carries an operation field that tells you how to apply it to your local dataset:
Always persist latest_cursor to durable storage before applying changes to your database. If your application crashes mid-apply and you have already advanced the cursor, you will miss those change events. A safe pattern is: store latest_cursor → apply changes in a transaction → commit. On restart, re-fetch changes from the stored cursor; the API is idempotent for the same cursor window.

Response

object
Top-level data envelope containing the delta payload.

Examples

Response — changes present

Response — no changes



Next Steps

  • Start here: take a full snapshot with Sync Snapshot to get your initial cursor and records.
  • Use the sync.changes_url from the snapshot response as your first changes URL — it’s already URL-encoded with the correct cursor.