> ## Documentation Index
> Fetch the complete documentation index at: https://docs.amlok.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Trace API requests and errors

> Find a request, inspect its payload and response, and troubleshoot asynchronous processing or failures without losing the original identifiers.

Use **Dev Tools > Request logs** to inspect calls made to the product API. Use **Errors & retries** to focus on failed requests. These views are available to Owners and Developers.

## Find the request

Filter by status, request details and time, or search for the identifier you recorded in your client. Confirm the workspace and environment first. Times marked **UTC** use UTC rather than your browser's local time.

![API request log table with HTTP methods, endpoint paths, response statuses and timestamps.](https://mintcdn.com/amlok-docs/HXjKmnxFg9L3P2cw/images/console/request-logs.jpg?fit=max\&auto=format\&n=HXjKmnxFg9L3P2cw\&q=85\&s=3d5b3caace875f73d3b61d58190b28cc)

Request logs show method, path, status and timing so you can identify the call to inspect.

Select a row to open its drawer. Use the available tabs to inspect the overview, request, response, related records and activity. Payloads and metadata can be redacted; the log is not a place to recover secrets.

## Read the response before retrying

| Status or situation | Next step |
| - | - |
| `202` accepted | Follow the returned operation or record. Acceptance is not completion. |
| `400` or validation error | Check the identified field and schema in Data Lookup. Correct the input before retrying. |
| `401` or `403` | Check the key, expiration, environment, scope and access. |
| `404` | Check the identifier and whether it belongs to the selected workspace and environment. |
| `409` | Read the conflict reason, including idempotency or resource-state conflicts. |
| `429` | Respect the returned retry guidance and reduce request pressure. |
| Timeout or server error | Use the recovery and idempotency contract to determine whether the original request was accepted. |

![Request drawer showing a 429 rate-limit response payload for an origination request.](https://mintcdn.com/amlok-docs/HXjKmnxFg9L3P2cw/images/console/request-response.jpg?fit=max\&auto=format\&n=HXjKmnxFg9L3P2cw\&q=85\&s=22c96059c8b529a7b1d7bb22570a25ef)

The response view shows the returned error payload. Use the error code and request identifier in your investigation.

For a retry of the same write, retain the same idempotency key and payload as required by the [idempotency contract](https://docs.amlok.io/api-reference/idempotency.md). Do not repeatedly create new originations to recover from a lost response.

## Keep a useful trace

Record the AMLOK request identifier, your caller request identifier when supplied, the UTC time, method, endpoint and related record or job identifier. Preserve the error code and response status. These make it possible to connect client activity with processing and later events.

Opening a request does not retry it. Outbound webhook attempts appear separately in [Deliveries & events](https://docs.amlok.io/console/webhooks.md), because a successful API request and a successful event delivery are different operations.

See [request recovery](https://docs.amlok.io/api-reference/request-recovery.md), [errors](https://docs.amlok.io/api-reference/errors.md) and [rate limits](https://docs.amlok.io/api-reference/rate-limits.md) for exact retry behavior.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.