Audit logging

What activity a Valyd integration can observe, and where a developer or org admin reads it. Four things are verifiable today from Valyd’s own docs — the X-Request-Id on every response, the verification event records, the webhook delivery log in the Developer Portal, and org login attribution via the valyd_org_member_id claim. Everything beyond those observable signals (log retention, export/SIEM, tamper-evidence, an account-level admin audit trail) is not documented in these docs; contact support@valyd.id for the current details. Nothing here asserts an audit capability Valyd has not documented.

Request correlation: X-Request-Id

Every Valyd response carries an X-Request-Id header — the correlation id for that single request. It is the one identifier you quote to support to have a specific call traced, and it is the value support asks for first. Log it on your side against your own request records so a later investigation can line up your logs with Valyd’s. See Errors & troubleshooting for the exact support contract, and never quote API keys or tokens alongside it.

Verification events

Each verification session produces durable, machine-readable event records you can act on:

• Terminal outcomes — verification.approved / verification.declined.
• Non-terminal states — verification.in_review (a manual/agent review is pending), verification.abandoned (the user left Valyd’s verification page), verification.expired (the session TTL elapsed).

Each event carries a stable event_id (mirrored in the X-Valyd-Event-Id header) and the session_id that produced it. The decision API (GET /api/v2/session/{id}/decision) is the authoritative record of a session’s result — poll or fetch it any time, independent of whether a webhook was delivered. Full event shape: Webhooks.

Webhook delivery log

Every webhook attempt — successful or failed — is recorded in the Developer Portal, on your application’s Verification page under Recent webhook deliveries. For each attempt the log shows the destination URL, the exact payload and headers Valyd sent, the receiver’s HTTP status and response body, and any transport error. A delivery is retried automatically (up to 10 attempts across roughly 2.5 hours), and the Resend button re-queues any delivery on demand — a resend carries the same X-Valyd-Event-Id, so an idempotent handler treats it as the same event. This is the built-in place to confirm what Valyd told your endpoint and when. Details: Webhooks — delivery log and manual resend.

Who signed in: valyd_org_member_id

For an organization, you always know exactly which of your people just logged in. When an org member signs in with Connect with Valyd, the valyd_org_member_id claim returns on the OIDC userinfo response and in the ID token (scoped to your org’s client). Its value is that member’s vmem_… id — your join key between your own roster and the login — so you can attribute and track logins against your own records. See Organizations & teams.

Not yet published

These are standard audit questions an enterprise review asks. They are not documented in these docs today — contact support@valyd.id for the current answers. Retention windows for the delivery log and request logs are tracked separately on Data retention.

See also

• Errors & troubleshooting — the X-Request-Id support contract
• Webhooks — event shape, retries, and the delivery log
• Data retention — how long logs and records are kept
• Support & escalation — what to send when you contact support
• Trust Center