Skip to main content

HTTP headers

Content-Type vs Accept​

The client should always send an Accept header, which indicates the preferred Content-Type format for the response. When including a request body, the client must also send a Content-Type header to specify the format of the data being sent. The server should always return a Content-Type header in its response. For REST APIs, the standard media type for JSON is application/json.

Custom content types are not allowed.

API key​

The client must always include an API key, issued by the API management platform, in the Apikey HTTP header.

Do not send API keys in the URL or as query parameters, as this poses a security risk. The API key identifies the client (app) and should only be used by the application it was created for. API keys can be found in the developer portal under the respective developer app.

To ensure security:

  • API keys should not be shared via email or included in Postman collections.
  • If sharing is necessary, use the same secure methods as for passwords.

Authentication​

Most APIs require user authentication. Clients must authenticate by providing credentials and requesting a token from the Token API (v1/oauth/token).

The acquired access token is used to authenticate requests to other APIs. The access token must be included in the Authorization header as follows:

Authorization: Bearer {access_token}

CORS​

APIs that are accessible from browsers must support Cross-Origin Resource Sharing (CORS) by returning appropriate CORS headers.

Custom headers​

Previously, custom headers were prefixed with X-, such as X-Custom-Header. However, this convention was deprecated in 2012 (see RFC 6648).

Convention: Use meaningful names without the X- prefix.

Example(s):

  • Powered-By: Apikey