Skip to main content
Fire uses two mechanisms for authentication: a login flow to obtain a Bearer token for API calls, and a signature-based mechanism to verify incoming webhook events.

​
Environments

Start your integration against staging — it mirrors production but is isolated from live data.

​
API authentication

The auth model depends on which endpoint family you call:
  • /api/v1/* endpoints (orders, cancel-order, cash-management, fiscal-callback, fiscal-print, channels-config, payment-methods-config) — only x-api-key: pk_live_... is required. Skip the login flow below.
  • /api/v4/integrations/sales/aggregator/* endpoints (legacy) — use the OAuth login flow described in this page to obtain a Bearer access token.
Calling the Fire API requires four headers on every request: The x-api-key identifies your integration. The x-client-channel header tells Fire the request comes from an external integration. The account header identifies which Fire account the request targets. The Bearer token proves your session is authenticated — you obtain it by calling the login endpoint.

​
Step 1 — Get an access token

Call POST /api/authentication/login with the headers above and your client credentials in the body, using the client_credentials grant type:
A successful call returns 201 Created with the access token:

​
Step 2 — Use the token in every request

Include all four headers in subsequent API calls:
Re-authenticate before the token expires to avoid 401 errors on in-flight requests.

​
Where to get your credentials

API keys, client credentials, and account identifiers are managed from the Fire dashboard under Developers → API Management; see API keys. Contact your Fire account team if you do not have access.

​
Webhook signature verification

Every event Fire sends is signed so your system can confirm it genuinely came from Fire and was not tampered with in transit.

​
How it works

When you register your endpoint in the Fire dashboard, Fire generates a webhook secret — a random string that only you and Fire know. It never travels in any request. Each time Fire sends an event, it uses that secret to compute a signature of the request body and attaches it as the X-Fire-Signature header, together with an X-Fire-Timestamp header. Your system does the same calculation on the body it receives and compares the result:
If the signatures match, the request is authentic. If they don’t, discard it.
The header carrying the signature is X-Fire-Signature by default, but it’s configurable per integration — if your dashboard setup shows a different header name, use that one instead.
Always verify the signature before processing an event. Skipping this step exposes your endpoint to spoofed requests from anyone who knows your URL.

​
Setup

When you add a webhook endpoint under an aggregator integration, the dashboard shows the signing secret for that endpoint (often only once). Copy it and store it securely — you need it to verify every delivery.

​
Verification steps

1

Read the signature header

Extract the value from the X-Fire-Signature header on the incoming request. It has the form sha256=<hex digest> — a prefix, not a bare hex string.
2

Recompute the signature

Using your webhook secret, compute HMAC-SHA256 of the raw request body (before any JSON parsing), then prepend sha256= to the resulting hex digest.
3

Compare

Compare the computed value (with the sha256= prefix) against the full header value using a constant-time comparison. If they match, process the event. If not, return 400 and discard it.
Use the raw body bytes for the HMAC computation — not a parsed or re-serialized version of the JSON. Parsing and re-serializing can alter whitespace or key ordering and cause valid signatures to fail verification.

​
Replay protection

Every delivery also carries an X-Fire-Timestamp header (Unix seconds — when Fire signed the request). Fire does not enforce a delivery window on its side today: if you want protection against a captured request being replayed later, check that the timestamp is within a tolerance you choose (e.g. 5 minutes) before accepting the event.