bad_cursor

Cursors are opaque base64 blobs returned in pagination.next_cursor. We emit bad_cursor when:

• The cursor isn't valid base64 / doesn't decode.
• The cursor's encoded shape is wrong (we evolve the format occasionally; older clients holding a stale cursor across a deploy may see this).
• The cursor's (createdAt, id) keyset references a row that no longer exists in the filtered result set (e.g. the row was deleted, or you changed projectId / dateFrom / dateTo mid-loop).

To recover, start the loop from the beginning without a cursor:

GET /v1/notes?projectId=proj_abc&limit=100

There is no need to discard the data you've already received — the endpoint orders by (createdAt DESC, id DESC), so re-paginating will just re-emit the rows you already have. Dedupe by id if you can't afford duplicates.

See conventions.md §pagination for the full pagination model.