API Request Headers: Where & How to Write Them

In the vast, interconnected landscape of modern web applications and services, Application Programming Interfaces (APIs) serve as the crucial backbone, enabling disparate systems to communicate seamlessly. From fetching weather data to processing financial transactions, APIs orchestrate the digital ballet that powers our daily lives. Yet, beneath the surface of seemingly simple requests and responses lies a sophisticated layer of meta-information that dictates how these interactions unfold: API Request Headers. Far more than mere ornaments, these headers are the silent workhorses, carrying vital context, authentication details, content specifications, and operational directives with every byte sent across the network. Understanding where these headers reside, how they are meticulously crafted, and the profound impact they have on api performance, security, and interoperability is fundamental for any developer, architect, or system administrator navigating the complexities of distributed systems.

This comprehensive guide delves deep into the world of API request headers, demystifying their structure, exploring the myriad environments where they are defined, and providing practical, actionable insights into how to write and manage them effectively. We will journey from the client-side applications that initiate requests, through the intricate pathways of api gateway infrastructures, and into the precise syntax required to wield these powerful metadata fields. Prepare to uncover the nuanced details that transform a generic data request into a highly specific, secure, and efficient api call, laying the groundwork for robust and reliable system integrations.

1. The Anatomy of an API Request: More Than Just a URL

Before we delve into the specifics of headers, it's imperative to grasp the fundamental structure of an API request. At its core, an API interaction, especially over the web, typically adheres to the Hypertext Transfer Protocol (HTTP) or its secure counterpart, HTTPS. These protocols define the rules of communication between clients (e.g., web browsers, mobile apps, servers) and servers, enabling the exchange of data in a structured manner.

An HTTP request is not merely a single piece of information; rather, it’s a meticulously structured message composed of several distinct parts. Understanding each component is crucial for appreciating the role headers play.

1.1 The Pillars of an HTTP Request

Every HTTP request fundamentally consists of four primary components:

1. Request Line: This is the very first line of an HTTP request and it provides the server with essential information about the action the client wishes to perform and on which resource. It comprises three parts:
   • HTTP Method (Verb): Specifies the desired action to be performed on the identified resource. Common methods include GET (retrieve data), POST (submit data), PUT (update/replace data), PATCH (partially update data), and DELETE (remove data).
   • Request Target (URL/URI): Identifies the resource upon which to apply the method. This is typically the path component of a URL, sometimes including a query string. For instance, /users/123 or /products?category=electronics.
   • HTTP Version: Indicates the version of the HTTP protocol being used, such as HTTP/1.1 or HTTP/2.0. This influences how the rest of the request is parsed and handled.
2. Request Headers: Following the request line, this section contains a series of key-value pairs that provide additional information about the request, the client, or the server's desired behavior. Headers are meta-data about the request itself, not the data being sent. This is the central focus of our discussion, and we will explore their significance and various types in immense detail. Headers dictate everything from authentication credentials to the expected format of the response, acting as crucial directives for both the client and the server.
3. Empty Line: A blank line (CRLF sequence) separates the request headers from the request body. This seemingly trivial detail is vital for the server to correctly parse the request and identify where the header section ends and the body content begins. Without it, the server would not know when to stop looking for headers and start processing the main payload.
4. Request Body (Optional): This component carries the actual data payload of the request. It is typically used with POST, PUT, and PATCH methods, where the client is sending data to the server for creation or modification. For GET and DELETE requests, a body is generally absent or ignored, as these methods typically operate on resources identified by the URL alone. The format of this body is often specified by a header, such as Content-Type.

Consider a simple request to create a new user:

POST /users HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer <your_jwt_token>
Content-Length: 53

{"username": "johndoe", "email": "john.doe@example.com"}

In this example: * POST /users HTTP/1.1 is the Request Line. * Host, Content-Type, Authorization, and Content-Length are the Request Headers. * The blank line separates headers from the body. * {"username": "johndoe", "email": "john.doe@example.com"} is the Request Body.

1.2 Headers as Metadata: The Context Keepers

The beauty and power of request headers lie in their ability to convey critical metadata. This metadata allows for incredibly flexible and efficient communication without burdening the actual data payload. Think of them as the meticulously filled-out shipping labels on a package: they tell the recipient not just what's inside, but also who sent it, how it should be handled, its weight, and how it's wrapped.

For APIs, headers define: * Authentication and Authorization: Who is making the request and are they permitted to do so? * Content Negotiation: What format is the data being sent in, and what format does the client prefer for the response? * Caching Directives: Should this response be cached, and for how long? * Client Information: What software is making the request? * Session Management: Maintaining state across multiple requests. * Conditional Requests: Only return data if it has changed since a specific time or version. * Custom Behaviors: Enabling specific features or overriding default server behaviors.

Without this rich contextual information provided by headers, api communication would be rudimentary, insecure, and highly inefficient, severely limiting the capabilities of modern interconnected systems.

2. Deciphering the "Where": Contexts for Request Headers

The process of writing or defining API request headers isn't confined to a single environment or tool. Instead, it permeates every layer of the api interaction, from the application initiating the call to the intermediate infrastructure that processes and routes it. Understanding these diverse contexts is key to effective header management and troubleshooting.

2.1 Client-Side Applications: The Initiators

The most common place where request headers are explicitly defined is within the client-side application that originates the api call. This could be a web browser, a mobile application, a desktop program, or even another server-side service acting as a client.

2.1.1 Web Browsers (Frontend JavaScript)

In modern web development, JavaScript running in a browser is a primary engine for making api requests. The Fetch API and the older XMLHttpRequest (XHR) object are the two dominant methods. Both provide mechanisms to add custom headers to outgoing requests.

• Fetch API: The fetch() function is the modern, promise-based way to make network requests. Headers are passed as an object within the init options.javascript fetch('https://api.example.com/data', { method: 'POST', headers: { 'Content-Type': 'application/json', 'Authorization': 'Bearer YOUR_JWT_TOKEN', 'X-Custom-Header': 'MyValue' }, body: JSON.stringify({ name: 'Alice', age: 30 }) }) .then(response => response.json()) .then(data => console.log(data)) .catch(error => console.error('Error:', error));Here, 'Content-Type', 'Authorization', and 'X-Custom-Header' are explicitly defined in the headers object. The browser automatically adds other standard headers like Host, User-Agent, Accept, and sometimes Origin (especially for CORS requests).
• XMLHttpRequest (XHR): While less common for new development, XHR is still widely used in older codebases. Headers are set using the setRequestHeader() method.```javascript const xhr = new XMLHttpRequest(); xhr.open('GET', 'https://api.example.com/items', true); xhr.setRequestHeader('Authorization', 'Bearer YOUR_JWT_TOKEN'); xhr.setRequestHeader('Accept', 'application/json');xhr.onload = function() { if (xhr.status >= 200 && xhr.status < 300) { console.log(JSON.parse(xhr.responseText)); } else { console.error('Request failed:', xhr.status, xhr.statusText); } }; xhr.onerror = function() { console.error('Network error occurred'); }; xhr.send(); ```Each setRequestHeader() call adds a new header. It's important to set headers after open() but before send().

2.1.2 Mobile Applications (iOS, Android SDKs)

Mobile applications, whether native or cross-platform, also rely on network requests to communicate with backend APIs. The underlying SDKs provide robust mechanisms for header management.

• iOS (Swift/Objective-C): URLSession is the primary API for networking. URLRequest objects encapsulate all details of a request, including headers.```swift import Foundationvar request = URLRequest(url: URL(string: "https://api.example.com/profile")!) request.httpMethod = "GET" request.setValue("application/json", forHTTPHeaderField: "Accept") request.setValue("Bearer YOUR_AUTH_TOKEN", forHTTPHeaderField: "Authorization")let task = URLSession.shared.dataTask(with: request) { data, response, error in guard let data = data, error == nil else { print("Error: (error?.localizedDescription ?? "Unknown error")") return } if let httpResponse = response as? HTTPURLResponse { print("Status Code: (httpResponse.statusCode)") // Process data } } task.resume() ```

Android (Kotlin/Java with OkHttp/Retrofit): Libraries like OkHttp (a robust HTTP client) and Retrofit (a type-safe HTTP client for Android and Java) simplify api interactions and header management.```kotlin import okhttp3.OkHttpClient import okhttp3.Request import okhttp3.RequestBody.Companion.toRequestBodyval client = OkHttpClient() val request = Request.Builder() .url("https://api.example.com/users") .header("Content-Type", "application/json") .header("Authorization", "Bearer YOUR_AUTH_TOKEN") .post("{ \"name\": \"Bob\" }".toRequestBody()) .build()client.newCall(request).enqueue(object : okhttp3.Callback { override fun onFailure(call: okhttp3.Call, e: java.io.IOException) { e.printStackTrace() }

override fun onResponse(call: okhttp3.Call, response: okhttp3.Response) {
    response.body?.string()?.let {
        println(it)
    }
}

}) ```

2.1.3 Desktop Applications & Server-Side Scripts

Applications running on desktops or backend servers making api calls also construct headers. The methods vary based on the programming language and chosen HTTP client library.

• Python (requests library): The requests library is incredibly popular for its simplicity and power. Headers are passed as a dictionary.```python import requestsheaders = { 'Content-Type': 'application/json', 'Authorization': 'Bearer YOUR_AUTH_TOKEN', 'User-Agent': 'MyPythonApp/1.0' } data = {"item": "new_item", "quantity": 5}response = requests.post('https://api.example.com/inventory', headers=headers, json=data)print(f"Status Code: {response.status_code}") print(f"Response: {response.json()}") ```
• Node.js (Built-in http/https module or axios): Node.js provides core modules for HTTP, but axios is a widely preferred third-party library.```javascript const axios = require('axios');axios.get('https://api.example.com/status', { headers: { 'Accept': 'application/json', 'X-Trace-ID': 'unique-request-identifier' } }) .then(response => { console.log(response.data); }) .catch(error => { console.error('Error:', error.message); }); ```

2.1.4 Command-line Tools (cURL)

For quick testing, debugging, or scripting, cURL is an indispensable command-line tool. It offers direct control over all aspects of an HTTP request, including headers, using the -H or --header flag.

curl -X POST \
  https://api.example.com/orders \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer YOUR_AUTH_TOKEN' \
  -d '{"product_id": "P123", "quantity": 2}'

Each -H flag specifies a single header. cURL is an excellent tool for understanding the raw HTTP request structure.

2.2 Server-Side Proxies and Gateways: The Interceptors

Beyond the initiating client, request headers often pass through a gauntlet of intermediary services before reaching their final destination. These services, such as reverse proxies, load balancers, and especially api gateway solutions, can inspect, modify, add, or remove headers. This is a crucial layer where headers can be enriched for internal routing, security, or logging purposes without the client needing to be aware of these internal mechanisms.

2.2.1 Reverse Proxies (Nginx, Apache)

Reverse proxies sit in front of one or more web servers, forwarding client requests to the appropriate backend server. They can be configured to add or modify headers, which is incredibly useful for: * Adding client IP information: X-Forwarded-For and X-Real-IP are common headers added by proxies to tell the backend the original client's IP address, as the proxy itself makes the request. * Host header modification: Ensuring the correct Host header is sent to the backend. * Security features: Blocking requests based on certain header values. * Caching directives: Modifying Cache-Control headers.

Example Nginx configuration to add a header:

server {
    listen 80;
    server_name api.mydomain.com;

    location / {
        proxy_pass http://backend_servers;
        proxy_set_header X-Proxied-By Nginx; # Adds a custom header
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

2.2.2 Load Balancers

Load balancers distribute incoming api traffic across multiple servers to ensure high availability and scalability. Like reverse proxies, they often add headers, primarily for tracking and identifying the client or the load balancer itself. These might include X-Forwarded-Proto (to indicate if the original request was HTTP or HTTPS) or specific load balancer IDs.

2.2.3 API Gateway

An api gateway is a specialized type of reverse proxy that acts as a single entry point for a group of APIs. It's a powerful tool for api management, handling tasks like authentication, authorization, rate limiting, traffic management, monitoring, and logging. The api gateway is a prime location for manipulating headers.

• Authentication and Authorization: Gateways often validate Authorization headers (e.g., JWT tokens, api keys) and can add internal headers to forward user IDs or roles to backend services, avoiding repetitive authentication checks.
• Traffic Routing: Headers can be used to route requests to specific versions of an api (e.g., X-API-Version: v2) or to different microservices based on client type or feature flags.
• Rate Limiting: Gateways might inspect headers like X-Client-ID to apply rate limits.
• Logging and Tracing: Gateways can inject correlation IDs (e.g., X-Request-ID) into requests, ensuring that all subsequent calls within a distributed transaction carry the same ID for end-to-end tracing across various microservices and logs.
• Content Transformation: In some cases, gateways can transform headers or even the request body itself before forwarding it to the backend.

For robust api lifecycle management, including sophisticated header handling, authentication, and traffic control, platforms like APIPark become indispensable. APIPark, an open-source AI gateway and API management platform, allows developers and enterprises to easily manage, integrate, and deploy AI and REST services. It unifies api invocation formats, encapsulates prompts into REST APIs, and offers end-to-end api lifecycle management, ensuring that headers are properly managed for security, routing, and operational efficiency. APIPark's ability to provide "Independent API and Access Permissions for Each Tenant" and enforce "API Resource Access Requires Approval" relies heavily on its intelligent processing of request headers to determine access rights and route requests accordingly. Its "Detailed API Call Logging" also leverages headers for comprehensive tracking and debugging. Discover more at ApiPark.

2.3 Development Tools and Environments

Finally, various development tools provide intuitive interfaces for defining and inspecting headers, simplifying the development and debugging process.

2.3.1 API Testing Tools (Postman, Insomnia)

Tools like Postman and Insomnia are designed specifically for api development and testing. They offer user-friendly graphical interfaces to construct requests, including dedicated sections for adding and managing headers. You can easily add, edit, enable, or disable headers, making it simple to test various scenarios like authenticated vs. unauthenticated requests, different content types, or custom header-based routing.

2.3.2 Browser Developer Tools

Every modern web browser comes with a suite of developer tools. The "Network" tab is invaluable for inspecting HTTP requests made by a web application. You can view all outgoing requests, click on a specific request, and then examine its request headers (and response headers). This is crucial for debugging why an api call might be failing or behaving unexpectedly, allowing you to verify that the correct headers are being sent from the client-side JavaScript.

2.3.3 IDEs (Integrated Development Environments)

Many IDEs and text editors, especially those popular for web development like VS Code, offer extensions that allow api testing directly within the editor. These extensions often support a similar interface to Postman or cURL, enabling developers to define request headers within a .http file or a dedicated panel.

In summary, request headers are defined and potentially modified at multiple stages of an api interaction. From the initial client application that crafts the request to the intermediary services like api gateway solutions that process and forward it, headers play a dynamic and critical role in shaping the communication flow.

3. The "How": Crafting and Manipulating Request Headers

Having explored where request headers are defined, we now turn our attention to the how. This section will detail the most common and essential request headers, their purpose, typical values, and provide practical examples across different programming contexts. Mastery of these headers is crucial for building robust, secure, and efficient api integrations.

3.1 Common Request Headers Explained

The HTTP specification defines a multitude of standard headers, each serving a specific purpose. Additionally, developers can define custom headers for application-specific needs.

Here's a breakdown of some of the most frequently encountered and critical request headers:

3.1.1 Content-Type

• Purpose: Informs the server about the media type of the request body. This is essential for POST, PUT, and PATCH requests where data is being sent to the server. Without this, the server wouldn't know how to parse the incoming data.
• Typical Values:
  • application/json: Most common for modern REST APIs. The body is a JSON string.
  • application/x-www-form-urlencoded: Used for submitting simple form data, where key-value pairs are URL-encoded.
  • multipart/form-data: Used for submitting forms that contain files, where each part (field or file) is separated by a boundary string.
  • text/plain: For plain text bodies.
  • application/xml: For XML bodies.
• Example Usage: When sending a JSON object to create a resource. json Content-Type: application/json

3.1.2 Accept

• Purpose: Informs the server about the media types that the client is willing to accept in the response. This enables content negotiation, where the server can choose the best representation of the resource based on client preferences.
• Typical Values:
  • application/json: Client prefers JSON response.
  • application/xml: Client prefers XML response.
  • text/html: Client prefers HTML response.
  • */*: Wildcard, client accepts any media type.
  • application/vnd.example.v2+json: Often used for API versioning (see advanced concepts).
• Example Usage: Requesting a JSON response. json Accept: application/json

3.1.3 Authorization

• Purpose: Carries credentials that authenticate a user agent with a server. This is one of the most critical headers for api security.
• Typical Values (Schemes):
  • Bearer <token>: Most common for modern REST APIs, where <token> is typically a JSON Web Token (JWT) or an opaque access token issued after an OAuth2 flow.
  • Basic <credentials>: Base64-encoded username:password. Less secure over plain HTTP, often used for internal services or initial client registration.
  • Digest <parameters>: A more secure challenge-response mechanism than Basic, though less common in REST APIs today.
  • APIKey <key>: Some APIs use a simple APIKey prefix with a raw key, or a custom header name like X-API-Key.
• Example Usage: Sending a JWT for authentication. json Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c Note: The token shown is a dummy example.

3.1.4 User-Agent

• Purpose: Identifies the user agent (client software) making the request. This can be useful for server-side analytics, debugging, or delivering specific content tailored to different clients (though Accept is generally preferred for content negotiation).
• Typical Values:
  • Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36 (Web browser)
  • curl/7.81.0 (cURL client)
  • PostmanRuntime/7.29.2 (Postman)
  • MyAwesomePythonApp/1.0 (Python 3.9) (Custom application)
• Example Usage: Identifying a custom client application. json User-Agent: MyApp/1.0 (Windows; MyCompany; internal)

3.1.5 Cache-Control & Pragma

• Purpose: Directives for caching mechanisms. Cache-Control is the more modern and flexible header. Pragma: no-cache is an older, HTTP/1.0 directive for backward compatibility.
• Typical Values (Cache-Control):
  • no-cache: Must revalidate with the server before using a cached copy.
  • no-store: Do not cache any part of the request or response.
  • max-age=<seconds>: Specifies the maximum amount of time a resource is considered fresh.
  • public: Cacheable by any cache.
  • private: Cacheable only by private caches (e.g., browser cache).
• Example Usage: Preventing caching for sensitive data. json Cache-Control: no-cache, no-store, must-revalidate Pragma: no-cache

3.1.6 Host

• Purpose: Specifies the domain name of the server (for virtual hosting) and optionally the port number. This header is mandatory for HTTP/1.1 requests.
• Typical Values:
  • api.example.com
  • localhost:8080
• Example Usage: Automatically added by clients based on the URL. json Host: api.example.com

3.1.7 Origin & Referer

• Purpose:
  • Origin: Indicates the origin (scheme, hostname, port) from which the request was initiated. Crucial for Cross-Origin Resource Sharing (CORS) security checks, especially for POST, PUT, DELETE requests or requests with custom headers.
  • Referer: (Note the misspelling in the spec) Indicates the URL of the page that linked to the resource being requested. Useful for analytics and logging, but can have privacy implications.
• Typical Values:
  • Origin: https://www.mywebapp.com
  • Referer: https://www.mywebapp.com/dashboard
• Example Usage: Automatically added by browsers. json Origin: https://clientapp.com Referer: https://clientapp.com/login-page

3.1.8 If-Modified-Since & If-None-Match (Conditional Requests)

• Purpose: Used for conditional requests to optimize bandwidth and performance.
  • If-Modified-Since: If the resource has not been modified since the specified date, the server should return a 304 Not Modified status code without a response body.
  • If-None-Match: If the ETag (a unique identifier for a specific version of a resource) of the requested resource matches any of the values in this header, the server should return 304 Not Modified.
• Typical Values:
  • If-Modified-Since: Tue, 15 Nov 1994 12:45:26 GMT
  • If-None-Match: "abcdef12345"
• Example Usage: json If-None-Match: "v1.2.3-hash"

3.1.9 X-Request-ID (Custom Header for Tracing)

• Purpose: While not a standard HTTP header, X-Request-ID (or similar variants like X-Correlation-ID) is widely adopted as a custom header for tracing requests across distributed systems, especially in microservices architectures. An api gateway or the first service encountered typically generates a unique ID and attaches it to the request. This ID is then propagated to all downstream services, allowing for end-to-end logging and debugging.
• Typical Values: A UUID or a similar unique string.
• Example Usage: json X-Request-ID: d290f1ee-6c54-4b01-90e6-d701748f0851

3.1.10 Custom Headers

• Purpose: To convey application-specific metadata not covered by standard HTTP headers. These often start with X- (e.g., X-API-Version, X-Client-Type), although this convention is becoming less common as IETF discourages it for non-standardized headers. It's often better to simply use descriptive names.
• Best Practices:
  • Use meaningful, descriptive names.
  • Document all custom headers in your API documentation (e.g., using OpenAPI).
  • Avoid sensitive information unless encrypted or protected.
  • Be mindful of potential conflicts with future standard headers.
• Example Usage: json X-API-Version: 2.0 My-Custom-Feature-Flag: enabled

Here's a summary table of common request headers:

Header Name	Purpose	Typical Values	Contexts
Content-Type	Specifies the media type of the request body (for POST/PUT).	application/json, application/x-www-form-urlencoded, multipart/form-data	Client-side (JS, Python, Mobile), api gateway (if body transformation)
Accept	Indicates client's preferred media types for the response.	application/json, application/xml, text/html, */*	Client-side (JS, Python, Mobile)
Authorization	Carries authentication credentials (e.g., API keys, JWTs).	Bearer <token>, Basic <credentials>	Client-side (JS, Python, Mobile), api gateway (for validation and forwarding)
User-Agent	Identifies the client software making the request.	Browser strings, curl/<version>, PostmanRuntime/<version>, YourAppName/<version>	Client-side (JS, Python, Mobile), automatically added by tools
Cache-Control	Directives for caching mechanisms.	no-cache, no-store, max-age=3600, public, private	Client-side (controlling browser cache), api gateway (influencing upstream caching)
Host	Specifies the domain name of the server and optional port. (Mandatory for HTTP/1.1)	api.example.com, localhost:8080	Automatically added by clients, modified by proxies/load balancers
Origin	Indicates the origin of the request (for CORS security).	https://clientapp.com	Automatically added by browsers for cross-origin requests
Referer	The URL of the page that linked to the requested resource.	https://previous-page.com/path	Automatically added by browsers (can be removed by security configurations)
If-None-Match	Makes request conditional on ETag not matching cached version (for caching).	"some-etag-value"	Client-side (when making conditional requests to optimize bandwidth)
X-Request-ID	(Custom) Unique identifier for tracing requests across distributed systems.	UUID string (e.g., d290f1ee-...)	api gateway (injects), Client-side (if provided by upstream), Backend services (propagates)
X-API-Key	(Custom) Often used for simple API key authentication.	YOUR_API_KEY_STRING	Client-side, api gateway (for validation)
X-API-Version	(Custom) Specifies the desired API version.	1.0, 2.1	Client-side (to target specific API version), api gateway (for routing)

3.2 Practical Examples Across Languages and Tools

Let's illustrate how to implement these headers in various common development environments.

3.2.1 JavaScript (Browser - Fetch API)

// Example: Authenticated POST request with JSON payload
const dataToSend = {
    firstName: 'Jane',
    lastName: 'Doe',
    email: 'jane.doe@example.com'
};

fetch('https://api.example.com/users', {
    method: 'POST',
    headers: {
        'Content-Type': 'application/json',
        'Authorization': 'Bearer YOUR_ACTUAL_JWT_TOKEN', // Replace with a real token
        'Accept': 'application/json',
        'X-Client-App': 'WebApp-V1.0' // Custom header
    },
    body: JSON.stringify(dataToSend)
})
.then(response => {
    if (!response.ok) {
        // Handle HTTP errors
        return response.text().then(text => { throw new Error(text) });
    }
    return response.json();
})
.then(data => {
    console.log('User created:', data);
})
.catch(error => {
    console.error('Error creating user:', error);
});

• Detail: The headers property within the init object of fetch takes a plain JavaScript object where keys are header names (case-insensitive, but commonly camelCase or kebab-case) and values are their strings. The browser automatically handles Host, Content-Length, User-Agent, and potentially Origin. For CORS preflight requests (OPTIONS method), the browser adds Access-Control-Request-Method and Access-Control-Request-Headers as well.

3.2.2 Python (requests library)

import requests
import json

# Example: GET request with custom headers
headers = {
    'Accept': 'application/json',
    'User-Agent': 'MyPythonScript/1.0',
    'Authorization': 'Bearer YOUR_ACTUAL_JWT_TOKEN_PYTHON',
    'X-Debug-Mode': 'true'
}

response = requests.get('https://api.example.com/products/123', headers=headers)

if response.status_code == 200:
    print("Product details:")
    print(json.dumps(response.json(), indent=2))
else:
    print(f"Failed to fetch product. Status: {response.status_code}, Response: {response.text}")

# Example: POST request with JSON payload and specific content type
post_data = {
    "name": "New Widget",
    "price": 29.99,
    "category": "electronics"
}
post_headers = {
    'Content-Type': 'application/json',
    'Authorization': 'Bearer YOUR_ACTUAL_JWT_TOKEN_PYTHON',
}

post_response = requests.post('https://api.example.com/products', headers=post_headers, json=post_data)

if post_response.status_code == 201: # Created
    print("Product created successfully:")
    print(json.dumps(post_response.json(), indent=2))
else:
    print(f"Failed to create product. Status: {post_response.status_code}, Response: {post_response.text}")

• Detail: The requests library accepts a Python dictionary for the headers argument. This is highly intuitive. For POST/PUT requests, if you use the json argument, requests automatically sets the Content-Type header to application/json. If you use the data argument with a dictionary, it defaults to application/x-www-form-urlencoded. Explicitly setting Content-Type is often good practice if you're handling the body yourself.

3.2.3 Node.js (axios library)

const axios = require('axios');

// Example: GET request with versioning header
axios.get('https://api.example.com/users', {
    headers: {
        'Accept': 'application/json',
        'X-API-Version': '2.0', // Request specific API version
        'Authorization': 'Bearer YOUR_ACTUAL_JWT_TOKEN_NODE'
    }
})
.then(response => {
    console.log('Users (v2.0):', response.data);
})
.catch(error => {
    console.error('Error fetching users:', error.message);
});

// Example: PATCH request for partial update
const patchData = {
    "status": "active"
};

axios.patch('https://api.example.com/orders/456', patchData, {
    headers: {
        'Content-Type': 'application/json',
        'Authorization': 'Bearer YOUR_ACTUAL_JWT_TOKEN_NODE',
        'X-Trace-Id': 'node-app-12345' // Custom tracing ID
    }
})
.then(response => {
    console.log('Order 456 updated:', response.data);
})
.catch(error => {
    console.error('Error updating order:', error.message);
});

• Detail: axios also uses a headers object within its configuration. For GET and DELETE requests, headers are passed as an optional third argument. For POST, PUT, PATCH, the data body is the second argument, and headers are the third. axios is generally robust in handling Content-Type automatically when JSON objects are passed as data.

3.2.4 Command-line Tools (cURL)

# Example: Basic GET request with Accept header
curl -X GET \
  https://api.example.com/health \
  -H 'Accept: application/json'

# Example: Authenticated POST request with JSON body
curl -X POST \
  https://api.example.com/products \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer YOUR_ACTUAL_JWT_TOKEN_CURL' \
  -d '{
        "name": "Super Gadget",
        "description": "An amazing new gadget.",
        "price": 99.99
      }'

# Example: Conditional GET request using If-None-Match
# Assume previous ETag was "abcdef123"
curl -X GET \
  https://api.example.com/data-resource \
  -H 'If-None-Match: "abcdef123"'

• Detail: cURL is explicit. Each header must be specified with a -H or --header flag, followed by the header name and its value separated by a colon (e.g., Header-Name: Header-Value). The -d flag is used for the request body, automatically setting Content-Type to application/x-www-form-urlencoded if not explicitly set. If you provide JSON with -d, you must manually specify Content-Type: application/json.

3.2.5 API Testing Tools (Postman)

In tools like Postman, you interact with a graphical interface:

1. Select Method & Enter URL: Choose GET, POST, etc., and type your API endpoint URL.
2. Navigate to Headers Tab: Click on the "Headers" tab below the URL input.
3. Add Key-Value Pairs: You'll see two input fields for each header: "Key" and "Value".
   • Type Content-Type in "Key", application/json in "Value".
   • Type Authorization in "Key", Bearer YOUR_TOKEN in "Value".
   • Postman often suggests common headers as you type.
4. Add Body (if applicable): If it's a POST/PUT/PATCH request, go to the "Body" tab, select "raw" and "JSON", then type or paste your JSON payload.
5. Send Request: Click the "Send" button.
6. Detail: Postman simplifies header management by providing a clear UI. It also handles certain boilerplate, like Content-Length (if a body is present), and Host. It's a great tool for quickly testing various header combinations without writing code.

These examples highlight that while the syntax for defining headers varies across technologies, the core concept remains consistent: headers are key-value pairs that convey essential metadata to control api communication.

APIPark is a high-performance AI gateway that allows you to securely access the most comprehensive LLM APIs globally on the APIPark platform, including OpenAI, Anthropic, Mistral, Llama2, Google Gemini, and more.Try APIPark now! 👇👇👇

4. Advanced Concepts and Best Practices

Moving beyond the basic mechanics, understanding advanced header concepts and adhering to best practices is vital for building resilient, secure, and maintainable api ecosystems.

4.1 Security Considerations for Headers

Headers are often the first line of defense and a common vector for security vulnerabilities if not handled carefully.

• Sensitive Data: Never put highly sensitive data like plain text passwords or private keys directly into headers.
  • Authorization: Always use secure schemes like Bearer tokens (JWTs) obtained via OAuth2, api keys (managed and rotated securely), or robust signature-based authentication. Ensure tokens have limited lifetimes and scopes.
  • Custom Headers: Be cautious about what information is placed in custom headers. If it's proprietary or sensitive, ensure the connection is always HTTPS, and consider encryption if the header traverses untrusted networks.
• CORS (Origin Header): Cross-Origin Resource Sharing (CORS) is a browser security feature that prevents web pages from making requests to a different domain than the one from which the web page was served, unless explicitly allowed by the server. The Origin request header plays a central role here.
  • When a browser makes a cross-origin request, it includes the Origin header. The server then responds with Access-Control-Allow-Origin (and other Access-Control-* headers) if it permits the request.
  • Misconfiguring CORS headers on the server (e.g., allowing * for Access-Control-Allow-Origin when it's not intended) can expose your api to cross-site request forgery (CSRF) or data exfiltration from malicious websites.
• Header Injection: Similar to SQL injection, if server-side code constructs HTTP responses (or proxy headers) by directly concatenating user-provided input without proper sanitization, an attacker could inject malicious headers (e.g., Set-Cookie to hijack sessions, or Location for redirection attacks). Always sanitize and validate any user input used to construct headers.
• API Gateway for Enhanced Security: An api gateway is a critical component for enforcing api security policies centrally.
  • It can validate Authorization headers, reject invalid or expired tokens, and apply rate limiting based on client credentials extracted from headers.
  • It can strip sensitive headers from requests before forwarding them to internal services.
  • It can add security-related headers to responses (e.g., Strict-Transport-Security, Content-Security-Policy).
  • Platforms like APIPark offer robust security features, including api access approval workflows and independent permissions per tenant, directly leveraging header analysis for granular control and preventing unauthorized access.

4.2 Performance Optimization with Headers

Headers can significantly impact the perceived and actual performance of your api by reducing unnecessary data transfer.

• Caching Headers (Cache-Control, If-Modified-Since, If-None-Match): These headers are paramount for efficient caching.
  • By sending If-None-Match with a previously received ETag or If-Modified-Since with a timestamp, the client can ask the server: "Has this resource changed?" If not, the server responds with a 304 Not Modified status code, sending no body, saving significant bandwidth and processing power.
  • The Cache-Control header in responses dictates how proxies and clients should cache the resource, preventing redundant requests altogether.
• Compression (Accept-Encoding): The client can signal its ability to handle compressed responses using Accept-Encoding.
  • Accept-Encoding: gzip, deflate, br tells the server the client supports Gzip, Deflate, or Brotli compression. The server, if it supports compression, will compress the response body and add a Content-Encoding: gzip header to the response, drastically reducing payload size.
• Range Requests (Range): For large files or media, the client can request only a portion of the resource using the Range header (e.g., Range: bytes=0-499). This allows for resuming downloads or streaming media efficiently. The server responds with 206 Partial Content and a Content-Range header.

4.3 Idempotency: Idempotency-Key Header

• Purpose: For non-idempotent operations (like creating a new resource or processing a payment) that might be retried due to network issues, a client can include an Idempotency-Key header (often a UUID).
• Mechanism: If the server receives a request with an Idempotency-Key it has already processed, it should return the original response from the first successful attempt instead of processing the request again. This prevents duplicate resource creation or double charges, ensuring consistency even with retries.
• Example: json Idempotency-Key: a1b2c3d4-e5f6-7890-1234-567890abcdef

4.4 Version Control with Headers

Managing api versions is a critical aspect of api evolution. Headers provide a flexible way to specify the desired version.

• Custom Header: A common approach is to use a custom header like X-API-Version. json X-API-Version: 2.0 This allows the api gateway or backend to route the request to the correct version of the service.
• Accept Header (Content Negotiation): A more RESTful approach leverages content negotiation. json Accept: application/vnd.example.v2+json Here, vnd.example.v2+json indicates that the client wants version 2 of the example vendor's JSON media type. This is explicitly supported by HTTP's content negotiation mechanism.

4.5 Error Handling and Debugging with Headers

Headers are invaluable for troubleshooting and understanding api behavior.

• Inspecting Response Headers: When an api call fails, examining the response headers can provide crucial clues. Headers like Content-Type (is the error message in the expected format?), Retry-After (for 429 Too Many Requests or 503 Service Unavailable), or custom error headers can guide debugging.
• Custom Error Headers: Servers can include custom headers in error responses to provide more context (e.g., X-Error-Code, X-Troubleshooting-Guide-Link).
• Tracing IDs (X-Request-ID): As discussed, X-Request-ID allows operations teams to correlate logs across multiple services, dramatically simplifying the process of diagnosing issues in distributed systems. This is particularly effective when integrated with an api gateway that ensures the ID is propagated correctly.

By thoughtfully applying these advanced concepts and best practices, developers can create api integrations that are not only functional but also secure, performant, and easy to maintain and debug.

5. Headers in the World of API Specifications and Gateways

The utility and management of API request headers extend beyond individual client-server interactions. They are formalized within api specifications and dynamically controlled by api gateway infrastructure, forming a cohesive ecosystem for modern api governance.

5.1 OpenAPI Specification (Swagger): Documenting Header Expectations

The OpenAPI Specification (formerly Swagger) is a language-agnostic, human-readable, and machine-readable interface description language for REST APIs. It allows developers to describe the structure of their APIs, including endpoints, parameters, responses, and critically, headers. Documenting headers in OpenAPI is paramount for several reasons:

• Client SDK Generation: Tools can generate client-side api wrappers in various programming languages directly from an OpenAPI document. For these SDKs to correctly form requests, they need to know which headers are required or optional, their types, and example values.
• Interactive Documentation: OpenAPI-generated documentation (like Swagger UI) allows users to explore and test api endpoints directly in a browser. This includes forms for inputting header values, providing a clear interface for api consumers.
• Validation: An OpenAPI document can serve as a contract. api gateways or validation tools can use this specification to validate incoming requests, ensuring that all required headers are present and correctly formatted before forwarding the request to the backend.

5.1.1 Defining Headers in OpenAPI

In an OpenAPI (e.g., v3.0) document, headers are typically defined as parameters within an operation (an endpoint for a specific HTTP method) or globally as components/parameters.

Example of Authorization Header Definition:

paths:
  /users:
    get:
      summary: Get all users
      operationId: getAllUsers
      parameters:
        - in: header        # Specifies this is a header parameter
          name: Authorization # The name of the header
          schema:
            type: string
            format: bearer
            example: Bearer eyJhbGciOi... # Example value
          required: true
          description: JWT token for authentication
      responses:
        '200':
          description: List of users
          content:
            application/json:
              schema:
                type: array
                items:
                  $ref: '#/components/schemas/User'

Alternatively, OpenAPI has a dedicated securitySchemes section for authentication headers, which is a more semantically appropriate way to define Authorization requirements:

components:
  securitySchemes:
    bearerAuth:    # A unique name for this security scheme
      type: http
      scheme: bearer
      bearerFormat: JWT
      description: Enter JWT Bearer token **_only_**

security:          # Apply this scheme globally or per operation
  - bearerAuth: []

paths:
  /users:
    get:
      summary: Get all users
      operationId: getAllUsers
      # No need to define Authorization in parameters here if using security scheme
      responses:
        '200':
          description: List of users
          # ...

Example of Custom Header Definition:

paths:
  /reports:
    post:
      summary: Generate a report
      operationId: generateReport
      parameters:
        - in: header
          name: X-Report-Format # Custom header for desired report format
          schema:
            type: string
            enum: [pdf, csv, json]
            default: json
          description: Desired output format for the report
      requestBody:
        # ...
      responses:
        # ...

By meticulously documenting all headers in the OpenAPI specification, api providers ensure clarity, reduce integration friction, and enable automated tooling for both consumers and producers of the api.

5.2 The Role of an API Gateway: Centralized Header Management

An api gateway is a fundamental architectural component in modern microservices and api-driven environments. It acts as a single, intelligent entry point for all api requests, abstracting the complexity of the backend services from the clients. Its role in managing and leveraging request headers is exceptionally significant, often taking on responsibilities that would otherwise burden individual backend services or clients.

5.2.1 Core Functions of an API Gateway

An api gateway typically performs a variety of functions that heavily involve headers:

• Request Routing: Directing incoming requests to the appropriate backend service based on the URL path, host, or specific headers.
• Authentication & Authorization: Validating Authorization headers (e.g., JWTs, api keys) and often transforming these into internal user IDs or roles that are then forwarded to backend services via new internal headers.
• Rate Limiting: Controlling the number of requests a client can make within a given time frame, often identifying clients via headers like Authorization or custom X-Client-ID.
• Traffic Management: Implementing circuit breakers, retries, and load balancing, sometimes influencing routing based on headers like X-Priority.
• Logging & Monitoring: Capturing detailed information about api calls, often enriching logs with header data, and propagating tracing headers like X-Request-ID.
• Header Transformation: Adding, removing, or modifying headers as requests pass through. This can be for security, internal routing, or protocol translation.
• Protocol Translation: Translating between different protocols (e.g., HTTP/1.1 to gRPC).

5.2.2 How Gateways Interact with Headers

API gateways are uniquely positioned to exert control over the entire header lifecycle:

1. Header Validation: Before forwarding, a gateway can check for the presence and validity of required headers (e.g., an Authorization token, a specific X-API-Version). Invalid requests can be rejected early, reducing load on backend services.
2. Header Injection: Gateways often add new headers to requests before sending them to backend services.
   • X-Request-ID: To enable end-to-end tracing.
   • X-Forwarded-For, X-Forwarded-Proto: To inform backend services about the original client's IP address and protocol, especially when the gateway terminates SSL.
   • Internal Authorization headers: After validating a client's Authorization header, the gateway might inject a more lightweight internal token or user ID header (X-Internal-User-ID) for backend services.
3. Header Modification/Stripping:
   • Sensitive headers (e.g., raw api keys) might be stripped before requests reach internal services to enhance security.
   • Outdated or irrelevant headers from the client might be removed to keep requests lean.
   • Headers might be transformed to meet internal api standards.
4. Content Negotiation & Versioning: Gateways can interpret Accept or X-API-Version headers to route requests to specific versions of a service or to apply different policies.
5. Caching: Gateways can act as a caching layer, using Cache-Control and conditional request headers (If-None-Match) to serve cached responses directly without hitting backend services, significantly improving performance.

5.2.3 APIPark: An Open Source AI Gateway & API Management Platform

As discussed previously, platforms like APIPark exemplify the power and utility of an api gateway in managing request headers within a broader api ecosystem. APIPark, being an open-source AI gateway and API management platform, provides a comprehensive solution for managing the entire api lifecycle, with significant implications for header handling.

APIPark integrates seamlessly into development workflows, offering features that directly or indirectly leverage smart header management:

• Unified API Format & Prompt Encapsulation: By standardizing invocation formats and encapsulating AI prompts into REST APIs, APIPark ensures that client requests (and their headers) are consistent, regardless of the underlying AI model. The gateway can intelligently add or modify headers to route requests to the correct AI service and apply model-specific configurations.
• End-to-End API Lifecycle Management: From design to publication and invocation, APIPark helps regulate api management processes. This includes defining and enforcing header policies, ensuring that api contracts (potentially defined via OpenAPI) are respected. For instance, api gateway policies on APIPark could dictate that an X-Client-ID header must be present for a particular api or that a Bearer token must be validated against an identity provider.
• API Resource Access Requires Approval & Independent Permissions: APIPark's advanced security features rely heavily on intelligently processing request headers. When a client makes a request, the api gateway inspects headers like Authorization or X-API-Key to identify the caller. It then references internal configurations managed by APIPark to determine if the caller has the necessary subscriptions and permissions for that specific api resource. This granular access control, per tenant or application, is fundamentally driven by header-based identity verification.
• Detailed API Call Logging: APIPark records every detail of each api call. This includes all request headers, response headers, and bodies. This comprehensive logging is critical for debugging, security auditing, and performance analysis. By capturing headers, businesses can trace the full context of a request, understand authentication failures, or see how caching directives were applied.
• Performance and Scalability: By efficiently handling header validation, routing, and transformation at the gateway level, APIPark offloads these concerns from backend services, allowing them to focus purely on business logic. This contributes to APIPark's impressive performance, rivaling Nginx, and its ability to support cluster deployment for large-scale traffic.

In essence, an api gateway like APIPark elevates header management from a low-level coding detail to a strategic api governance capability. It centralizes control, enhances security, optimizes performance, and provides invaluable visibility into api traffic, making it an indispensable tool for enterprises managing complex api landscapes.

Conclusion

API request headers are far from incidental components of web communication; they are the silent, yet powerful, architects of effective and secure api interactions. Throughout this extensive exploration, we've peeled back the layers to reveal the intricate world of these metadata fields, from their fundamental role in defining an HTTP request to their sophisticated orchestration across diverse technological landscapes.

We began by understanding the core anatomy of an api request, firmly establishing headers as critical context-keepers that dictate everything from authentication and content type to caching strategies. This foundational knowledge set the stage for our journey into the "where" of header definition. We saw that whether you're building a sleek frontend with JavaScript's Fetch API, a robust backend service in Python, a mobile application leveraging native SDKs, or scripting with cURL, the mechanisms for crafting headers are pervasive and integral to the development process. Furthermore, we illuminated the crucial role of intermediary services like reverse proxies and, most notably, api gateways, in inspecting, modifying, and injecting headers, often enriching requests with vital operational or security metadata.

Our deep dive into the "how" provided a practical toolkit, dissecting common request headers such as Content-Type, Authorization, Accept, and Cache-Control. We explored their specific purposes and demonstrated their implementation across various programming languages and development tools, equipping you with the hands-on knowledge to wield them effectively. Moving into advanced concepts, we underscored the profound impact of headers on api security, performance, and versioning, emphasizing the strategic advantage of employing Idempotency-Key headers for reliability and X-Request-ID for comprehensive tracing.

Finally, we connected the dots to the broader api ecosystem, highlighting how headers are formalized within OpenAPI specifications to ensure clear documentation and automated tooling. Critically, we delved into the transformative role of an api gateway as a centralized hub for header management, authentication, routing, and logging. Platforms like APIPark stand as prime examples, demonstrating how an intelligent api gateway can elevate header handling from a technical detail to a strategic asset, ensuring api security, performance, and governance across complex environments, particularly in the burgeoning field of AI services.

In an ever-evolving digital landscape driven by interconnected services, mastery of API request headers is no longer optional; it is a prerequisite for building applications that are not just functional, but also secure, performant, resilient, and inherently scalable. By understanding their nuances and adhering to best practices, developers and architects can unlock the full potential of api communication, paving the way for the next generation of innovative and reliable digital experiences.

---

Frequently Asked Questions (FAQs)

Q1: What is the primary difference between a request header and a request body?

A1: The primary difference lies in their purpose: * Request Headers carry metadata about the request itself, the client making it, or the desired server behavior. This includes information like content type, authentication credentials, preferred response formats, or caching directives. Headers are key-value pairs and are typically much smaller than the body. * Request Body carries the actual data payload of the request. This is the information being sent to the server for processing, creation, or update (e.g., a JSON object for a new user, a file upload). The body is usually present only for POST, PUT, or PATCH methods and can range in size from a few bytes to gigabytes.

Q2: Why is the Authorization header so crucial for API security, and what are common pitfalls?

A2: The Authorization header is crucial because it conveys the credentials that authenticate the client making the api request, enabling the server to verify the client's identity and determine if they have permission to access the requested resource. Common pitfalls include: 1. Using plain text passwords: Never send passwords directly; always use secure authentication schemes like Bearer tokens (JWTs) or Basic authentication over HTTPS. 2. Hardcoding tokens: Storing api keys or access tokens directly in client-side code (especially public-facing apps) is a security risk. Tokens should be stored securely and retrieved dynamically. 3. Overly permissive tokens: Using tokens with excessive permissions or infinite expiry can lead to widespread compromise if leaked. Implement minimal privilege and short-lived tokens. 4. Lack of HTTPS: Sending Authorization headers over plain HTTP exposes credentials to eavesdropping, making HTTPS mandatory for any api dealing with sensitive data.

Q3: How do Content-Type and Accept headers work together in content negotiation?

A3: Content-Type and Accept headers work in tandem for content negotiation, allowing clients and servers to agree on the format of data exchange: * Content-Type (Request Header): Sent by the client to tell the server what format the request body is in (e.g., application/json for a JSON payload). The server uses this to correctly parse the incoming data. * Accept (Request Header): Sent by the client to tell the server what format(s) it prefers for the response body (e.g., application/json to receive JSON data). The server then tries to send the response in one of the client's preferred formats, indicating its choice with the Content-Type header in its response. If the server cannot provide any of the preferred formats, it might return a 406 Not Acceptable status.

Q4: Can I create my own custom headers, and are there any best practices for doing so?

A4: Yes, you can create your own custom headers. While the old convention was to prefix them with X- (e.g., X-API-Version), this practice is now discouraged by the IETF for non-standardized headers to avoid potential conflicts with future official HTTP headers. Best Practices: 1. Descriptive Naming: Use clear, descriptive names that reflect the header's purpose (e.g., Api-Version instead of X-Api-Version). 2. Documentation: Always document all custom headers thoroughly in your api specification (e.g., OpenAPI) to inform api consumers. 3. Purpose-Driven: Only use custom headers for application-specific metadata that isn't covered by existing standard HTTP headers. 4. Security Awareness: Avoid placing sensitive, unencrypted data in custom headers, and always ensure that custom headers are part of your security review process, especially if they carry any form of identifier or control mechanism.

Q5: What is the significance of an api gateway in managing request headers?

A5: An api gateway plays a pivotal role in managing request headers by acting as an intelligent intermediary between clients and backend services. Its significance stems from several capabilities: 1. Centralized Control: It provides a single point to enforce api policies related to headers, such as validating Authorization tokens, applying rate limits based on client IDs (from headers), or checking for specific X-API-Version headers for routing. 2. Header Transformation & Injection: Gateways can add vital headers (e.g., X-Request-ID for tracing, X-Forwarded-For for original client IP) and remove or modify others (e.g., stripping sensitive credentials before forwarding to internal services), streamlining backend communication and enhancing security. 3. Enhanced Security: By offloading authentication and authorization from backend services, the gateway can perform robust header validation and implement granular access controls based on header content, preventing unauthorized access earlier in the request lifecycle. 4. Performance Optimization: Gateways can use headers for intelligent caching decisions or to route requests to optimized service versions, improving overall api performance and responsiveness. Platforms like APIPark exemplify how api gateways effectively manage headers for comprehensive API lifecycle governance, security, and integration, particularly for AI and REST services.

🚀You can securely and efficiently call the OpenAI API on APIPark in just two steps:

Step 1: Deploy the APIPark AI gateway in 5 minutes.

APIPark is developed based on Golang, offering strong product performance and low development and maintenance costs. You can deploy APIPark with a single command line.

curl -sSO https://download.apipark.com/install/quick-start.sh; bash quick-start.sh

In my experience, you can see the successful deployment interface within 5 to 10 minutes. Then, you can log in to APIPark using your account.

Step 2: Call the OpenAI API.