{ sessionId, sealedToken } handoff, and your backend decides whether to allow, challenge, throttle, or block the action.
Recommended flow
1
Start Foil early
Initialize the browser client on page load so collection begins before the user reaches the protected action.
2
Request a fresh session handoff
Right before signup, checkout, login, or another sensitive action, call
foil.getSession().3
Submit the handoff with the business action
Send
{ sessionId, sealedToken } to your backend alongside your normal payload.4
Verify on the server
Use the SDK to verify the sealed token locally with your secret key.
5
Apply policy
Allow, challenge, rate-limit, or block based on the verdict.
Browser handoff
Verify the sealed token
The primary verification path. Local, fast, no network call to Foil.The method is named
safeVerifyFoilToken (and snake/Pascal variants) in every SDK except PHP, where it is SealedToken::safeVerify.Alternative: session readback
If you prefer to fetch the full session from the API (useful for async or audit workflows):Attach your user ID
If the Foil session starts before the user exists in your database, attach your user ID after signup succeeds from your backend:Policy patterns
What’s next
- Testing your integration - simulate bot traffic and debug
- Going to production - rollout checklist
- Verdicts & scoring - understand what scores mean
- Sessions API - full API reference