The 1inch Business API supports two authentication methods:

1. **API keys** – Simple bearer tokens for direct integrations
2. **OAuth 2.1** – Standard protocol for user consent flows and server-to-server access

Your credentials carry many privileges, so keep them secure. Do not share API keys or OAuth client secrets in publicly accessible areas such as GitHub or client-side code.

---

## API Keys

You can view and manage your API keys under each of your [Applications](/applications).

### Usage

- **Header**: `Authorization: Bearer {YOUR_API_KEY}`
- **Query parameter**: `apiKey={YOUR_API_KEY}`

### REST API Call

```bash
# Header authentication
curl -X 'GET' \
  'https://api.1inch.com/swap/v5.2/1/tokens' \
  -H 'accept: application/json' \
  -H 'Authorization: Bearer YOUR_API_KEY'

# Query parameter authentication
curl -X 'GET' \
  'https://api.1inch.com/swap/v5.2/1/tokens?apiKey=YOUR_API_KEY' \
  -H 'accept: application/json'
```

### WebSocket

```bash
# Header authentication
wscat -c 'wss://api.1inch.com/web3/1' -H 'Authorization:Bearer YOUR_API_KEY'

# Query parameter authentication
wscat -c 'wss://api.1inch.com/web3/1?apiKey=YOUR_API_KEY'
```

### Response Headers

Every API response includes the following header:

| Header         | Description                                                                                             |
| :------------- | :------------------------------------------------------------------------------------------------------ |
| `X-Request-Id` | Unique request identifier. Save this value when troubleshooting -- it correlates with server-side logs. |

**Tip:** When reporting an issue to support or using the MCP [`debug`](/portal/documentation/ai-integration/ecosystem#debug) tool, include the `X-Request-Id` from the failing response. It allows exact log lookup without time-range guessing. Note that logs are only available within the retention period defined by your subscription plan.

---

## OAuth 2.1

OAuth 2.1 provides an alternative to API keys, suitable for:

- **Client Credentials** – Server-to-server integrations without user interaction
- **Authorization Code + PKCE** – User-facing apps where the end user grants access

OAuth access tokens are used the same way as API keys: `Authorization: Bearer {ACCESS_TOKEN}`.

### Obtaining OAuth Clients

**Option A: Application Details (recommended)**

1. Go to [Applications](/applications) → select an application → **Details**
2. In the **OAuth Clients** section, click **Create OAuth client**
3. Choose grant type (Authorization Code or Client Credentials), set redirect URIs if needed, and create
4. Copy `client_id` and `client_secret` from the success dialog

**Option B: Dynamic Client Registration (DCR)**

Register a client via API:

```bash
# Client Credentials – no application_id required
curl -X POST 'https://api.1inch.com/oauth/register' \
  -H 'Authorization: Bearer YOUR_PORTAL_ACCESS_TOKEN' \
  -H 'Content-Type: application/json' \
  -d '{
    "client_name": "My Server Client",
    "redirect_uris": ["https://example.com"],
    "grant_types": ["client_credentials"]
  }'

# Authorization Code – application_id required
curl -X POST 'https://api.1inch.com/oauth/register' \
  -H 'Authorization: Bearer YOUR_PORTAL_ACCESS_TOKEN' \
  -H 'Content-Type: application/json' \
  -d '{
    "client_name": "My Web App Client",
    "redirect_uris": ["https://myapp.com/callback"],
    "grant_types": ["authorization_code", "refresh_token"],
    "application_id": "YOUR_APPLICATION_ID"
  }'
```

### Discovery

Fetch OAuth server metadata (RFC 8414). Replace the base URL with your auth server URL if it differs from the API gateway:

```bash
curl 'https://api.1inch.com/.well-known/oauth-authorization-server'
```

Response includes `issuer`, `authorization_endpoint`, `token_endpoint`, `registration_endpoint`, `jwks_uri`, and supported grant types. Use these URLs for OAuth flows.

### Client Credentials Flow

For server-to-server calls without user interaction:

```bash
# 1. Exchange client credentials for access token
curl -X POST 'https://api.1inch.com/oauth/token' \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -d 'grant_type=client_credentials&client_id=YOUR_CLIENT_ID&client_secret=YOUR_CLIENT_SECRET'

# 2. Use access_token in API calls
curl -X 'GET' 'https://api.1inch.com/swap/v5.2/1/tokens' \
  -H 'Authorization: Bearer ACCESS_TOKEN'
```

### Authorization Code Flow (with PKCE)

For user-facing apps where the end user grants access:

```bash
# 1. Generate PKCE code_verifier and code_challenge (S256)
# code_verifier = 32 random bytes, base64url
# code_challenge = base64url(SHA256(code_verifier))

# 2. Redirect user to authorization endpoint
# GET /oauth/authorize?response_type=code&client_id=...&redirect_uri=...&state=...&code_challenge=...&code_challenge_method=S256

# 3. User approves on consent page, gets redirected to redirect_uri?code=...&state=...

# 4. Exchange authorization code for tokens
curl -X POST 'https://api.1inch.com/oauth/token' \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -d 'grant_type=authorization_code&code=AUTH_CODE&redirect_uri=...&code_verifier=...&client_id=...&client_secret=...'

# 5. Use access_token; use refresh_token when access_token expires
curl -X POST 'https://api.1inch.com/oauth/token' \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -d 'grant_type=refresh_token&refresh_token=...&client_id=...&client_secret=...'
```

### Supported Grant Types

| Grant Type           | Use Case                     |
| -------------------- | ---------------------------- |
| `client_credentials` | Server-to-server, no user    |
| `authorization_code` | User-facing apps with PKCE   |
| `refresh_token`      | Refresh expired access token |