FazerCards Glossary
Rate limit
A cap on how many API calls one client can make in a time window. FazerCards uses per-category limits on the public API (catalog read 30/min, order create 60/min, order status 120/min, account 30/min, payments 15/min) so polling never blocks order creation.
Rate limits protect the API from abuse and noisy neighbours. FazerCards splits the public /api/v2 surface into operation categories and applies a sliding-window counter per (category × API key). The numbers are deliberately tight — sized to real reseller workloads (catalog cached locally, a few orders per minute on a busy bot, occasional balance / status reads) rather than to a generous ceiling that abusive integrations can calibrate against. Login endpoints are limited separately (10 attempts per 15 minutes per IP) to make password brute-force economically pointless. When you exceed a category limit, that category returns HTTP 429 with a Retry-After header; the rest of the API remains available.
Key facts
- Catalog read (GET /catalog, /prices, /skus): 30 req/min.
- Order create (POST /order, /topup, /gift-cards, /game-keys): 60 req/min.
- Order status (GET /order/{id}, polling): 120 req/min.
- Account read (GET /me, /balance, /subscription, /transactions): 30 req/min.
- Payment write (POST /payments): 15 req/min.
- Default (anything else): 120 req/min.
- Login endpoints: 10 attempts per 15 minutes per IP.
- Counter key: (category × API key) — categories do not share budget.