Pagination
List endpoints return bounded { data } arrays today — tasks capped at 50, workers via a limit parameter. Cursor pagination is not yet available.
List endpoints return a bounded set of rows in a single { data } array. There is no cursor to follow and no meta envelope today — a list call gives you the most recent rows, up to the endpoint's cap, in one response.
The envelope
A single-object response wraps the payload in { data }. A list response is the same envelope with an array payload:
{
"data": [
{ "id": "task_8f21", "type": "field_verification", "state": "approved" },
{ "id": "task_8f22", "type": "field_verification", "state": "matched" }
]
}There is no meta object and no next_cursor — the list endpoints don't emit them.
What each list returns
GET /v1/tasks— your org's tasks, newest first, capped at 50. It takes no query parameters, so you always get the most recent page.GET /v1/workers— the public worker projection for a zone. Passlimitto set how many rows come back (default 20, capped at 50), andzone_refto filter by zone.
curl https://api.hannu.africa/v1/workers?zone_ref=lagos_yaba&limit=20 \
-H "Authorization: Bearer $HANNU_KEY"Cursor pagination is not yet available
The list endpoints return bounded results, not paged ones — there is no cursor, next_cursor, or meta to follow yet. Cursor pagination is planned; until it ships, design around the caps above (tasks: 50 newest; workers: limit, max 50). Subscribe to webhooks for task state changes instead of polling long lists.