Hopefully you already completed authentication so that you can initiate requests from your system. But that’s only the first step to fully interacting with Redox and your connections. Now that you can send data, we need to configure your system to receive and respond to data.
To receive data though, your system must:
The last point—checking the verification token—is to ensure that your system only processes data legitimately received from Redox. Like we talked about with authentication and the phone example, this is like having us send a text first to make sure that you want to answer the phone when we call.
You can think of the verification token as the counterpart to your access token; we generate the access token for you, but you generate the verification token for us. So, before you process any incoming request to one of your defined endpoints, we recommend that you verify the legitimacy of the request by checking that the verification token matches the one you gave to Redox.
Learn how to configure and verify an endpoint.
Once an endpoint is verified, you can begin receiving requests. If you want to receive data for multiple systems, you must verify each one individually. Any request you receive should have the verification token in the header like this:
"authorization" : "Bearer [your-verification-token]""verification-token" : "[your-verification-token]"
If the verification token doesn’t match, it means it’s not from Redox, so you should discard the request without processing.
Live data streams don't contain a challenge or verification token in the body or URL of the request. As such, you don't need to return a challenge value.
For synchronous requests, the verification token and challenge are included in the request body. Once you respond with the challenge value, any subsequent requests only include the token (not the challenge) in the request header. You should verify the verification token to ensure it's an authorized request.
Your response to any request you receive should differ based on the type of request made and whether your connection’s EHR system requires a response from you. Check out how to handle: responses for:
Each data model has different requirements for parameters. Explore each data model and their respective required parameters.