Tenant Scoping

Every Partner API credential belongs to one Taiga organization. That organization has a configured list of billing-provider NPIs.

Taiga uses that NPI allowlist to decide what the credential can read or write.

How scoping works

List reads

For list endpoints that support billing-provider NPI filters, Taiga intersects the requested NPIs with your organization's allowed NPIs.

If no NPI filter is provided, Taiga still filters the response to your allowed NPIs.

curl "https://api.taigabilling.com/api/encounters/v4?limit=25" \
  -H "Authorization: Bearer $TAIGA_ACCESS_TOKEN"

Object reads

For single-object reads, Taiga fetches the object and returns it only if it is in scope.

If the object is outside your scope, the response does not include the object. Treat this the same way you would treat a missing resource.

Writes

Writes are checked before and after forwarding.

If either check fails, Taiga returns an error and does not return the object.

Creating providers and service facilities

Creating an organization provider or service facility is the one write that can extend your organization's scope. Unlike other writes, the NPI on a provider create does not need to already be in your allowlist — this is how you register a new billing or rendering provider. On success, the new provider's NPI (and the provider or service-facility ID) is added to your organization's scope automatically, so follow-up requests that reference it are in scope.

curl -X POST "https://api.taigabilling.com/api/organization-providers/v3" \
  -H "Authorization: Bearer $TAIGA_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "npi": "1020555011", "is_rendering": true, "is_billing": false,
        "provider_type": "INDIVIDUAL", "license_type": "NP",
        "qualifications": [] }'

A few consequences to plan for:

• Updates cannot move a provider to an NPI outside your scope. A PATCH that changes a provider's npi to a value your organization does not already own is rejected. Only a create may introduce a new NPI.
• Scope is additive. Deleting a service facility, or terminating a provider with an employment_termination_date, does not remove it from your allowlist; the resource simply stops resolving. There is no request that shrinks your scope — contact support to remove an entry.
• Providers cannot be deleted through the API. Use a PATCH with an employment_termination_date to deactivate one.

Auditability

Do not put PHI in:

• Credential labels
• Key names
• Operational notes
• Webhook configuration metadata