Application context after login

Application context is an opt-in assertion by your server. It connects a stored detection to references in your application audit log. It does not independently verify a customer’s identity or change the bot score, admission decision, or route policy.

Send it from the server

Use a property-scoped organization API key, kept on your backend. The /api/v1/sdk/detect request accepts an optional top-level application_context object alongside request_metadata and local_analysis. The browser detection tag does not supply this trusted context.

{
  "request_metadata": {
    "method": "POST",
    "path": "/api/reports",
    "ip": "203.0.113.10",
    "user_agent": "example-client"
  },
  "local_analysis": {},
  "application_context": {
    "account_ref": "acct_opaque_123",
    "tenant_ref": "tenant_opaque_7",
    "request_id": "request_opaque_456",
    "action": "report.generate",
    "authenticated": true,
    "outcome": "attempted"
  }
}

Derive account, tenant, and authentication state from your server’s verified authentication context. Never copy them from visitor-controlled request headers or a form field. A request header named wd_application_context is withheld and cannot replace this field.

This is an HTTP API addition. Existing SDK releases do not automatically forward arbitrary new options. Use a server-side API adapter that explicitly sends the field, or wait for an SDK version documenting it; adding an unknown option to an old SDK is not an integration.

Contract

• request_id and action are required.
• account_ref and tenant_ref are optional opaque references. Missing remains unknown.
• References are 1–128 ASCII letters, digits, dots, underscores, colons or hyphens, starting with a letter or digit. The action uses the same alphabet and is at most 64 characters.
• authenticated is an optional boolean. Omitted does not mean false.
• outcome is required: attempted, started, completed, failed, refused, or unknown.
• Use attempted for a pre-handler check. Do not report completed before the action has actually completed in your application. This field is your report, not independent execution verification.
• The API rejects invalid context and requests carrying context without a property-scoped key with HTTP 400. Existing requests without context are unchanged.

Do not include emails, passwords, access tokens, raw prompts, customer records or request bodies. Prefer stable random or keyed opaque references that you can resolve in your own system. Do not treat the field restrictions as a general personal-data detector.

Read it in the app

Open App Activity from the dashboard. Observed route activity shows the account, tenant, action, authentication state, reported outcome, and request reference where present. Records without context say Not connected.

Context is retained only alongside a stored bot detection. It does not turn ordinary human requests into a product analytics stream. It inherits the detection’s property/organization access controls and retention; deleted or expired detections no longer provide context. Context from API-key SDK detections is kept separate from browser assertions and from AI Protection’s existing tool/model usage reports.

Actor journeys group observed traffic. Their time-gap segments are inferred, not login sessions, and a network actor may group unrelated clients. Each row’s account reference belongs to that reported request; do not roll one account onto every event in an actor group or use IP matching to join identities.

Verify one action

Use a synthetic account and records in an isolated workspace. Match the exact request reference in your app audit log to the stored detection. Check a second account on the same IP remains distinct. Inspect recorded responses separately from reported action outcomes. In monitor mode requests pass; if you choose to enforce, verify in your own handler log that the refused operation did not execute and that ordinary access still succeeds.