Skip to main content

​
API key

Every public API request must include your TenantCore API key in the Authorization header:
Create the key from Developer API settings. The full secret is shown once when you create or rotate it. TenantCore stores only a one-way hash and safe display metadata, so an existing key cannot be revealed later. Store the key in a secret manager or other protected server-side configuration. Do not put it in browser code, source control, logs, or client-visible configuration.

​
Example request

​
Resource ownership boundary

A valid API key does not turn TenantCore into a generic Microsoft 365, DNS-provider, or sending-tool proxy. Every operation is resolved through TenantCore first: API key → TenantCore account UUID → TenantCore-owned tenant → TenantCore-owned domain/mailbox/integration → provider action A tenant must already be connected to your TenantCore account as BYOT or exist as a TenantCore-managed tenant before resource-management endpoints can act on it. Supplying an arbitrary Microsoft tenant GUID, domain, mailbox, or provider resource is never enough to authorize an operation. GET /v1/tenants/connect-url is the controlled onboarding exception: it creates a signed TenantCore consent flow for your authenticated account so a new BYOT tenant can become an owned TenantCore resource. It does not accept an arbitrary tenant GUID to operate against.

​
Write-request idempotency

Every POST, PUT, PATCH, and DELETE request under /v1 must include an Idempotency-Key header:
Use a new key for a new operation. If your HTTP client times out and you need to retry the exact same request, reuse the same key. TenantCore will replay the completed response instead of executing the provider operation twice. Reusing the same idempotency key with a different method, path, query string, or body returns 409 idempotency_key_conflict.

​
Request IDs

Every /v1 response includes X-Request-ID. You may also send your own safe correlation value in X-Request-ID; TenantCore will return it when valid. Include this value when contacting support about an API request.

​
Rate limits

TenantCore applies both account-level distributed rate limits and process-level concurrency protection. Current defaults are: Successful authenticated responses include the applicable X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset, and X-RateLimit-Bucket headers. A limit breach returns 429 with Retry-After.

​
Key prefixes

New production keys use the tc_live_ prefix. Grandfathered trial keys may use tc_trial_. Treat the entire key as opaque and do not authorize or infer permissions from its prefix.

​
Plan scoping

Public API access is included with TenantCore Complete. Grandfathered legacy API entitlements may remain usable during the controlled legacy-product migration. Entitlement and tenant-capacity checks run on every authenticated request. API access never bypasses the tenant-slot limits assigned to the TenantCore account.

​
Rotating your key

You can rotate your key from the API page in the TenantCore app. The old key is invalidated immediately. The new key is shown once, so copy it before leaving or refreshing the page and update every integration that used the old key. There is no /v1 endpoint that lets an API key rotate itself.

​
Authentication errors