Authenticate a legacy API key

Last updated: Dec 10, 2025
DEVELOPER
HEALTH TECH VENDOR

You can authenticate Redox Data Model API requests with legacy API keys.

Preferred authentication method: OAuth API keys

We don’t recommend using legacy API keys to authenticate your API requests.

Check out our authentication overview and learn how to use OAuth keys (our preferred authentication method).

Prerequisites

  • A user must be assigned to an engineer role to authenticate API keys. Learn about user roles.
  • Have an existing API source. This is a prerequisite because sources and legacy API keys are tied 1:1. If you don’t have one yet, learn how to create an API source.
  • Have an existing secret value stored for the legacy API key. If you don’t have one, learn how to generate a secret value.
  • Have a subscription with a source, destination, and data model to send a Redox Data Model API request. Talk to your Technical Account Manager if you need a subscription.  
    Not supported with the Redox FHIR API

    Legacy API keys aren’t supported with Redox FHIR® API requests.

Step 1: Retrieve the legacy API key credentials

  1. Log in to the Redox dashboard.
  2. From the navigation menu, click the Developer page.
  3. By default, the Sources tab opens and displays any configured sources and OAuth API keys. Find the API source you want to send the request from.
  4. On the source tile, click the copy icon of the Legacy API key field to copy the API token value.
  5. Use the corresponding secret value you’ve stored securely.
If legacy API key credentials are exposed

If either your API key token or secret value are exposed, you must generate a new secret value again. Learn how to generate a new secret value.

Step 2: Send an authentication request

  1. Send an authentication request:
    Example: Request for generating an access token
    bash
    1
    curl -X POST https://api.redoxengine.com/auth/authenticate \
    2
     -H 'Content-Type: application/json' \
    3
     -d '{"apiKey": "{{api-token}}", "secret": "super-secret-client-secret"}'
  2. You receive the following response:
    Example: Response for generating an access token
    json
    1
    {
    2
    "accessToken": "13d5faa8-aacd-4a0d-a666-51455b1b2ced",
    3
    "expires": "2015-03-25T20:52:35.000Z",
    4
    "refreshToken": "4ed7b234-9bde-4a9c-9c86-e1bc6e535321"
    5
    }
  3. Use the following values from the authentication response:
    1. accessToken: Use this value in the authorization header to initiate an API request. 
    2. expires: Contains the exact date and time that your access token expires. Access tokens expire 24 hours after retrieval. 
      401 error code

      If you attempt to use an expired access token with a request, you’ll receive a 401 Unauthorized error.

    3. refreshToken: Use this value to retrieve a new access token after the initial one expires. See the details for refreshing your token at the end of this article.

Step 3: Initiate an API request

After successfully authenticating, you can initiate API requests from your API source to the verified destination(s) in your subscription.

Authorization headers

The Data Model API relies on OAuth 2.0 Bearer to authenticate requests. All API requests must contain an Authorization header with a valid access token in the following format: Authorization: Bearer [your-accessToken].

Example: Authorization header for a request
bash
1
curl -X POST https://api.redoxengine.com/endpoint \
2
 -H "Authorization": "Bearer f81eeac9-7cb0-4a82-951b-724f592723ae"

Header

Value

Description

Authentication

Bearer `your-authToken`

The token that authenticates your request. This header is required.

Content-Type

application/json

The value that identifies the type of API call.

Request parameters

Every Data Model API request must contain these body parameters.

Parameter

Type

Description

Meta.DataModel

String

The data model corresponding to the type of data you're sending or requesting.

Meta.EventType

String

The event type of the data model that you're sending or requesting. Learn more about event types.

Meta.Source.ID

String

The identifier for the source sending the outgoing request. This parameter is required if you have more than one legacy API key. Learn more about identifying a source.

Meta.Destinations[].ID

String array

Objects with ID value(s) of the endpoint(s) you're sending data to or the endpoint you're requesting data from.

A request should generally look like this:

Example: General request
bash
1
curl \
2
 -X POST https://api.redoxengine.com/endpoint \
3
 -H "Content-Type: application/json" \
4
 -H "Authorization: Bearer $API_TOKEN" \
5
 -d '{
6
   "Meta": {
7
     "DataModel": "PatientAdmin",
8
     "EventType": "Arrival",
9
     "Destinations": [
10
       {
11
         "ID": "af394f14-b34a-464f-8d24-895f370af4c9",
12
         "Name": "Redox EMR"
13
       }
14
     ]
15
   },
16
   "Patient": {
17
      # … payload omitted
18
   }
19
 }'
Other required parameters

Each data model has different requirements for parameters. Explore each data model to see their respective requirements.

Sending test API requests

For test requests, send to https://api.redoxengine.com/endpoint. Learn how to send test messages.

Multi-region users

If you’re operating in Canada, you have to add the ca region to the Redox endpoint URL: https://api.ca.redoxengine.com.

(Optional) Refresh your access token

You can use the refresh token returned from the most recent authentication request to retrieve a new access token via the refresh token endpoint:

Example: Request for refreshing an access token
bash
1
curl -X POST https://api.redoxengine.com/auth/refreshToken \
2
 -H '{"Content-Type": "application/json"}' \
3
 -d '{"apiKey": "{{API-token}}", "refreshToken": "4ed7b234-9bde-4a9c-9c86-e1bc6e535321"}'

The object returned for a successful response is the same as that for the original access token retrieval request noted above.

Refresh token expiration

Refresh tokens are dynamic, so they change and rotate daily. They expire after 7 days of inactivity.

However, we recommend requesting new access tokens rather than managing refresh tokens. This simplifies your workflow and avoids the risk of accidentally leaking a secret value.

FHIR® is a registered trademark of Health Level Seven International (HL7) and is used with the permission of HL7. Use of this trademark does not constitute an endorsement of products/services by HL7®.