Skip to main content
The Tenant Management API is designed for partners who handle data from multiple downstream customers. It enables you to provision and manage isolated tenants under a single parent organization, ensuring customer data remains segregated while still being managed centrally. With this API you can:
  • Create and manage tenants under your organization
  • Provision applications within each tenant for machine-to-machine (M2M) submissions
  • Manage lifecycle operations such as listing, fetching, and deleting tenants and applications
This separation allows you to enforce data isolation, support per-customer customization, and simplify monitoring across multiple clients.

Key model (control plane vs data plane)

Resistant AI separates tenant management from document processing, and each uses different credentials and access scopes:

Tenant Management API (control plane)

  • Uses organization-level credentials (admin scope).
  • Access tokens are used only for Tenant Management API operations:
    • create/list/delete tenants
    • create/manage tenant applications
  • These tokens cannot be used for document submission or result retrieval.

Documents API (data plane)

  • Document submission and result retrieval must be done using credentials issued for a tenant application.
  • The token scopes for Documents API are different (e.g., read/write submission scopes).

Workflow

1

User organization-level credentials to call Tenant Management API (control-plane)

2

Create one tenant per downstream customers (recommended)

3

Create one or more tenant applications per tenant (per region/cell)

4

Use tenant application credentials to call Documents API (data plane)

Provisioning limits & lifecycle

Default tenant quota: organizations can provision up to 20 tenants by default.
If you need more, contact Resistant AI to increase the quota.

Treat tenants as lifecycle-managed resources

Tenants are intended to represent real downstream customers and should be managed over time:
  • Create a tenant when onboarding a downstream customer.
  • Operate with one or more tenant applications (per cell/region as needed).
  • Delete tenants you no longer need to keep the organization tidy and reduce administrative overhead.
To delete a tenant, you must first delete all tenant applications inside that tenant.

Core concepts

Organization

The organization is the top-level container, provisioned by Resistant AI.
  • Acts as a parent for all your tenants
  • Users (via SSO integration) can belong to one or more tenants within the organization
  • Organization-level applications are used to manage tenants and tenant-level applications

Tenant

A tenant represents an isolated scope for data and configuration.
  • Primary isolation boundary for data and configuration
  • Each tenant can have its own users and applications
  • Submissions created under one tenant are not visible to another, ensuring strict data segregation
  • Tenants are multi-regional: they exist globally within the organization but host their own region-specific applications
Recommended mapping (partner best practice):
  • Use a one-to-one mapping between your downstream customers and Resistant AI tenants (one tenant per downstream customer).

Application

An application is an OAuth2 client credential representing machine-to-machine access. There are two important categories:

Organization-level application

A special application used at the organization level. Required to:
  • Create tenants
  • Create tenant applications
It returns a client_id and either requires an RSA key or supports the client credentials flow.

Tenant application

A tenant application:
  • Belongs to exactly one tenant
  • Is used only for authentication (machine-to-machine access to the Documents API)
  • Each tenant can have one or more tenant applications (e.g., one per region)
Applications are region-specific, since submissions and results processing occur within a defined AWS region (e.g., EU, US, CA, AP).
Cell = our short region identifier used when creating tenant applications.