Authentication

Every request carries the key in the x-api-key header. Authorization: Bearer fitsa_live_... is also accepted, for platforms that can only set a bearer token.

-H "x-api-key: fitsa_live_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

No store identifier to pass

The store, its WhatsApp number and its permissions are all derived from the key.

A request containing storeId, store_id, userId or any equivalent field is rejected, not silently ignored: 400, code unsupported_field.

This is a design choice, not an arbitrary restriction:

• one thing to manage on your side instead of two, one thing to keep secret;
• an identifier accepted as a parameter would be an invitation to try another one;
• a leaked key only exposes one store, since there is no second parameter to vary.

Scopes

Each key carries scopes, in domain:resource:verb form:

A call outside its scope returns 403 with code insufficient_scope and the missing scope in param.

Rotation

The Replace button in the dashboard creates a fresh key with the same settings and revokes the old one immediately. A grace period would leave two valid keys with no way to tell which one is compromised.