Status Codes
Every Happy Endpoint API response includes an HTTP status code. Use the code to decide whether to parse data, fix request parameters, update credentials, slow down requests, or retry a transient failure.
HTTP status codes
| Code | Meaning | Retry | What to do |
|---|---|---|---|
| 200 OK | The request succeeded and the response body contains JSON data. | No | Parse the response and save the data your workflow needs. |
| 201 Created | A job or resource was accepted for creation by an endpoint that supports it. | No | Store the returned identifier and follow the endpoint reference for the next step. |
| 202 Accepted | The request was accepted for asynchronous processing. | Poll as documented | Do not treat this as final data. Use the returned job or request identifier when the API provides one. |
| 400 Bad Request | A required parameter is missing, malformed, unsupported, or outside the accepted range. | No | Fix the request before sending it again. Validate IDs, query values, pagination, country codes, and enum values. |
| 401 Unauthorized | The RapidAPI key is missing, invalid, expired, or sent with the wrong header. | No | Check the X-RapidAPI-Key header and confirm the key is active in RapidAPI. |
| 403 Forbidden | The key is valid, but the account or plan cannot access this API or endpoint. | No | Review your RapidAPI subscription, endpoint access, and account permissions. |
| 404 Not Found | The endpoint, ID, URL, listing, product, or other requested resource was not found. | Usually no | Verify the endpoint path and identifiers. If the input is valid, handle the response as an empty result. |
| 429 Too Many Requests | The request exceeded a RapidAPI rate limit or quota window. | Yes, after waiting | Slow down, use exponential backoff, queue bulk work, or review your RapidAPI plan limits. |
| 500 range | A temporary server or upstream provider error occurred. | Yes | Retry with exponential backoff, cap retry attempts, and log the endpoint, status, and sanitized parameters. |
| Timeout | Your client, network, platform, or an upstream provider timed out before a response completed. | Yes, when safe | Set explicit client timeouts and retry only if your workflow can safely repeat the request. |
How to use status codes
Check the status before reading the body
Do not assume every response is successful JSON data. Inspect the HTTP status first, then decide whether to parse data, show an empty state, retry later, or alert an operator.
Separate permanent and temporary failures
400, 401, and 403 usually need a code, key, or subscription fix. 429, timeouts, and 500-range responses usually need pacing, retries, or a background queue.
Log enough context to debug safely
Record the endpoint, status code, response time, sanitized parameters, and request or job ID when available. Remove keys and secrets before writing logs.