REST API / Authentication

Authentication

Feed API uses API keys to authenticate requests. All requests to protected endpoints must include your key in the x-api-key header.

Getting your API key

1Log in to your reseller dashboard
2Navigate to Settings → API Keys
3Click "Create API Key" and give it a name
4Copy the key — it is only shown once

Warning

A new key is created with every access right enabled, so treat it as full access to your reseller account until you narrow it. Never expose it in client-side code or public repositories.

Making authenticated requests

Pass your key in the x-api-key header:

curl

curl https://api.feedapi.co.uk/v1/products \
  -H "x-api-key: fapi_your_key_here"

JavaScript

const response = await fetch(
  "https://api.feedapi.co.uk/v1/products",
  {
    headers: {
      "x-api-key": "fapi_your_key_here",
      "Content-Type": "application/json",
    },
  }
);

const { data, meta } = await response.json();

Key format

All keys begin with fapi_ followed by 64 hex characters.

Example

fapi_a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2

Access rights

Every key carries a set of access rights that decide which endpoints it may call. You choose them when you create the key and can change them at any time under Settings → API Keys → Access rights — the key itself does not change, so there is nothing to redeploy. Calling an endpoint your key does not cover returns 403 INSUFFICIENT_SCOPE.

products:readGET /v1/products, /v1/products/:id, /v1/products/:id/variants

categories:readGET /v1/categories

suppliers:readGET /v1/suppliers, /v1/suppliers/:id

orders:readGET /v1/orders and its sub-resources (returns, shipments, status-history, cancellations)

orders:writePOST /v1/orders, /v1/orders/:id/cancel, /v1/orders/:id/returns

webhooks:readGET /v1/webhooks, /v1/webhooks/:id/deliveries

webhooks:writePOST, PATCH and DELETE on /v1/webhooks, plus /v1/webhooks/:id/rotate-secret

inventory:readGET /v1/inventory/movements — stock change history for your catalogue

Tip

Rotating a key carries its access rights across to the replacement, so you never have to set them up again. Narrowing takes effect on your very next request — there is no second key to fall back on, so switch a right off only once nothing is using it.

Key lifecycle

Active

Key is valid and can make requests.

Retiring

Key was replaced by a rotation and still works, but only until its deadline. Move your integration to the new key before then.

Revoked

Key was manually revoked. Returns 403 KEY_REVOKED.

Expired

Key passed its expiry date. Returns 403 KEY_EXPIRED.

Tip

Each reseller account has one active API key at a time. To replace it without downtime, use Rotate in Settings → API Keys rather than revoking: you get the new key immediately and the old one keeps working for a window you choose (1 hour, 24 hours, or 7 days). Revoke the old key early once your integration is switched over.

Rate limits

Requests are rate-limited per account to 60 requests per minute, not per key — during a rotation the retiring key and its replacement draw on the same budget. Status is returned in headers:

X-RateLimit-Limit60Maximum requests per minute

X-RateLimit-Remaining58Requests remaining in current window

X-RateLimit-Reset1719227460Unix timestamp when window resets

Retry-After12Seconds to wait (on 429, and on the 503 below)

Tip

Going over the limit returns 429 RATE_LIMIT_EXCEEDED. Separately, if the limiter itself cannot reach its store it refuses the request with 503 rather than letting it through unmetered — also with a Retry-After. Both are temporary and safe to retry after backing off.