Getting patient data to flow between your application and an EHR shouldn't require months of custom development work. That's exactly the problem Redox solves. Redox API documentation gives developers a single, standardized interface to connect with over 100 EHR systems, including Epic, Cerner, and athenahealth, without building and maintaining point-to-point integrations for each one.

At VectorCare, we built our patient logistics platform with EHR interoperability at its core. Our Connect module integrates directly with EHR, CAD, and billing systems so healthcare organizations can coordinate transport, home care, and DME delivery without toggling between disconnected tools. We've been through the EHR integration process ourselves, and Redox's standardized data models played a significant role in how we think about connecting clinical systems to operational workflows. That firsthand experience is why we put this guide together, to help development teams and technical leaders navigate Redox's documentation effectively.

This article walks you through the key components of the Redox API, from authentication and data models to event-based subscriptions and testing environments. Whether you're scoping out a new integration or troubleshooting an existing one, you'll leave with a clear understanding of how Redox works and a practical path to getting your EHR integration live faster.

What you need before you open the Redox docs

Jumping straight into the Redox API documentation without the right groundwork will slow you down. Before you write a single line of code, confirm three things: you have a Redox account with sandbox access, you understand which data models apply to your use case, and your team agrees on what clinical events your application needs to send or receive.

Your technical prerequisites

Your development environment needs to support HTTPS webhooks and JSON payloads. Redox sends event-driven data to a destination URL you provide, so your server must be publicly reachable and capable of responding with a 200 status code within a few seconds. If your stack can handle a standard REST webhook, you're ready.

You'll also want a working understanding of these concepts before diving in:

• HL7 FHIR or Redox's proprietary data models (Redox supports both; confirm which path your target EHR uses)
• OAuth 2.0 or API key authentication (Redox uses OAuth 2.0 for its modern API and API keys for legacy endpoints)
• JSON schema reading, so you can accurately interpret event payloads

Access and credentials you'll need

Sign up for a Redox developer account at the Redox developer portal to get sandbox credentials. You'll receive a source ID and a secret key, both of which authenticate every request you make. Store these credentials securely in environment variables and never hardcode them in your codebase.

Treat your Redox source ID and secret key the same way you'd treat a database password: rotate them on a schedule and limit access to only the team members who need them.

Once your sandbox credentials are confirmed and your environment is ready, you can move on to selecting the right API for your specific workflow.

Step 1. Choose the right Redox API

Redox offers two distinct API paths, and picking the wrong one early costs significant rework. The Redox FHIR API follows the HL7 FHIR R4 standard, while the legacy data model API uses Redox's proprietary JSON event format. Both access the same EHR network but differ in schema structure and EHR compatibility.

FHIR API vs. Redox data models

Your target EHR determines which path to take. Connecting to Epic or another system with strong FHIR R4 support means the FHIR API gives you a portable, standards-based schema. For older EHRs or event types not yet covered by FHIR, the proprietary data model documented in the redox api documentation is the better fit.

Check Redox's EHR compatibility matrix in their developer portal before committing to an API path.

Match the API to your clinical events

Once you've confirmed your API path, list the clinical event types your application needs to send or receive. Each event maps to a specific endpoint and data model, so defining this list before writing code prevents scope creep.

Common events to confirm up front:

• ADT: patient admission, discharge, and transfer updates
• Orders: lab or radiology order creation
• Results: lab results and clinical observations
• Scheduling: appointment creation and status changes

Step 2. Set up auth and environments

Authentication is where most integrations break first. Redox uses OAuth 2.0 client credentials for its modern API, meaning your application authenticates as a machine, not a user. Pull your client_id and client_secret from the Redox developer portal, then exchange them for a bearer token before making any API calls.

Configure OAuth 2.0 authentication

Your token request goes to Redox's auth endpoint. Store the returned token in memory and refresh it before expiration rather than re-requesting it on every call. Here's a minimal token request:

POST https://api.redoxengine.com/v2/auth/token
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials
&client_id=YOUR_CLIENT_ID
&client_secret=YOUR_CLIENT_SECRET

Tokens expire, so build retry logic that catches 401 responses and automatically fetches a fresh token before retrying the original request.

Switch between sandbox and production

The redox api documentation separates sandbox and production environments with distinct base URLs, so hardcoding either one causes problems. Use environment variables to switch between api.redoxengine.com for production and the sandbox endpoint during development. Confirm with your Redox account manager that your sandbox credentials match the EHR connections you plan to test before promoting any code to production.

Step 3. Send a test message and read logs

With authentication working, your next move is sending a test event through the sandbox to confirm the full data path before touching any production system. This step catches payload errors, missing fields, and misconfigured webhook endpoints early, when fixes are cheap.

Send your first test event

Start with an ADT NewPatient event, since it's one of the simpler payloads in the redox api documentation and gives you an immediate, readable response. Use the following minimal example to POST to the Redox sandbox endpoint:

POST https://api.redoxengine.com/endpoint
Authorization: Bearer YOUR_TOKEN
Content-Type: application/json

{
  "Meta": {
    "DataModel": "PatientAdmin",
    "EventType": "NewPatient",
    "Test": true
  },
  "Patient": {
    "Identifiers": [{ "ID": "TEST-001", "IDType": "MRN" }],
    "Demographics": { "FirstName": "Test", "LastName": "Patient" }
  }
}

Set "Test": true in every sandbox request to prevent data from routing to live EHR systems.

Read and interpret the logs

Once you send the request, open the Redox developer portal logs immediately. Every event shows a timestamp, HTTP status, full request payload, and the EHR's response body. Look for a 200 status with an empty errors array; anything else tells you exactly which field failed validation so you can fix it before building further.

Step 4. Build your EHR workflow mapping

A working test message confirms your connection, but your real integration depends on accurate workflow mapping: translating clinical events from the EHR into actions your application can act on. This step is where you close the gap between raw API data and your actual business logic.

Map clinical events to your application logic

Every event your application receives needs a defined response. Before writing handler code, create a simple mapping table that connects each incoming event type to the specific action your system should take:

Complete this mapping table before writing any handler code; missing even one event type causes silent failures that are hard to trace later.

Document your field mappings

The redox api documentation defines every field in each payload, but your application likely uses different field names internally. Write a field-level mapping document that pairs each Redox field to its equivalent in your data model. For example, map Patient.Demographics.FirstName to your internal patient.first_name field. Keep this document version-controlled so your team can reference it when the EHR sends unexpected values or when payloads change.

Next steps

You now have a clear path from sandbox access to a working EHR integration using the redox api documentation: confirm your prerequisites, select the right API path, authenticate correctly, send a test event, and map your clinical workflows before writing production code. Following these steps in order prevents the most common integration failures that slow teams down.

Once your Redox integration is live, the next challenge is connecting that clinical data to your operational workflows. That means linking EHR events to real patient services like transport scheduling, home care coordination, and DME delivery without building another set of point-to-point connections. That's exactly what VectorCare's Connect module handles, pulling together EHR, CAD, and billing systems into one unified platform so your care teams act on data instead of chasing it. If you're ready to put your EHR integration to work across patient logistics, explore how VectorCare connects clinical and operational systems.