Skip to main content

​
Overview

The TenantCore API exposes TenantCore-defined operations for resources owned by your account. It is not a generic Microsoft 365, DNS-provider, or sending-tool proxy. The authorization chain is always: API key → TenantCore account UUID → TenantCore-owned resource → allowed TenantCore action → provider Today you can use /v1 to:
  • obtain TenantCore’s signed Microsoft consent URL for adding a new BYOT tenant to your account
  • list and inspect TenantCore-owned tenants
  • synchronize connected tenants
  • manage domains that belong to those tenants
  • create and manage TenantCore mailboxes on owned domains
  • configure Exchange-enforced sending-limit policy
  • create/check sending-tool integrations and connect TenantCore mailboxes through provider OAuth
  • inspect mailbox usage and enforcement state
Managed-tenant purchase/provisioning is not exposed through the public API.

​
Base URL

​
Resource ownership

Resource management endpoints require an existing TenantCore resource. Supplying a Microsoft tenant GUID, domain name, mailbox address, or provider identifier does not grant access by itself. A valid target is either:
  • a BYOT tenant already connected to the authenticated TenantCore account, or
  • a TenantCore-managed tenant already assigned to that account.
Domains and mailboxes must resolve through those owned tenants before TenantCore will call Microsoft or another provider.

​
Request format

The API accepts and returns JSON. Every request requires:
Every POST, PUT, PATCH, and DELETE request also requires:
Reuse that same idempotency key only when retrying the exact same request after a timeout/network failure.

​
Response and request IDs

Successful responses are JSON objects. Every /v1 response includes:
Errors use:

​
Rate and capacity protection

TenantCore rate-limits the public API by authenticated account and uses tighter limits for Microsoft/provider-heavy operations. It also enforces per-process concurrency ceilings and a maximum request-body size. See Authentication for the current defaults and response headers. These controls protect both TenantCore and upstream systems from accidental loops, runaway automation, and abusive traffic.

​
Connecting a BYOT tenant

GET /v1/tenants/connect-url returns a signed TenantCore Microsoft admin-consent URL bound to the authenticated account. A Global Administrator approves the TenantCore application in Microsoft’s UI. After the callback succeeds, the tenant becomes a TenantCore-owned BYOT resource and normal API operations may act on it. The API does not accept an arbitrary tenant GUID and begin managing it directly.

​
Infrastructure notes

  • Exchange and Microsoft Graph changes can require propagation time.
  • DNS results reflect what TenantCore can verify publicly/provider-side at the time of the request.
  • API operations never bypass TenantCore ownership, entitlement, or plan limits.
  • Server-side provider details and secrets are not returned in generic error responses; use X-Request-ID for support correlation.

​
Getting started

  1. Activate TenantCore Complete (or use an eligible grandfathered API entitlement).
  2. Open the API page in TenantCore and create a key.
  3. Copy the key immediately; it is shown once and cannot be revealed later.
  4. Send it as Authorization: Bearer <your_api_key>.
  5. For every write, generate an Idempotency-Key and retain it until you know whether that logical operation completed.
  6. Start with GET /v1/tenants to discover resources already owned by the account.
  7. If you need to add BYOT infrastructure, use GET /v1/tenants/connect-url and complete the signed TenantCore consent flow.