# Request Logs in Developer Portal

import BeforeYouBegin from '_core/components/BeforeYouBegin/BeforeYouBegin';

<BeforeYouBegin />

**Request Logs** is a searchable history of the API calls your integration makes to noon. When a call fails or behaves unexpectedly, open the [Request Logs dashboard][portal-request-logs-tool], lookup the api call by its request ID, and see what noon received and sent back — status, timing, headers, and payloads — without asking noon support to pull logs for you.

This page explains what Request Logs captures. To look up a specific call, see [Find and inspect a request][developer-portal-request-logs-find-request].

## How it works

1. Your integration calls noon APIs as usual — there's nothing to enable or configure.
2. noon records each call against your project: which API user made it, which endpoint it hit, the status, how long it took, and — depending on the call — its payloads.
3. Every response noon sends back carries an `x-request-id` header that uniquely identifies that call.
4. Within a few seconds, the call appears in [**Request Logs → Dashboard**][portal-request-logs-tool] in the Developer Portal.
5. You can search, filter, and open the call for the next 14 days. After that, it's deleted.

## What gets logged

Every call your project's API users make to noon APIs is logged, across every marketplace. The only exception is public endpoints that don't require a session — including authentication calls such as logging in your API user.

:::tip Can't find a request log?
On rare occasions, an api call may not show up in the dashboard. Its log can still be retrieved — raise a [support case][developer-portal-support-cases] and include the request ID.
:::

## What each log contains

Every log includes:

- Request ID, time, and duration
- Status code and, for failed calls, the error code
- Method, endpoint, and query parameters
- API user, project code, and marketplace
- IP address the call came from
- The `user-agent` and `content-type` request headers

What else is stored depends on the method and the outcome:

| | POST | GET — success (2xx) | GET — failure (non-2xx) |
|---|---|---|---|
| Request payload | Yes | — | — |
| Response payload | Yes | No | Yes |
| Response headers | Yes | No | Yes |

A successful GET shows no response payload or response headers — that's expected, not a missing log.

When response headers are stored, they're limited to `content-type`, `content-length`, `content-encoding`, `x-request-id`, and the rate-limit headers `x-ratelimit-remaining`, `x-ratelimit-burst-remaining`, and `x-ratelimit-retry-after`. For what the rate-limit headers mean, see [Rate Limits & Usage][rate-limiting].

## Getting started

- **Integrators:** start recording `x-request-id` from every response, then follow [Find and inspect a request][developer-portal-request-logs-find-request] the next time a call fails.
- **Sellers:** ask your integrator for the request ID of the failing call, or filter the dashboard by time and **Failure** status — see [Find and inspect a request][developer-portal-request-logs-find-request].