Site Options

API: Application Programming Interfaces

The following article gives a brief overview of APIs.

Application Programming Interfaces (APIs) are a set of rules and protocols that allow software programs to communicate with each other. 

Exposing data and actions: APIs limit the actions and data points with which external software can interact.

Sending Requests: When a software system needs to access a resource from another system, it sends a request through an API.

Processing Requests: If the API is authorized, the system processes the request and sends back a response.

APIs use a request-response model. When a client, software, or user sends a request, an API processes it and returns a response.

Testing Content Catalyst API's

The administration portal contains the APIs available for use with Content Catalyst, documentation, and a testing area.

Admins can head to this area via the welcome page seen below.

Status Codes 

APIs use status codes to inform the client or user of the results per request.

These are the common status codes that can occur when using Content Catalyst APIs.

200: A 200 code means the server has successfully returned the requested data, and the API has been successful.

404: A 404 error indicates the API request was unable to find the requested data.

403: A 403 Error means forbidden. This indicates that the client or user does not have permission to request the URL. The user is authenticated, but the user or role associated with the user is not authenticated to make the API request.

In this case, an Administrator should be contacted to investigate further.

This could happen when a wrong API key is used, or a paid-for feature is accessed without the correct permissions applied.

A further list of codes is outlined here: HTTP response status codes - HTTP | MDN

API Restrictions

The following restrictions are currently in place across all client sites in order to prevent outages and denial of service issues.

Flood protection limit: If there are more than 5,000 requests per minute per IP, this request will be blocked to prevent denial of service.

Brute force mitigation protection limit: This rule checks vulnerable endpoints, such as account login, account reg, and v1 API auth endpoints; any more than 100 per 5 mins per IP is blocked. 

When these rules block a request, a 403 response will be received. 

Handling Responses 

Please see the following guidelines recommended below:

HTTP response status codes - HTTP | MDN

A key response to note is the 429 'Too Many Requests' response.

This status code indicates that too many requests have been made in a given amount of time.

This is known as “rate limiting”. For more information on handling a 429 response, see 429 Too Many Requests - HTTP | MDN.

Rate Limits.

In order to maintain stability, security, and fairness, rate limits will be applied to restrict usage during a certain time frame.

The limits will be set to 60 requests per minute per IP address for all clients as standard unless this has been stipulated in your contract.

 

Key reasons for setting API rate limits:

Security: Limiting the number of requests can help reduce the risks of security issues such as brute force attacks, data scraping, or other malicious activities.

Having these limits in place ensures an added layer of protection against unauthorized or harmful use.

Improved Performance: APIs are resource-intensive. Limiting the number of requests can help prevent servers from being overloaded with excessive traffic. Limiting these traffic spikes will also help maintain a smooth and reliable performance rate.

Preventing Abuse or Misuse: Setting rate limits can help prevent scenarios in which requests may be used in unintended ways.