Authentication

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.

Usage

• Header: Authorization: Bearer {YOUR_API_KEY}
• Query parameter: apiKey={YOUR_API_KEY}

REST API Call

         
         

           Bash
         
 
         
         

           
           

             
1
2
3
4
5
6
7
8
9
10
           
 
           
           
# 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
         
 
         
         

           
           

             
1
2
3
4
5
           
 
           
           
# 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:

Tip: When reporting an issue to support or using the MCP 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 → 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
         
 
         
         

           
           

             
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
           
 
           
           
# 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
         
 
         
         

           
           

             
1
           
 
           
           
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
2
3
4
5
6
7
8
           
 
           
           
# 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
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
           
 
           
           
# 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