Making requests
Base URL
https://api.biflus.com. Every path in this
doc (/v1/clients, etc.) hangs off that.
Object IDs
Every record has an _id like
client_a8f291 or inv_9a3d27
— a short, type-prefixed id, the same format used throughout this
documentation. Treat it as an opaque string, not something to parse or
construct yourself: always use the id a response gave you, never guess
one.
Rate limits
100 requests per minute, per API key. Exceeding it returns
429; see Errors. The
limit resets on a rolling one-minute window, not a fixed clock minute, and
there's no response header exposing your remaining quota today — the
only signal is the 429 itself.
Pagination
List endpoints (GET /v1/clients,
/v1/items, etc.) accept
?limit (default 25, max 100) and
?cursor. Every list response includes a
pagination object: pass its
next_cursor back in as ?cursor
to get the next page; a null cursor means you're
at the end.
{ "data": [ /* … */ ], "pagination": { "count": 28, "remaining": 3, "next_cursor": "MjU=" } }
Libraries
There's no official SDK — every example on this page is plain HTTP, so any language with an HTTP client works today (Zapier's own HTTP action included).
- Request the max
limit=100when syncing a whole resource in bulk — fewer round trips, same rate-limit cost per request. - Always loop until
next_cursorisnull, even if you "know" there's only one page — catalogs and client lists grow. - Back off with a short delay after a
429rather than retrying immediately in a loop — 100/min is generous for normal use, so a 429 usually means a retry loop, not real traffic.
- Don't build your own offset-based pagination by guessing at index math —
cursoris an opaque token, treat it as one and just pass it straight back. - Don't assume
countis the total across all pages — it's the count on the current page only; use repeated calls untilnext_cursoris null to get everything. - Don't hit the rate limit from parallel workers on one key. 100 req/min is per key, not per request source — fan-out jobs sharing one key add up fast.