While we like to avoid errors, it doesn't mean they won't happen. Review the HTTP error codes you might see in response to your API requests.
Code | Description |
|---|---|
400 Bad Request | The request is formatted incorrectly or is missing required information. |
401 Unauthorized | Authentication failed. This means you need to refresh or regenerate your access token and try again. |
403 Forbidden or 404 Not Found | The request is missing one or more of these: (a) the POST verb (b) destination identifier (c) the event type (i.e., the data model) or FHIR® interaction or operation in the URL. |
413 Payload Too Large | The payload sent exceeds the payload size limit of 10 MB. Refer to Redox message size limits. |
429 Too Many Requests | Your system has exceeded the rate limit of 7,500 requests per IP address for the current five-minute rolling window. Wait a few minutes then try initiating the request again. . |
500 Internal Server Error | An unknown error occurred within Redox. |
502 Bad Gateway | The request was dropped within Redox. This can sometimes occur during brief periods when internal updates are being applied. |
504 Gateway Timeout | The request took too long to complete. Requests to Redox time out after a couple of minutes. |
If an asynchronous message fails in a production environment, the process for automatic retries depends on the acknowledgement type. Learn more about asynchronous messages and responses.
If the destination sends back a negative acknowledgement (NACK), we retry the failed message after a few seconds. If it fails again, we steadily increase the wait period between retries until it becomes a fixed wait of a minute or two between requests. Retries continue every couple of minutes until the destination sends a successful response or until we manually pause the request.
We also pause the queue for asynchronous traffic until the failed one goes through successfully or is stopped. Our Customer Success team receive and alert if any message queues pile up so they can review and resolve any processing failures. Pager alerts only come through between 10 AM and 10 PM Eastern time. Outside that time, alerts are queued and delivered at the start of the next day.
For non-critical errors, you should send back a 200 OK status before performing data validation or after finding an error that can be resolved at a later time. This way, we don’t pause data for production environments and your development/staging environments can proceed with business as usual. This option ensures continuity in your data delivery so that your data flow doesn’t get hung up on one troublesome data payload.
If you identify a non-critical issue with an incoming message, log an error in your system. Then submit a ticket via our Help Desk if you need help resolving it.
If you're experiencing downtime or another critical error, we recommend sending a 4XX or 5XX status to initiate pausing on our end. That way, none of your data is lost while you work to resolve your system.
If the destination doesn't acknowledge the message at all, we retry the failed message after a few seconds. If it fails again, we steadily increase the wait period between retries until it becomes a fixed wait of a minute or two between requests. Retries continue every couple of minutes until the destination sends a successful response or until we manually pause the request.
We also pause the queue for asynchronous traffic until the failed one goes through successfully or is stopped. Our Customer Success team don't receive an alert, but they periodically review the queues for any long-standing retries for an unacknowledged message. They'll investigate queues and determine whether to allow retries to continue, skip the erroring message, or take another action to resolve the issue.
If an asynchronous message fails in a development or staging environment, we don't automatically retry the failed message or pause the queue. This means that other asynchronous messages can continue sending.
You can manually retry sending a message in the Redox dashboard. Any request can be manually retried, including ones that didn’t deliver, that Redox failed to process, or that sent successfully but you want to re-send. Learn how to initiate a manual retry.