Skip to main content
Error responses are RFC 9457 problem details: a type, a title, a status, and sometimes a detail.
Error responses do not carry a request id. Only a successful 202 does. If you need to raise something with support, report the page URL and the approximate time instead.

​
Every response

Only the first failure is reported. Checks run in this order: workspace and capture key, then the phone number, then consent, then the brand, then the captcha and finally the domain. Fixing one error can reveal the next.

​
About the captcha rejection

CAPTCHA_REJECTED covers four different situations, and two of them are yours to fix:
  • The token expired. It was minted too early. A reCAPTCHA v3 token lasts about two minutes; mint it when the form is submitted, not when the page loads.
  • The token was already used. A token verifies once. If you retried a failed submission without minting a new token, the replay is rejected.
  • The score was too low, or no token was sent at all. These two are the anti-bot check doing its job. There is nothing to fix in your integration.
Because all four return the same code, the useful diagnostic is whether the same visitor succeeds on a second attempt with a fresh token. If they do, it was timing, not a bot.

​
About the 422

This is a transient failure on our side: we could not reach the captcha provider, so we could not decide whether the submission was genuine. Retrying is safe. The lead is preserved when this happens, and a retry cannot produce a duplicate message. Mint a fresh captcha token for the retry, as you would for any other one.

​
About the domain error

The ordering here is genuinely surprising, so it is worth stating plainly. Your page’s domain is checked against the domains registered for your workspace — but the domain we check is the one the captcha provider reports, not the one in the request’s own headers. That check happens after the token verifies. The practical consequence: a page served from an unregistered domain fails at the captcha stage with ORIGIN_NOT_ALLOWED, not with a CORS error. If you are seeing this while your integration otherwise works, the domain is missing from your workspace configuration — contact Bridge to have it added.