Skip to main content
v2 keeps the same concepts as v1 but modernises authentication, ordering, and the catalog. v1 remains available; migrate when you’re ready.

​
Key changes

API-key auth

v2 uses a simple x-api-key header instead of bearer-token login/refresh.

Async ordering

Orders return immediately as processing; you poll for codes. No long, blocking requests.

Filtering & pagination

The catalog supports country/language/brand/category/tag filters and skip/take (max 100).

Wallet endpoint

A dedicated GET /v2/wallet returns balances; order responses also embed a wallet snapshot.

​
Endpoint mapping

​
Behavioural differences

The biggest change: ordering is asynchronous. Code that expected pins in the place-order response must now poll GET /v2/orders/{reference} until status is completed. See Order lifecycle.
v2 identifies products by productCode - a stable 14-digit string identifier (for example 10020000213575) used in order lines and product URLs. Internal numeric product ids are no longer exposed. productCodes are stable and identical in sandbox and production: integrate against sandbox, then switch the base URL and API key and the same productCodes work in production. Catalog responses also expose per-locale sku values. Pricing validation is unchanged for fixed products (price must match) and range-checked for open-denomination products.
v1 returned numeric order ids. v2 returns a UUID orderId (for example b9f6f9a2-4d0a-4f5c-9a1e-7c2d8f3b6e10) when you place an order. Poll GET /v2/orders/{reference} with that UUID or with your own externalOrderCode - numeric order ids are not accepted.

​
Response shape changes (v2.1)

See the Changelog for the full list.