Skip to content
SimplifyLocalDocs
Sign in to the app

Pagination

List jobs and the Build-time feed page with an opaque cursor.

"pagination": { "next_cursor": "eyJjIjoiMjAyNi0wNC0xMlQxNDozMDowMFoiLCJpIjoiMDFITi4uIn0", "has_more": true }

Rules

Section titled “Rules”
  1. Omit cursor on the first request.
  2. Pass next_cursor back verbatim as the cursor query parameter to get the next page.
  3. Stop when has_more is false. next_cursor is null on that page. Whenever has_more is true, next_cursor is non-null, so a follow-the-cursor loop cannot dead-end.
  4. Do not parse the cursor. Its format is implementation-defined and may change without a version bump. The only valid operations are “send it back” and “throw it away”.
  5. Keep the other parameters the same across a paginated walk (limit, updated_since, indexable, reviews, service, city). The cursor records your position, not your filters.
  6. Use a cursor only with the endpoint and business that issued it. The two list endpoints order differently, so a cursor from one means nothing on the other.

Stability

Section titled “Stability”

A cursor marks the position of the last row on the page you received; the next page starts strictly after that position. A job published while you paginate is placed by its own ordering timestamp and does not shift the rows already returned, so a walk started before a publish still completes cleanly. If the row a cursor marks is unpublished in the meantime, the next page simply begins after its position.

A malformed cursor, or one over 512 characters, answers 400 invalid_cursor. Restart from the first page.

Terminal window
curl "https://app.simplifylocal.app/api/businesses/{slug}/jobs?limit=100&aggregates=false&cursor=eyJj…" \
  -H "Authorization: Bearer sl_live_…"

On /jobs, send aggregates=false on every page after the first; the aggregates are the same on every page.

SimplifyLocal