Browse docs
API pagination guide: why keyset, not offset#
Offset pagination (?page=3) breaks under concurrent writes: if a row is inserted or deleted while you're paging through, you can see a row twice or skip one entirely, and it gets slower the deeper you page. Keyset pagination follows a cursor derived from the last row you saw, so it stays correct and fast at any depth.
curl "https://api.skedcast.com/v1/posts?limit=50&cursor=eyJ…" \
-H "Authorization: Bearer sked_live_YOUR_KEY"{
"data": [ { "object": "post", "id": "…" } ],
"page": { "cursor": null, "nextCursor": "eyJ…", "hasMore": true },
"meta": { "correlationId": "c-…" }
}Filtering#
Most list endpoints accept status/client/platform filters as ordinary query params alongside limit and cursor — see the specific resource's table in the full API reference for exactly which filters it supports.
Idempotency on writes#
Every POST, PATCH, and DELETE needs an Idempotency-Key header — any unique string, a UUID is simplest. Replaying the same key returns the original result instead of creating a duplicate, so a network retry after a timeout is always safe. A different body under the same key is a 409 conflict, not silently accepted.
FAQ
- Can I jump to a specific page number?
- No — keyset pagination has no concept of a page number, only "the next batch after this cursor". If you need a specific slice, filter more narrowly (by date range or status) instead of trying to skip ahead.
- What happens if I reuse an Idempotency-Key with a different request body?
- A 409 conflict (idempotency key reuse) — the handler never runs a second time. Generate a fresh key for each logically distinct request.