Skip to main content

Introduction

Two OSIGU products, integrated as a pair:

  • ARC — OSIGU's original platform. Covers pre-authorizations, claims, and dispensing (the redemption side at the pharmacy / clinic).
  • ePrescription (EHR) — OSIGU's electronic-prescription product. Doctors issue compliant e-prescriptions here; pharmacies redeem those prescriptions through the same Dispensing endpoints ARC uses for authorizations.

They're separate products, but they share the OAuth token, the provider identity, the medical catalogues, the provider-product registry, and the Dispensing endpoints — one integration effort covers both.

Together they cover four moments of the care encounter:

  • Pre-authorization (ARC) — checking that a service is covered before it's rendered.
  • Dispensation (ARC) — the pharmacy / lab / imaging centre delivering the covered product or study. Redeems an authorization or an electronic prescription. When it's an authorization, Osigu also generates the claim automatically so the provider doesn't have to integrate twice.
  • Claim (ARC) — the reimbursement record sent to the sponsor. For pharmacies / labs / imaging it's auto-generated by Dispensing; for outpatient encounters and medical procedures the provider files it directly.
  • Electronic prescription (ePrescription) — issuing a compliant e-prescription that a pharmacy can later dispense.

The two widgets — pre-authorization widget (ARC) and electronic-prescription widget (ePrescription) — sit on top of the same REST APIs. Use one, the other, both, or neither.

This documentation is for engineers integrating a provider system directly — either via the REST APIs, the widgets, or both.

What you can do​

Issue pre-authorizations

Request pre-authorization for medications, labs, imaging studies, or in-clinic procedures. Attach the medical indication, receive one authorization per product group per sponsor rules.

Dispense at pharmacy, lab or imaging

Redeem a prescription or authorization by code, verify the beneficiary (biometric or OTP if required), and finalise the delivery. When it's an authorization, the claim is generated automatically behind the scenes.

File claims for services rendered

For outpatient encounters and medical procedures — register the consultation, procedure or bundle so the sponsor can reimburse. Pharmacies, labs and imaging centres can also file directly here instead of going through Dispensing.

Issue electronic prescriptions

Create a compliant e-prescription (v1, v1.1 with consent, or v2 with Spain repository certification). Send it to the patient by email or link the codes to a dispensation.

Core ideas​

Sponsor-driven configuration

Every operation is scoped by a sponsor (insurer / EPS / ARS / self-funded employer). Coverage rules, required support documents, biometric requirements, and even the beneficiary search form vary per sponsor. Your integration reads the current sponsor configuration via getSponsorConfiguration and adapts.

Provider is derived from the token

You don't pass provider_id on every call. The provider is derived from the OAuth token's provider_slug extension, set at onboarding. This means one client_id = one provider identity. Multi-branch providers are handled via provider_branch_id on individual charges/authorizations.

Two-step create-then-complete for pre-authorizations

Pre-authorization requests are two-phase: you initiate a request (which returns an ID), attach the required indications/support files, and only then complete it. This lets you upload documents in whatever order suits your UI, and reject-then-retry doesn't leave orphan records. See Authorizations for the full state machine.

Some sponsors require OTP or biometric sign-off

Depending on the sponsor and the operation, an OTP challenge to the beneficiary or a biometric reading (fingerprint / facial) may be required. The API responds with a challenge URL when it needs one — see OTP flow and the biometric endpoints under Pre-authorizations.

Dispensation covers both electronic prescriptions and pre-authorizations

The pharmacy uses the same /dispensing/v1 endpoints to redeem an electronic prescription code or an authorization code. Osigu recognises which type it is from the code and adapts the flow (verification requirements, sponsor callbacks, etc.).

Settlement batches are a Dominican Republic legacy flow

In the Dominican Republic, providers historically group redeemed authorizations into a settlement batch (radicación) and submit it to the sponsor as a package. The /v3/settlements endpoints support this flow. Newer countries typically integrate with our Revenue Cycle Management (RCM) product instead — see rcm-docs.osigu.com.

Widgets are optional, not additional

The two widgets (pre-authorization + prescription) render the entire form flow for the operations they cover. If you use a widget, your backend never talks to the REST endpoints directly — the widget calls them for you and delivers the outcome via postMessage or a callback. If you don't use the widgets, you talk to the REST API. There is no "hybrid" mode.

Who this is for​

These products are built for:

  • Hospitals and clinics that need pre-authorization for outpatient services or in-clinic procedures.
  • Pharmacies dispensing at the point of care, either insured or cash.
  • Doctors' offices issuing electronic prescriptions to be dispensed elsewhere.
  • HIS / PMS integrators that want to embed OSIGU's operations flow without building the UI from scratch — the widgets exist for this exact case.

If you're a sponsor (insurer / self-funded employer) looking to integrate with Osigu to receive our claims/authorizations feed, this documentation is not for you. Contact support@osigu.com for the payer-side integration guide.

Environments​

OSIGU provides two independent environments; both ARC and ePrescription share them. Build and validate against sandbox first — every code sample defaults to sandbox.

Sandbox

Base URL: https://sandbox.osigu.com

OAuth token: https://sandbox.osigu.com/v1/oauth/token

Integration testing. Non-billable. Use while building.

Production

Base URL: https://api.osigu.com

OAuth token: https://api.osigu.com/v1/oauth/token

Live traffic. Real authorizations, real dispensations. Switch after sandbox is green.

Credentials are environment-scoped — your sandbox client_id will not work against the production OAuth endpoint, and vice versa.

Getting started​

  1. 1Get onboarded by OSIGU

    OSIGU's commercial team provisions your client_id, client_secret, provider_slug, and configures which sponsors and product types you can operate on.

  2. 2Obtain an OAuth access token

    Use the client credentials grant against the OAuth endpoint of your target environment. Cache the token for ~50 minutes (default TTL is 1 hour).

  3. 3Send your first request

    Follow the quickstart to look up a beneficiary, initiate a pre-authorization request, attach the indication, and complete it — all in under 10 minutes.

  4. 4Decide REST vs widget

    If you want minimal UI work, embed the pre-authorization widget or the prescription widget. If you prefer full control, wire the REST endpoints directly.

  5. 5Implement a webhook receiver

    For async outcomes (dispensation completed, authorization voided, etc.), expose an HTTPS endpoint and verify HMAC signatures.

Support​

For onboarding, secret rotation, or production incidents: support@osigu.com.