Going live checklist

Before you switch from test keys to live keys, check these points. Each one is a real behaviour of the API that is easy to miss during development.

Last updated 2026-11-03

Keys

Create a live site key (bs_site_…) and a live secret key (bs_live_…) and swap them in. Magic addresses no longer apply: every address is screened.
The live site key lists every domain your sign-up form is served from. A check from any other Origin answers 403 ORIGIN_NOT_ALLOWED.
The secret key is only on your server, never in a page, an app or a repository.

It handles all three actions: allow, hold (a pending account with its reviewId) and block.
It has a decided behaviour for a missing token (NO_TOKEN): fall back to /verify, or reject.
It has a decided behaviour when InlineShield cannot answer: fail open (the default in the snippets) or fail closed (INLINESHIELD_FAIL_CLOSED).
With /verify, it sends the player's IP address and User-Agent, not your server's.
It stores the requestId of every screening, for outcome feedback.

Your webhook endpoint is set in Settings › Webhook, verifies every signature and answers 2xx quickly. Send a test ping.
It activates or removes pending accounts on signup.approved and signup.rejected, idempotently.
Someone on your team checks the Review queue: a hold nobody decides within 72 hours is rejected.

Your plan's monthly quota covers your expected sign-ups. Live /verify and /check responses carry X-Quota-Used and X-Quota-State; you also get an email at 80% and 100% of the quota, and screening stops at 110%.
You know what happens over the quota: 402 on /verify and /check, success: false with QUOTA_EXCEEDED on /siteverify. See Rate limits and quotas.