Applications should have queuing infrastructure in place so that received messages are managed and stored appropriately. Redox won’t send subsequent messages to an application’s endpoint until a 200 success response has been received for the previous message; we recommend sending this confirmation prior to doing any data validation so you can continue to receive messages in real time. If after returning a 200 response, your application identifies an issue with a particular message, we recommend logging an error in your application and reaching out to our 24 hour support team. Alternatively, if there is an issue with how the message was processed or sent then applications should respond to Redox with an appropriate error code. See our post under Technical Considerations on HTTP Status Codes.
It is also recommended that applications have queuing capability for outbound messages being posted to Redox. In the event that Redox does not return a 200 success response to an application’s POST, the application will need to be able to queue any subsequent outbound messages until the issue is resolved.
In the event that an application or EHR returns an error, Redox will queue subsequent messages and proactively reach out to the appropriate team to resolve the issue. Redox also has queuing in place to process all inbound messages from both EHR and application partners and connecting parties can expect real-time confirmations.