API keys and webhooks: what to hand your developer

One named key, read scopes only, and a revoke date.

Compliance and scale

One day a courier, an accountant or a "tech-savvy" cousin will tell you your store "has an API" and "supports webhooks". It sounds like homework you suddenly owe. It is not.

The whole idea fits in two lines. All it asks of you is to copy one key from Integrations → API keys and hand it to the developer.

What each one actually is

An API key is a spare key to the back office. Someone's software uses it to read your orders, products, customers or stock.
A webhook is a bell. When a new order lands, your store rings an address the developer gave you, with the order details inside.

Code and signatures are their side of the line. Yours is the outcome and the key.

First, check that you need a developer at all

Most "integration" in Egypt is push-button: pixels, ready courier links and analytics rarely need code. Start at the app store. Custom work earns its keep in four cases — courier sync with Bosta, orders flowing into your accountant's program for VAT records, alerts on high-value or cash-on-delivery orders, and matching payments against your InstaPay and wallet records. If none of these hurts yet, leave API access off.

Two gates you cannot get around

It is owner-only. Integrations → API keys opens for the store owner, or a member with the Owner role. Everybody else lands on Analytics, an Operations lead included.

It needs Growth or Pro. Starter does not include Public API webhooks; the menu item still shows, then bounces you to Analytics. If your role cannot see the subscription, the page opens but the key fails with public_api_webhooks_not_in_plan.

What you hand the developer

The outcome, in plain words. "When an order is paid, I want it in my accountant's program."
One key, named after their tool. Click New API key and fill in Key name.
Only the scopes they use. Four read scopes are ticked for you — orders:read, products:read, customers:read, inventory:read — and the key gets those four even if you untick everything.
The key itself, once. Storix shows the full key — it starts with mak_ and is 52 characters — once, then keeps only a hash. Copy it, send it, keep a copy.
A revoke date. Keys never expire on their own. Agree it when you hire.

The scope that moves your stock

Read scopes look at data. orders:write changes it. A key with that scope creates real orders: Storix takes the items off your stock, and refuses the order when a product does not have enough. A bug in someone's script becomes a missing item on your shelf. Hand over a write scope only when the project truly needs one.

Revoking, and the 20-key limit

Revoke in the key's row stops the key at the next call, and cannot be undone. A store holds 20 active keys at a time. A lost key can never be shown again, so revoke and create a new one — and revoke on the freelancer's last day, the way you close a staff login.

Three webhook facts that save an argument

Ten seconds. Their server must answer with a success code within 10 seconds. Otherwise Storix retries after 30 seconds, 2 minutes, 10 minutes, 30 minutes and 1 hour — six attempts. After that the delivery waits in the dead-letter queue until someone replays it.
A quiet feed may be paused. Storix can pause a subscription itself when deliveries stay slow, or when the address points to a blocked network. A paused subscription still shows Active, receives nothing, and Enable subscription does not undo it — only the Storix team can resume it, so ask support.
Rotating the signing secret is instant. The old secret dies at once, including deliveries waiting to retry. Warn the developer before you click.

API keys and webhooks come with the Growth and Pro plans — compare plans. This lesson is general guidance for merchants, not legal or accounting advice.