REST API & Developer Access FAQ

An HTTP interface to Redix conversion tools and demonstration APIs. Works with any language that can make HTTP requests — Python, C#, Java, Node.js, curl, Go, Ruby, PHP, Rust, VB.NET.

Routes are grouped in families. Conversion routes sit under the /api/v2 path prefix; the payer and prior authorization routes use their own paths (/api/pas, /api/patient, /api/provider, /api/payer, /cds-services, /fhir). /api/v2 is a path prefix, not a version number for every route; the public OpenAPI document reports application version 2.1.1. Authentication uses the X-API-Key header.

• POST /api/v2/convert/smart: auto-detect and convert a supported format
• POST /api/v2/convert/hl7-to-fhir: HL7 v2.x to FHIR R4
• POST /api/v2/convert/cda-to-fhir: CDA to FHIR R4 (evaluation offering)
• POST /api/v2/convert/file-upload: generic file conversion through the Redix engine
• /api/v2/hipaa-to-fhir/*: X12 to FHIR R4 (837, 835, and 278 demonstrated on samples; 834, 270/271, and 276/277 in evaluation scope)
• /api/v2/fhir-to-hipaa/*: FHIR PAS to X12 278 (in development, not generally available)

• Da Vinci PAS — POST /api/pas/Claim/$submit, POST /api/pas/Claim/$inquire; the demo also has POST /api/pas/Claim/$cancel, a demo-specific route rather than a PAS-defined operation
• Patient Access — GET /api/patient/Claim, ClaimResponse, Coverage, ExplanationOfBenefit
• Provider Access — GET /api/provider/Patient, Claim, ClaimResponse
• Payer-to-Payer — GET and POST /api/payer/Consent, GET /api/payer/Patient/{patient_id}, GET /api/payer/Coverage, bulk export POST /api/payer/Group/{group_id}/$export
• CRD — POST /cds-services/order-sign-crd
• DTR — GET /fhir/Questionnaire, GET and POST /fhir/QuestionnaireResponse
• RMap to FHIR PAS — POST /api/v2/rmap-to-fhir/278-request

These routes run on the public demo with synthetic data. A route being available does not by itself establish CMS-0057-F compliance or conformance to the Da Vinci guides; production use depends on your data sources, identity and authorization integration, and validation in your deployment.

Official SDKs:

• Python — pip install redix-client (available on PyPI)
• Node.js — npm install redix-client (available on npm)

Documented examples:

• C# / .NET — HttpClient + X-API-Key (.NET 6+, VB.NET supported)
• Java — java.net.http.HttpClient (Java 11+)
• curl / CLI — Bash and PowerShell

Any language with HTTP support works — Go, Ruby, PHP, Rust, and others. Request formats vary by route: file conversion routes take multipart/form-data uploads, PAS routes take JSON FHIR Bundles, and read routes use path and query parameters.

API key via X-API-Key header.

Public sandbox: the public demo key demo-key-12345 runs Redix sample content only. Sample runs send X-Submission-Method: sample, and the server also checks that the content is a registered Redix sample; the header alone does not open the sandbox to other content. The sandbox is rate-limited.

Your own de-identified files: require a private evaluation key with the scope for the tools you are evaluating. Do not send PHI to the public sandbox. See the API documentation for details.

Production: customer-managed keys on customer infrastructure. OAuth 2.0 or SMART on FHIR authorization for payer-facing APIs is integrated with your identity provider and must be configured and verified in your deployment.

JSON, with fields that vary by route; each route's schema is in the OpenAPI document. Examples:

• HL7, CDA, and smart conversion (/api/v2/convert/hl7-to-fhir, cda-to-fhir, smart) — success, conversion_id, converter, processing_time_ms, resource_count, fhir_bundle, warnings
• X12 to FHIR (/api/v2/hipaa-to-fhir/*) — status, transaction_type, fhir_bundle, metadata, warnings
• Engine file conversion (/api/v2/convert/file-upload) — output, error, and acknowledgment file references and a conversion summary, not a fhir_bundle
• Da Vinci PAS (/api/pas/Claim/$submit) — a FHIR PAS response Bundle

HTTP status codes: 200 Success, 400 Bad Request, 401 Unauthorized (missing or invalid key), 403 Forbidden (the key's scope does not cover the request), 413 Payload Too Large (public sandbox file-size limit), 422 Unprocessable Entity, 429 Too Many Requests (rate or daily limit), 500 Server Error. A 200 response means the API processed the request; it is not FHIR validation or payer acceptance.

The public sandbox applies file-size, request-interval, and daily limits. Clients must handle HTTP 429 (and 413 for oversized files) and follow the limit and retry information returned in the response.

Limits for a customer-hosted deployment depend on how that deployment is configured.

• On-premises: your data center
• Docker: container deployment
• Kubernetes: requirements assessed per deployment
• Private cloud: AWS, Azure, or Google Cloud, in your own account

Production PHI does not need to be sent to Redix. HTTPS/TLS for production traffic is configured and verified as part of your deployment. Base URL options: http://localhost:8080 (local development only), https://your-domain.com through nginx (production), or https://localhost:8444 with native SSL. Do not send PHI to the public sandbox.

• Swagger UI at demo.redix.com/docs — interactive with "Try it out" buttons
• ReDoc at demo.redix.com/redoc — alternative documentation view
• OpenAPI spec at demo.redix.com/openapi.json — machine-readable specification
• Redix REST API Guide — available from Redix

• Try the sandbox: test the API and tools on sample data, with no local installation
• Request an evaluation: get the engine, API server, and SDKs for your infrastructure
• Deploy locally: on-premises, Docker, or private cloud; production PHI does not need to be sent to Redix