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

# Authentication

> How to authenticate Request Network API calls with API keys or Client ID

## Overview

Request Network API supports two authentication modes:

* `x-api-key` for server-side integrations
* `x-client-id` for browser/client integrations (with `Origin` header)

Use this page as the canonical auth reference. Client IDs are managed in the [Request Dashboard](https://dashboard.request.network). Webhooks can be managed no-code from the [Dashboard](/tools/dashboard#webhooks) or programmatically via the [Auth API](https://auth.request.network/open-api/#tag/webhook) (`POST /v1/webhook` with the `x-client-id` header).

## Choose the Right Method

| Method    | Best for                                                 | Header(s)                  |
| --------- | -------------------------------------------------------- | -------------------------- |
| API Key   | Backend services, cron jobs, trusted server environments | `x-api-key`                |
| Client ID | Browser/front-end calls where client auth is required    | `x-client-id` (+ `Origin`) |

## API Key Authentication

Use API keys for backend calls.

### Example

```bash cURL theme={null}
curl -X GET 'https://api.request.network/v2/request/{requestId}' \
  -H 'x-api-key: YOUR_API_KEY'
```

## Client ID Authentication

Use Client ID when your integration needs browser-side authentication flow.

### Example

```bash cURL theme={null}
curl -X GET 'https://api.request.network/v2/request/{requestId}' \
  -H 'x-client-id: YOUR_CLIENT_ID' \
  -H 'Origin: https://your-app.example'
```

<Info>
  For browser-based requests, `Origin` is part of the request context and is required for Client ID auth.
</Info>

## Header Reference

* `x-api-key`: API key used for server-side auth
* `x-client-id`: Client identifier used for client-side auth
* `Origin`: required with Client ID flows in browser contexts

## Rate limits

Request Network enforces rate limits on `x-client-id` requests to keep the API responsive for every integrator. By default, authenticated `x-client-id` integrators get an SLA of **300 requests per minute (5 requests per second)** in production.

Several tiers exist. Most integrators run on **Default**; contact us to move to a higher-throughput tier if you need one:

| Tier                   | Rate                       |
| ---------------------- | -------------------------- |
| Basic                  | 2 req/sec (120 req/min)    |
| Default (standard SLA) | 5 req/sec (300 req/min)    |
| Premium                | 10 req/sec (600 req/min)   |
| High-volume            | 20 req/sec (1,200 req/min) |

Tiers are listed from lowest to highest throughput; `Default` is the standard SLA applied to authenticated integrators unless you have been assigned another tier.

Rate limits are scoped per client ID and IP address, so usage from one client ID on one IP doesn't affect your limit on another IP. If you sustain a breach of your limit, requests from that client ID and IP are temporarily blocked (5 minutes by default) before being allowed again. Some endpoints, such as client ID management, use a more relaxed limit than the general default shown above.

<Note>
  The production default is 5 req/sec. Non-production environments (development and test) run at a higher limit to support testing. Contact us if your integration needs a higher tier than the production default.
</Note>

## Common Authentication Errors

### 401 Unauthorized

* Missing auth header
* Invalid/expired API key or client ID

### 403 Forbidden

* Credentials are valid but not allowed for the requested operation
* Client ID is revoked or restricted

### 429 Too Many Requests

* Request rate exceeded for your credentials. See [Rate limits](#rate-limits).

## Security Guidance

* Keep API keys server-side and out of frontend bundles
* Store credentials in environment variables or secret managers
* Rotate compromised credentials immediately
* Verify webhook signatures independently (webhook signing uses a separate secret)

## Related Pages

<CardGroup cols={3}>
  <Card title="Dashboard" href="https://dashboard.request.network" icon="key">
    Create credentials and manage webhook configuration.
  </Card>

  <Card title="Webhooks" href="/api-reference/webhooks" icon="webhook">
    Signature verification and delivery behavior.
  </Card>

  <Card title="OpenAPI Reference" href="https://api.request.network/open-api" icon="book">
    Full endpoint authentication requirements.
  </Card>
</CardGroup>