Consumer Privacy Notice

For people who sign in to APIs and developer portals powered by APIblaze.

Last updated: October 7, 2026

Who this is for

This notice is for end users — the people who sign in to an API, developer portal, or application that is operated by an API provider and powered by APIblaze ("APIblaze", "we", "us"). It describes what happens to your information when you sign in, call the API, or use its chat or MCP features. The API provider's own privacy policy also applies to how they use your information.

The parties and their roles

  • The API provider — the business or developer whose API or portal you sign in to. They are the primary controller of your information; their privacy policy governs how they use it.
  • APIblaze — we operate the gateway, sign-in and identity infrastructure for the provider. For most of what we do we act on the provider's behalf (a processor). We also use a limited amount of this information for our own purposes — chiefly keeping the platform secure and preventing abuse across the service — and for those purposes we are a controller. This notice covers that processing.
  • Your login provider — the identity provider you choose (for example GitHub, Google or Microsoft) verifies who you are and shares basic profile information based on the permission you grant it.

What we collect

When you sign in and use a provider's service through APIblaze, we may process:

  • Profile information from your login provider — typically your name, email address, and a provider account identifier. We do not receive your password, and we request only the basic permission needed to sign you in.
  • Sign-in and account records — a stable internal identifier we create for you, which API and provider you signed in to, your group memberships and access requests, and timestamps of your sign-ins, so the provider can recognize you across sessions.
  • Technical information — when you make requests, we process the identifiers in them (for example an API key, which we store as an irreversible hash — and, if it has an expiry date, also in full in encrypted storage until it expires so it can be shown to you again — or a token, which we store encrypted), and we record limited request metadata: route, status, timing, and an approximate location (country) derived from your network address. We use your network address itself only to rate-limit, to detect abuse and to pass it to the provider's backend; we store it only in one-way hashed form, and we remove it from stored logs and captured traffic.
  • Chat content — if you use a provider's AI chat, the messages you send and the responses the provider's API returns to the chat (see "AI chat" below).
  • Request content (only in specific cases) — see "Request content" below.

How we use it

  • To operate sign-in and create and manage your access to the provider's service.
  • To apply the provider's access rules — group memberships, permissions, and usage limits.
  • To keep the platform secure and prevent abuse and fraud. This includes analysis across the service to detect misuse and automated enforcement of the provider's access rules — see "Automated access decisions" below. We keep the details of our abuse-detection methods confidential so they cannot be evaded.
  • To keep basic, aggregated analytics (such as request counts and country) needed to run the service.
  • To keep security and audit records.

Automated access decisions

Access to a provider's API may be granted or denied automatically based on that provider's rules — for example whether your email or domain is on their allowlist, whether you belong to a required group, or whether your account has been suspended — and on platform-wide rate and abuse limits. A denied request is refused in real time. If you believe access was denied in error, contact the API provider, who controls those rules; you can also contact us at the address below.

Request content

Request logs. By default we record only metadata about your requests (route, status, timing, your identifier), the names of headers and the shape of bodies — not their values. An API provider can turn on capture of header values, query parameters, bodies and selected token claims for a proxy so they can debug it; when they do, that content is stored for 91 days for the provider to review. Credentials, cookies, network addresses and secret-shaped values are always removed first.

Traffic capture. An API provider can additionally enable a traffic-capture feature in a non-production (development) environment. It is on by default for development environments, the provider can turn it off, and it never runs in production. When enabled, the contents of requests and responses on that environment — which may include information you send — are stored for 31 days so the provider can review them and draft their API description from them. We remove credentials, cookies, network addresses and user agents from stored samples, but we do not remove other content by field name, so any personal data inside a request or response body may be retained. If the provider runs an AI review on those samples, their content is sent to the model providers described below.

AI chat and MCP

Some providers offer an AI chat that can call their API for you, or expose their API to AI tools through the Model Context Protocol. When you use them, your messages and the API responses returned to the chat are sent to language-model providers through OpenRouter (which routes to providers such as Anthropic, OpenAI, Google and DeepSeek). We request routing that excludes providers who retain or train on inputs, and we do not include your identity or network address in what is sent. A provider may instead use their own model account, in which case that provider's model agreement applies. Please do not put sensitive personal information in chat messages.

If you report a problem

A developer portal can offer a "report a problem" button. What you write goes to the API provider's ticket, together with recent failing requests your browser made and any errors it logged. You can attach a screenshot: it is taken of the page you are on, inside your browser, and fields we recognise as keys, tokens, passwords or personal data are blacked out before the picture is made, so those pixels are never produced. You can black out anything else yourself, and only that edited picture is uploaded. The picture is stored on its own, is never attached to the ticket we open or posted to our alerting channel, and only APIblaze staff can open it. If you would rather send nothing, the screenshot is optional.

Who we share it with

  • The API provider — so they can identify and manage you as their user. They can see your identity (such as name and email), your group memberships, your access status, and the request metadata and captured content described above.
  • The provider's own systems — when you call their API, we pass your identifier, your group memberships, the tenant you belong to and your network address to their backend so it can serve your request and apply its own limits. The address travels with a short-lived signature so the provider's backend can tell it came from us and was not forged.
  • Our service providers (subprocessors) — Cloudflare (hosting, storage and network), Neon (the database that holds identities), an OpenFGA authorization service we host, OpenRouter and the model providers it routes to (AI chat and MCP, as above), AWS SES and Resend (to send access-request and verification email to you and operational email to providers and our team), and your login provider. These process data on our instructions, except your login provider, which acts under its own terms.
  • We do not sell your personal information, and we do not send you marketing email.

How long we keep it

  • Your identity and account records: while the API provider maintains your access; deleted when the provider deletes you, their tenant or their account.
  • Identities observed from traffic but not registered: pruned after about 90 days without activity.
  • Stored provider tokens: at most about 30 days after your last sign-in or token refresh.
  • Request logs: 91 days. Captured traffic samples: 31 days. Aggregated analytics: about 90 days.
  • Sign-in session records: 7 days (30 days for some applications); authorization and verification codes: minutes; MCP sessions: one hour.
  • Long-running jobs started through MCP: for 24 hours we keep a record of who asked for the job, which tool it ran and what the API answered, so the result can be collected after it finishes.
  • A problem report you send, including any screenshot you attach: 365 days.
  • Security and audit records: 90 days, and some security-audit entries are kept even after other data is deleted.

Your rights

Depending on where you live, you may have rights to access, correct, delete, or export your personal information, or to object to or restrict certain processing. Because the API provider is the primary controller, requests about how they use your data are best directed to them; they can see and delete your identity in their dashboard. For the processing APIblaze carries out (operating sign-in and platform security), contact us at privacy@apiblaze.com; we can find and erase your records across the providers you have signed in to, and we answer within 30 days. You can also revoke the permission you granted your login provider at any time from that provider's settings.

Security

We protect your information with encryption in transit, encryption at rest for stored tokens and secrets, irreversible hashing of API keys, isolation of each provider's data, and access controls. No system is perfectly secure, but we work to protect your information appropriately. Security concerns can be sent to security@apiblaze.com.

If you sign in with APIblaze's shared login

Some providers use a shared APIblaze sign-in option. If you use it, your login provider's consent screen names APIblaze rather than the API provider — but your profile information is still used to give you access to the API provider whose service you are signing in to, as described here. Providers can instead use their own login, in which case their own name appears at that step. When you sign in through a provider's own application, that provider's terms and privacy policy are what you are shown, and they are responsible for naming APIblaze in them.

Children and sensitive data

Our sign-in is not directed at children under 16 and is not intended for the collection of special categories of data (such as health, biometric, or similar sensitive information). Please do not submit such information through sign-in or chat.

Changes and contact

We may update this notice; material changes will be reflected by the date above. Questions can be sent to privacy@apiblaze.com (APIblaze LLC, Birmingham, Michigan, United States). For how a specific API provider uses your data, please see that provider's privacy policy.