Error response structure
When an error occurs, the API returns a JSON object with three fields: Example:Common errors and solutions
403 Forbidden
403 Forbidden
The request is valid, but the server refuses to process it. Common causes:
the requested resource requires permissions your plan doesn’t include, a
parameter isn’t available on your plan, or the date range exceeds your plan’s
allowed history period.Example:Solution:
- Verify your plan includes the parameters and features you’re using.
- Check for typos in parameter names.
- Ensure your date range stays within your plan’s history limit.
- If you believe you should have access, contact support.
408 Request timeout
408 Request timeout
The server couldn’t complete the request within the 30-second timeout.
Most commonly caused by complex queries over long time ranges that span
multiple monthly indexes.Example:Solution:
- Break the query into smaller time chunks — monthly ranges work best.
- Reduce nested boolean logic and NEAR operators in a single query.
- Lower
page_size(try 100 instead of 1000 for complex queries). - Implement retry logic with exponential backoff.
422 Validation error
422 Validation error
The server understood the request but can’t process it due to invalid input.Example:Solution:
- Check all parameter names, formats, and values against the API Reference.
- Ensure
from_is earlier thanto_. - Verify date strings follow the expected format.
429 Too many requests
429 Too many requests
You’ve exceeded the rate limit for concurrent API requests.Example:Solution:
- Add delays between requests or implement a request queue.
- Use exponential backoff when retrying.
- Check your plan’s concurrency limits in Subscription plans.
499 Unknown status code
499 Unknown status code
A non-standard code for client-side errors that don’t fit standard HTTP
status codes. Typically indicates a missing required field or malformed
parameter.Example:Solution:
- Check your request payload for missing required fields.
- Verify all parameter types match the API specification.
- Review the API Reference for the correct request format.
500 Internal server error
500 Internal server error
An unexpected server-side condition. Can also be triggered by a malformed
request payload — the API returns a generic 500 rather than a validation
error for certain malformed inputs.Solution:
This error often doesn’t return a JSON response body. You may see a generic
error page or a connection error instead.
- Validate your JSON payload before sending — check for syntax errors like missing brackets or trailing commas.
- Wait a few minutes and retry.
- Check the NewsCatcher status page for any known incidents.
- If the problem persists, contact support with your request details and correlation ID.
Troubleshooting with correlation IDs
Every API response includes acorrelation-id header. Always include it when
contacting support — it helps us locate your exact request in the logs.
Best practices
- Inspect the status code first. The code narrows the problem space before you read the message.
- Implement structured error handling. Use try-catch blocks and log both the status code and message for every failed request.
- Use exponential backoff for transient errors. Apply it to
429and408— not to401,403, or422, which indicate problems that won’t resolve on retry. - Validate before sending. Check parameter formats, required fields, and date ranges client-side to avoid round-trips on predictable errors.
- Protect your API key. Store it in environment variables, not in source code.

