{ sessionId, sealedToken } handoff, and your backend decides whether to allow, challenge, throttle, or block the action.
Recommended flow
Start Tripwire early
Initialize the browser client on page load so collection begins before the user reaches the protected action.
Request a fresh session handoff
Right before signup, checkout, login, or another sensitive action, call
tripwire.getSession().Submit the handoff with the business action
Send
{ sessionId, sealedToken } to your backend alongside your normal payload.Browser handoff
Verify the sealed token
The primary verification path. Local, fast, no network call to Tripwire.Alternative: durable session readback
If you prefer to fetch the full session from the API (useful for async or audit workflows):| Field | Description |
|---|---|
decision.automation_status | none, automated, or inconclusive |
decision.risk_score | 0.0 (human) to 1.0 (bot) |
decision.evaluation_phase | snapshot or behavioral |
decision.decision_status | preliminary or final |
highlights | Top signals that influenced the decision |
automation | Detected automation framework details |
visitor_fingerprint | Durable device identifier |
Policy patterns
| Pattern | When to use | Example |
|---|---|---|
| Report only | First week of integration | Log verdicts, don’t block anyone |
| Soft challenge | inconclusive on sensitive endpoints | Show CAPTCHA or require email verification |
| Hard block | bot on signup, checkout, scraping | Return 403 immediately |
| Rate control | Repeated fingerprints | Slow down instead of blocking |
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