Environments & Credentials

ANKASecure runs in isolated environments. Credentials, keys, policies, and audit logs from one environment are never visible in another.

Environments at a glance

Rule of thumb: anything you do in Staging is safe to inspect (rotate keys, break policies, spam requests). Anything in Production carries real audit trail and real regulatory weight.

Getting credentials

Credentials are issued by the platform admin using the Admin API. They cannot be self-provisioned from the portal.

Two credential shapes exist depending on who the caller is:

Staging

If you want to try the API on staging:

1. Contact your ANKATech account manager or write to [email protected].
2. Request:
   • A tenant on staging (if you don't already have one)
   • A client_id + client_secret for a workload of that tenant, or a human user with the appropriate role
   • The list of permissions you need (see Authentication → Permissions model)
   • A pre-provisioned kid (key identifier) if you don't have admin.keys.* yourself
3. You'll receive the credentials over a secure channel — typically an encrypted 1Password / Bitwarden note. Do not accept them over plain email.

Credentials are handed once. If you lose them, they must be rotated — the platform never emails an existing secret twice.

Production

Production credentials are provisioned when you sign your service agreement, as part of tenant onboarding. The admin from your side takes ownership of secret rotation from that point.

For on-prem deployments, your own operators run the Admin API and issue credentials against your local cluster. See the AWS Marketplace AMI docs for the initial admin bootstrap flow.

What changes between environments

Tokens issued in one environment are not valid in another. A staging JWT called against a production host returns 401 (signature invalid).

Multiple hosts, one API surface

The public API surface is identical across environments: the same 5 API groups, the same paths, the same request / response schemas. Only:

• The host differs
• The kid values you can address differ (each environment has its own key catalogue)
• The client_id / client_secret differ

Meaning: an integration that works on staging works on production — you flip the base URL and swap credentials, nothing else changes.

Server variables in the OpenAPI

Every OpenAPI definition on this portal declares two servers:

servers:
  - url: https://staging.ankatech.co
    description: Staging (default)
  - url: https://{host}:{port}
    description: Custom deployment (dev / on-prem)
    variables:
      host: { default: localhost }
      port: { default: "443" }

• The Try It dropdown lets you switch between Staging and a Custom host without leaving the portal.
• For on-prem deployments, pick Custom and set host / port to your local ingress.
• The default is staging.ankatech.co so first-time clicks work with no config.

The audit.json spec also declares two extra production hosts (api.ankatech.co, audit.ankatech.co) for reference — those are placeholders that the account team overrides per tenant.

Environment discovery

If you're integrating with a tenant you don't own (partner integrations, SaaS federation), the tenant admin should hand you:

1. The baseUrl for their environment
2. A client_id + client_secret scoped to that tenant, or a delegated identity via token exchange (RFC 8693)
3. The list of kid values you're allowed to reference

You never need to know their tenantId explicitly — it's embedded in the JWT you receive after authenticating.

Rate limits

Rate limits exist to keep the shared staging environment responsive and to enforce contract SLAs in production. The exact numbers depend on your deployment and are not part of the public API spec — always confirm the current values with your platform admin before load-testing.

Response semantics are stable across environments:

• Breach returns 429 Too Many Requests
• Response includes a Retry-After header in seconds
• Respect it and add jitter (Retry-After ± 20 %) to avoid thundering-herd retries

Endpoint families that typically have distinct quotas:

• /api/v3/auth/token — token issuance
• /api/v3/crypto/* — synchronous crypto ops (encrypt / decrypt / sign / verify)
• /api/v3/crypto/*/stream — streaming crypto ops (concurrency, not throughput)
• /api/v3/admin/* — admin operations
• /api/v3/audit/* — audit queries

For staging you can safely test moderate loads. For production, coordinate a load test with your account team.

Where to go next