Taiga Partner API
Build against Taiga's billing API with scoped partner credentials.
The Taiga Partner API lets approved partner organizations work with billing data programmatically. The API uses Taiga-issued API keys and your organization's configured billing-provider NPI scope.
What's in these docs?
Use this section for the workflow around the API — authentication, request shape, tenant scoping, pagination, and errors. Use the API Reference for exact endpoint paths, request bodies, response schemas, and generated request examples.
Start here
Authenticate
Create an API key and send it as a Bearer token.
Make requests
Headers, paths, and example calls against the API host.
Tenant scoping
How Taiga enforces billing-provider NPI boundaries on every request.
Pagination
Walk through list endpoints with next_page_token.
Errors
Status codes, the Taiga error envelope, and retry guidance.
Generate an SDK
Use the OpenAPI spec to generate typed clients in any language.
OpenAPI spec
Download the spec to power code generators, API clients, or your own tooling.
You need an authorized partner account.
The spec is served from the same authenticated host as the API. Sign in to the developer portal with a Taiga partner account to download it, or fetch it programmatically with a valid bearer token.
Base URLs
| Surface | URL |
|---|---|
| Partner API | https://api.taigabilling.com |
| OpenAPI spec | https://api.taigabilling.com/openapi.json |
| Developer portal | https://app.taigabilling.com/developers |
How access works
Your organization must have developer access enabled in Taiga. Once enabled, users in your organization can create API keys from the developer portal.
Each API key belongs to one Taiga organization. Requests made with that key are scoped to that organization's configured billing-provider NPIs. You do not pass an organization override in API requests.
Typical integration flow
Create an API key. Sign in to the developer portal and add an API key.
Call the API. Send requests with Authorization: Bearer <api key>. Tenancy is enforced server-side.
Create the patient before the encounter. Register the patient with
POST /patients/v1, create their insurance with POST /coverages/v1 using
the patient field, then add the returned coverage id to the patient's
filing_order.coverages with a versioned
PUT /patients/v1/{id}/{version}. Encounters reference the resulting patient
record — see
Making requests.
Create encounters from the patient. Call
POST /api/encounters/v4/create-from-pre-encounter with the patient's
pre_encounter_patient_id; demographics and coverage are pulled from the
patient record. Non-telehealth encounters must include a service facility,
and each applicable service line must carry its prior-authorization number.
Use BILLABLE only when the encounter is ready for immediate billing
processing; validation blockers can still require action before submission.
Paginate lists. Use limit and follow next_page_token until it is empty.
Generate a client. Download openapi.json and produce a typed SDK in your language of choice.