Dispensing

Dispensing is the moment a pharmacy or clinic actually hands over what an authorization or an electronic prescription entitled the beneficiary to receive. It's the point-of-service side of the operation — the counterpart to the pre-authorization the doctor obtained earlier, or to the electronic prescription the doctor issued.

The Dispensing API lives under /dispensing/v1/... and it works the same way regardless of whether the code being redeemed is:

• An authorization code (issued by ARC's pre-authorization flow), or
• An electronic-prescription code (issued by Osigu's ePrescription (EHR) product, which is separate from ARC but shares these dispensing endpoints, the medical catalogues, and the provider identity).

Osigu recognises the code type internally; you always start with the same startDispensation call.

One integration, two flows

Point-of-delivery providers — pharmacies, laboratories, imaging centres — deal with two very different transactions: uninsured electronic prescriptions (patient pays out of pocket) and insured pre-authorizations (sponsor pays). Historically that meant integrating twice — one API for electronic prescriptions, another to report a delivery to a sponsor as a claim.

Dispensing unifies both. When you redeem an authorization through startDispensation → completeDispensation, Osigu creates the claim automatically behind the scenes so the sponsor receives it. Your integration doesn't call the Claims API — the same dispensing endpoints handle both cases:

Code type	What the provider does	What Osigu does behind the scenes
Electronic prescription (uninsured)	startDispensation → completeDispensation	Marks the prescription as redeemed.
Authorization (insured)	Same two calls	Marks the authorization as redeemed and creates the claim on behalf of the provider.

The same set of endpoints and the same claim shape covers medications, labs and imaging — whichever type of product/study the authorization covered.

Providers that prefer to integrate directly with the Claims API instead of using Dispensing can — see Claims. Most pick the Dispensing path.

Two-phase pattern

Just like pre-authorizations, dispensing is two-phase — start, then complete. Between the two calls, the pharmacy can inspect what's redeemable, swap products (if the sponsor allows), gather any additional data the sponsor demands (biometric reading, OTP, delivery address), and only then commit.

Verification: OTP or biometric

Whether the sponsor demands verification before the dispensation completes depends on the sponsor's rules and, sometimes, on the country. Two mechanisms coexist:

• OTP — a one-time code the sponsor sends to the beneficiary's phone or email. The pharmacy asks the beneficiary for the code and passes it to Osigu via validateOtp. See OTP flow.
• Biometric — a fingerprint or facial reading captured at the pharmacy device. The reading is sent as Base64 to the biometric endpoint and Osigu polls the sponsor for a match.

You can find out whether either is required for a specific authorization via getDispensationVerificationStatus.

Modifying products mid-dispensation

Some sponsors allow the pharmacy to substitute a product for an equivalent (same INN, different brand; same active ingredient, different presentation). While the dispensation is in STARTED, you can call updateDispensationProducts to change the product list. Osigu re-validates against the authorization and against the sponsor's substitution rules before accepting the change.

Once you call complete, the products are locked.

Lifecycle

Status	Meaning
STARTED	Dispensation created. Products loaded from the authorization/prescription. Can still swap products, void, or complete.
PENDING_VERIFICATION	Sponsor requires OTP or biometric. The dispensation blocks on this.
DISPENSED	Complete. The authorization/prescription has been redeemed. Not reversible.
VOIDED	Cancelled by the pharmacy (or by Osigu on timeout). The authorization is freed and can be dispensed again.

What the endpoints look like

The dispensing endpoints are:

Endpoint	Purpose
POST /dispensing/v1/dispensations	Start a dispensation for a code. Returns the dispensation ID and the products loaded from the authorization/prescription.
GET /dispensing/v1/dispensations/{id}	Retrieve the dispensation state.
PUT /dispensing/v1/dispensations/{id}/products	Swap products (if allowed).
GET /dispensing/v1/dispensations/{id}/verification-status	Check if OTP/biometric is required and its state.
POST /dispensing/v1/dispensations/{id}/complete	Final commit.
POST /dispensing/v1/dispensations/{id}/void	Abort.

Related concepts

• Authorizations — the source of most dispensations.
• Prescriptions — the other source.
• OTP flow — the verification challenge for sensitive dispensations.
• Webhooks — dispensing.completed and dispensing.cancelled fire as dispensations progress.