Authenticating Redox APIs

Last updated: Mar 4, 2024

No one answers the phone when they don’t recognize the number on the screen. Unless you ordered food delivery, in which case you take a chance lest the delivery person needs help finding you. But generally, we swap phone numbers with someone we want to talk to so that they know it’s us when we text them later. In other words, you’re authenticating your identity.

But what happens when you change your phone number? Simple, you send another text to confirm your identity with a new phone number.

Authenticating your Redox setup is similar in concept: We want to make sure it’s you on the other end of that call. We do this by giving you an API key and secret. Secret values are how your system proves its identity to us.

First, you plug in the API key and secret in the Redox dashboard. Then, when you send an authentication request with these values, we generate an access token for you that’s good for 5 minutes. The access token allows you to freely initiate requests and receive data back.

Using multiple keys

We recommend having an API key and secret for each environment. For most organizations, this means having one per environment type (i.e., development, staging, production).

You can create more than one API key for a given environment, though, depending on how you want to control access. It just depends on your organization's security practices. For example, if two dev teams work in the same environment, it may be useful for each team to have a key and secret to work in their own context.

Users in your organization can view or manage API keys depending on their assigned environment role. Learn about environment roles.

Ultimately, it’s your call on how many keys to use—yes, you’re welcome for that unintentional, but delightful pun.

Authentication methods

You have two options for authenticating your setup with Redox.

Receiving responses

Once you complete your authentication and receive an access token, you're ready to initiate and receive requests. Responses to your requests differ based on the type of request made and whether you require a response from your connection’s EHR system. Check out these articles for specifics: