Pagination

Caution

GET /orders/ does not expose numeric pagination on the public route. The endpoint returns a flat array of Payment with all the results for the requested range.

Control the response size by narrowing the range with start and end.

Parameters

GET /orders/ accepts:

Param	Format	Default	Description
start	YYYY/MM/DD	today − 7 days	Start date (inclusive, UTC).
end	YYYY/MM/DD	today	End date (inclusive, UTC).

The page and items_per_page parameters exist in the code but currently have no effect on the public response (they are dashboard internals). Do not rely on them; control volume by range.

Example

curl -H "X-Device-Id: $B4BIT_API_KEY" \
  "https://pos.b4bit.com/api/v1/orders/?start=2026/01/01&end=2026/01/31"

Time zone

Dates are interpreted in UTC (confirmed in the backend, settings.py TIME_ZONE = 'UTC'). If your merchant operates in another time zone, convert before sending to avoid payments at the day boundary falling outside the range.

Ordering

Payments come sorted by created_at descending (most recent first).

Recommendations

• Batch by short ranges (daily or weekly) if you have high volume. Avoids huge responses.
• Prefer webhooks for real-time updates; use GET /orders/ only for historical reconciliation.
• When reconciling, save the last processed edited_at and filter by range from that point on.

Recommended reconciliation

1. Persist every incoming webhook with identifier + status + edited_at.
2. Once a day, call GET /orders/?start=yesterday&end=today and cross-check by identifier against your database.
3. For any payment that does not match, fetch the detail with GET /orders/info/{identifier}.