Partner Orders Polling

Partner integrations can poll the API for the set of orders currently assigned to their partner account, instead of (or in addition to) receiving events via webhooks.

Two read-only endpoints are available — the paginated variant is recommended for all new consumers; the offset-based variant is kept for backwards compatibility with early integrations.

Authentication

Both endpoints require a partner-role access JWT (the same token issued via /v3/auth/access-token — see Authentication).

Authorization: Bearer <PARTNER ACCESS TOKEN>

Authorization rules:

The token's role must be partner (other roles → 401).
A WebhookConfiguration with scope = "partner" must exist for the authenticated partner account. Child partner accounts fall back to their master account's configuration. If neither resolves a configuration → 403.
The response payload shape and version come from that configuration; for the paginated endpoint the configuration's transformer must be s4c.

Visibility scope

The set of orders returned to the caller is determined by the account that owns the resolved WebhookConfiguration (not by the caller's own account directly):

Caller	Orders visible
Contact on a partner account that has its own `partner`-scoped `WebhookConfiguration`	Orders assigned to that partner account and to all of its direct child partner accounts.
Contact on a child partner account (the child has no own configuration; resolved via fallback to the master)	Orders assigned to the master account and all of its direct child partner accounts — i.e. the same set the master would see, including siblings of the caller's account.

In other words: when a child contact's WebhookConfiguration is resolved via the master fallback, the visibility scope widens to the master's full first-level subtree. Configure a partner-scoped WebhookConfiguration directly on a child account if you need its contacts to be restricted to that account's own orders.

Orders that are not assigned to any account inside the resolved scope are never returned.

`GET /v3/partner-orders/paginated`

Returns the partner's orders in a stable paginated envelope.

Query parameters

Name	Type	Default	Description
`page`	integer (≥1)	`1`	1-based page index.
`pageSize`	integer (1–200)	`50`	Page size. Values above 200 are silently clamped to 200.
`updatedSince`	ISO‑8601 datetime	none	Only return orders whose `updatedAt >= updatedSince`. Use for delta polling.
`active`	boolean (`true`/`1`)	false	When `true`, exclude orders whose status is one of `new`, `cancelled`, `closed`, `completed`, `invoice sent`. Use to fetch only the orders that still require partner action.

Response

{
  "items": [ /* OrderStatusEvent-shaped payloads, one per job */ ],
  "page": 1,
  "pageSize": 50,
  "total": 1234
}

items is ordered by updatedAt descending and is sized to at most pageSize. total is the unpaginated count under the same filters (account scope, updatedSince, active).

Example

curl -i "https://<api-host>/v3/partner-orders/paginated?active=true&page=1&pageSize=50&updatedSince=2026-05-01T00:00:00Z" \
  -H "Authorization: Bearer <PARTNER ACCESS TOKEN>"

`GET /v3/partner-orders`

Legacy offset-based listing. Returns a raw array (no envelope).

Query parameters

Name	Type	Default	Description
`limit`	integer	unbounded	Max number of orders to return. No server-side cap — prefer `/paginated`.
`offset`	integer	`0`	Skip the first N orders.
`updatedSince`	ISO‑8601 datetime	none	Same semantics as on `/paginated`.
`active`	boolean (`true`/`1`)	false	Same semantics as on `/paginated`.

Response

[
  { "_v": "1.3.0", "_type": "OrderStatusEvent", /* … */ },
  /* … */
]

Errors

HTTP status	Meaning
`401`	Missing, expired, or invalid JWT.
`403`	Authenticated, but the partner account has no `partner`-scoped `WebhookConfiguration` (and no parent account that does).
`400`	`/paginated` was called on an account whose `WebhookConfiguration.transformer` is not `s4c`.