Skip to main content
Every request authenticates with a single bearer key issued from your AI Reserve workspace (API Keys in the sidebar → Create Key; you’ll be asked to sign in first) — keys look like aireserve_api_… (older audacity_api_… keys keep working). There is no region, no credential chain, no IAM role, and no signing. The SDKs resolve the key the way the AWS SDKs resolve credentials, in priority order: If no key can be resolved, the SDK fails fast with a clear client-side error (MissingApiKeyError or the language equivalent) — before any network call is made. Keep keys in a secret manager or environment variable; never commit them.

Get an API key

Sign in to the portal, open API Keys in the sidebar, and click Create Key.

​
Restrict where a key can be used

Admins can narrow where requests carrying a key may come from. Every control below is evaluated at the API edge before any model work or spend, and a rejected request gets a clear 403 naming the control (never the observed address or country, and never the configured lists). The organization-level controls also apply to portal sessions: a signed-in user on a blocked network or in a disallowed country sees a short notice instead of the app until they are back on an allowed connection.

​
IP allowlists and the organization IP blocklist

  • Per key — an IP allowlist of IPv4/IPv6 addresses or CIDR ranges (API Keys page → the key’s IP access). Requests from any other address are rejected with ip_address_not_allowed.
  • Per organization — an IP blocklist (dashboard → Governance → IP blocklist). Matching API requests are rejected with ip_address_blocked regardless of the key, and matching portal sessions are blocked.

​
Country restrictions

Country lists work on the source country of the request — the country the request’s network address resolves to — so an admin can think in “US only” or “US + Canada” instead of address ranges. Organization lists cover every API key, domain sign-in (OIDC), and portal session; MCP traffic is not covered. Platform operators (super admins) are exempt so a mistaken list can always be corrected. Rules worth knowing:
  • A key can only narrow, never widen. The effective set for a key is the intersection of the organization allowlist (if any) and the key allowlist (if any). A key list containing a country the organization does not allow admits nothing for that country; the portal warns before saving such a list. The organization blocklist always applies on top.
  • Unknown country fails closed under an allowlist. If the source country cannot be determined (the lookup failed, the address has no country, or it is a private address), the request is rejected whenever any allowlist is set. With only a blocklist configured there is nothing to match, so the request proceeds.
  • Requests the platform makes on your behalf come from our infrastructure in the United States — the Slack agent, the portal’s “Test key” button, and similar integrations. An organization allowlist that excludes US will reject those too.
  • Rejections use the code country_not_allowed and the message Requests from your current country are not permitted by your organization's country restrictions…. The platform’s own geographic screen is separate and unchanged; its rejections keep the unsupported_country_region_territory code.
Country restrictions are about where a request comes from, not where it is processed. They are not a data-residency control: requests are processed in the United States regardless of the countries you allow — see Data privacy.
Manage them from the dashboard → Governance → Country restrictions (organization) and the API Keys page → the key’s Countries column (per key). Both accept one-click presets — United States only, US + Canada, EU/EEA, United Kingdom — and every change is recorded in the admin activity log.