Skip to main content

Partner API: pagination, field selection and identifiers

The rules that hold across every endpoint: how paging works, how to narrow a response with ?fields=, and the difference between asan_empcode and employee_id.

Written by Vaibhav Kashyap

Pagination

4 endpoints are paginated: /v1/bank_details, /v1/employees, /v1/leave/balances, /v1/salary.

  • limit — Rows per page, 1-200. Defaults to 50.

  • cursor — Opaque cursor from the previous page's next_cursor. Omit for the first page; a null next_cursor means there are no further pages.

A paginated response looks like this:

{
  "data": [ ... ],
  "next_cursor": "eyJvIjo1MH0"
}

Loop until next_cursor comes back null. Treat the value as opaque — pass it back exactly as you received it. It is not a row number or an offset, and its internal format is free to change.

An endpoint that is not in the list above returns its whole result set in one response. Reference data works that way, because there are tens of rows, not thousands.

Narrowing the response with ?fields=

10 endpoints accept ?fields=: Comma-separated subset of this endpoint's response fields, at most 100. Narrowing only: a name outside the documented field list is rejected with 400, never silently ignored.

Each endpoint article lists the exact names that endpoint accepts. Note that it only ever narrows: you cannot ask for a field the endpoint does not already return, and asking for one is a 400 rather than a silent drop.

The two employee identifiers

This is the single thing integrations most often get wrong, because both are called some kind of employee id.

  • asan_empcode is Asanify's own identifier. It is stable, it never changes, and it is what appears in URL paths. It is also the join key: the same asan_empcode identifies a person across the directory, payroll, salary, leave and bank details. Store it as your foreign key to Asanify.

  • employee_id is your employee code — the one your team typed into Asanify, unique within your company. It is returned as a field, and several endpoints accept it as a filter, but it is not what paths take, and a customer who renames their codes changes it.

If you take one rule from this article: join on asan_empcode, display employee_id.

Dates and nulls

Dates are YYYY-MM-DD strings. A field documented as nullable comes back as JSON null when it has no value, never as an empty string and never omitted — so your parser can rely on the key being present.

Did this answer your question?