Skip to main content

Pull API

If your system can't call ours, expose one read endpoint and we fetch on a schedule (every 30 minutes by default).

You build​

  • One cursor-paged GET endpoint (below)
  • An auth header you tell us at onboarding

We provide​

  • The scheduled fetcher with durable cursors and retries
  • Everything downstream identical to push (dedupe, webhooks, …)

The contract you implement​

GET <your-url>?cursor=<opaque>&limit=<n>
Authorization: <your auth header, stored encrypted on our side>

→ 200 {
  "rows": [ /* case rows — same shape as the push API */ ],
  "nextCursor": "<opaque>" | null,
  "hasMore": true | false
}

Rules that make it robust:

  • Return rows changed since the cursor you last issued. We persist nextCursor only after a page imports successfully — a failed fetch retries from the same point, so cursor reads must be repeatable.
  • Re-serving an identical page is always safe (content-hash dedupe on our side).
  • Your own field names are fine — a column mapping can be configured at onboarding; otherwise use the canonical data contract.

Push is still recommended where possible: it's real-time, pull is polled.