SDK key auth

Every /storefront/v1 request uses a site-scoped SDK key. The middleware resolves its tenant, site, brand, environment, and scopes before a handler runs.

Send the key

The SDK sends:

X-InBlack-SDK-Key: inb_pk_live_REDACTED

For direct HTTP calls, set the same header yourself. Keys use this shape:

inb_{pk|sk}_{live|test}_{token}

Use pk publishable keys in browser applications. Never embed an sk secret key in client code. Live and test keys are distinct and resolve only active site records.

Missing, malformed, expired, or revoked keys return 401 with code invalid_sdk_key.

Scopes

Current storefront scopes are:

Scope	Access
read-only	GET storefront routes
read-write	Reads and non-GET routes
admin	All storefront methods accepted by this middleware

A valid key without the required scope returns 403 with code insufficient_sdk_key_scope.

These SDK scopes do not grant access to tenant administration or pillar GraphQL APIs. Customer account routes additionally require a customer bearer token where indicated.

Rate limits

Storefront traffic is limited independently by client IP and SDK key:

Route class	Per IP	Per SDK key
General /storefront/v1 traffic	100 requests/minute	100 requests/minute
/storefront/v1/auth/*	10 requests/minute	10 requests/minute

The Google callback does not require an SDK key because signed state resolves the brand, but it still uses the auth IP limit.

When a limit is exceeded, honor Retry-After, apply jitter, and avoid retrying multiple browser requests at once.

Bot protection boundary

The storefront middleware currently provides SDK-key validation, scope checks, and rate limiting. It does not require a Turnstile, CAPTCHA, or other challenge token by default. Add browser-side bot controls at your edge when your threat model requires them; do not send an undocumented challenge field to the API.