TrustWixDocs
Console handbook

Logs

What your integration did, what we sent you, and the whole trail behind any single verification

Logs is the page for the people who build and run your integration. It has three tabs, and between them they answer nearly every "but we did not receive it" question without anybody having to open a support ticket.

Not everybody has this page

Access is limited to owners and developers. A stored delivery payload is a verbatim copy of what we posted to you, so it can contain applicant data from well outside anything a reviewer was asked to look at. If the page is closed to you, an owner can open it.

Every tab shares a time range at the top: the last 24 hours, 7, 30 or 90 days, or a custom range.

API calls

Every authenticated call your servers made, appearing within seconds of being made.

The figures across the top are calls in the window, the error rate with the count that responded 4xx or 5xx, the p95 duration, and how many calls were slow. The chart puts call volume and errors on the same axis, which is usually enough to see whether a spike in failures is yours or ours.

Filter by path, HTTP method, status class, API key, or slow calls only. The table gives time, method, path, status, duration and which key signed the call.

If a call your backend swears it made is not here, it never reached us, and the answer is on your side: wrong host, wrong key, or something in between the two.

Webhook deliveries

Every event we sent to your endpoints, with the outcome.

Filter by event type, endpoint, delivery outcome, or failures only. Each row gives the time, the event, the endpoint, the response status and how many attempts it took.

Inspect opens the two halves that matter: what we sent, including the signature and the exact payload, and what came back, including the response body, the round trip time, the error, and when the next retry is due.

Retry delivery posts that exact payload to your endpoint again, right now. It reuses the original idempotency key, so a receiver that already processed the event can recognise the repeat and drop it. Use it after you have fixed whatever was rejecting the delivery.

If deliveries are missing entirely rather than failing, the endpoint is probably not subscribed to the event, or the event is not routed to it. Webhooks explains both, and its coverage warnings are usually quicker than reading this page.

Verification activity

The whole trail behind one verification, oldest first: consent, every check with its verdict, any review decision, and each webhook we sent about it.

Pick a session from the recent list or search by verification id or flow. The search covers the most recent verifications in the window rather than your entire history, and says so. If the session you want is not found, check the environment toggle before anything else, because a live session does not exist in the sandbox view.

Exporting

Export takes a period and a scope, counts the matching rows before you commit, and hands you a CSV for a spreadsheet or NDJSON for a developer. The scope is where the value is: problems only, client errors, server errors, failures, still in flight, accepted only.

Exports are capped at the first 20,000 rows. The dialog tells you when your selection exceeds that, so you can narrow the period rather than quietly receive a partial file.

On this page