> ## Documentation Index > Fetch the complete documentation index at: https://docs.myproceeds.xyz/llms.txt > Use this file to discover all available pages before exploring further. # Events > The step-by-step trail every paid request leaves behind — your first stop when something fails. Every paid request leaves a trail. Proceeds emits an event at each step so when something breaks, you can see exactly where. Use **Events** to answer one question: *where did this flow stop?* Filter by **All**, **Request**, **Success**, or **Error**. Expand a row to inspect the response payload. Events are also available via `GET /v1/events` and [webhooks](/dashboard/webhooks). ## Event types | Event | Meaning | | --------- | ------------------------------------------------------------------------------------------ | | `REQUEST` | Paywall hit without payment (`402` path). | | `SUCCESS` | Successful payment and fulfillment — the request was proxied to the upstream `Target URL`. | | `ERROR` | Settlement or upstream failure. | A healthy paid request emits `REQUEST → SUCCESS`. An unpaid challenge emits `REQUEST` only. ## Filters `All`, `Request`, `Success`, `Error`. ## How to read the stream Start at the latest event and walk backwards: 1. Did `REQUEST` fire? If not, the URL never reached Proceeds — check DNS or the client's URL. 2. Did `SUCCESS` fire? If not, either the client never paid, payment was rejected, or settlement/upstream failed. 3. If you see an `ERROR` event, open it for the underlying reason — see [Forward upstream auth](/guides/forward-upstream-auth) and [Custom headers and query parameters](/guides/custom-headers-and-params) when the failure is upstream. Compare event traces against the matching transaction record. Push these events to your server instead of inspecting them here.