Last updated: October 1, 2026
This Data Processing Addendum ("DPA") forms part of the Terms of Service, or any other agreement, between Inferbase and the organization using the Service ("Customer") (the "Agreement"). It applies automatically to organizations that use the API to process personal data; a countersigned copy is available on request at legal@inferbase.ai.
1. Definitions
"Data Protection Law" means the laws that apply to the processing of Customer Personal Data under the Agreement, including the GDPR, the UK GDPR, and India's Digital Personal Data Protection Act, 2023. "Customer Personal Data" means personal data in Customer's content (prompts, files, outputs, tool calls and results sent through the API) that Inferbase processes on Customer's behalf. "Controller", "processor", "data subject", "personal data breach" and "processing" have their meanings under Data Protection Law. "Subprocessor" means a third party Inferbase engages to process Customer Personal Data.
2. Roles and instructions
2.1 Customer is the controller (or a processor acting for its controller) of Customer Personal Data, and Inferbase is its processor. Inferbase is a controller of account, billing and usage data about Customer's users, under its Privacy Policy.
2.2 Inferbase processes Customer Personal Data only on Customer's documented instructions. The Agreement, Customer's configuration of the Service (its policies, connected credentials, retention settings, endpoints) and its API requests are those instructions. Inferbase will tell Customer if it believes an instruction breaks Data Protection Law.
2.3 Customer-connected providers. When Customer connects its own provider key or cloud account, requests served through it are sent to that provider under Customer's own agreement with it, on Customer's instruction. That provider is Customer's processor, not Inferbase's subprocessor, and Customer is responsible for that relationship. The same applies to MCP servers, webhooks and other endpoints Customer configures.
2.4 Customer is responsible for the lawfulness of the Customer Personal Data it sends and for giving any notices and obtaining any consents required.
3. Confidentiality
Inferbase ensures that personnel authorized to access Customer Personal Data are bound by confidentiality obligations, and limits access to those who need it to provide, secure or support the Service.
4. Security
Inferbase implements the technical and organizational measures in Annex II and may update them provided the overall level of protection does not decrease.
5. Subprocessors
5.1 Customer gives general authorization for the subprocessors listed at inferbase.ai/subprocessors. Inferbase imposes data protection obligations on each that are no less protective than this DPA, and remains liable for their performance.
5.2 Inferbase will notify Customer at least 30 days before adding or replacing a subprocessor that processes Customer Personal Data. Customer may object on reasonable data protection grounds within that period; the parties will discuss in good faith, and if they cannot resolve the objection, Customer may terminate the affected part of the Service and receive a refund of prepaid, unused fees for it.
5.3 Customer can avoid managed-inference subprocessors entirely for any request by serving it on its own provider keys or cloud accounts, and can restrict which models and providers serve its requests through its routing policies.
6. Assistance
Taking into account the nature of the processing, Inferbase will assist Customer, through the Service's self-serve features where possible, with data subject requests, security, breach notification, data protection impact assessments and prior consultations. Self-serve features include deleting stored request content, disabling content storage per user, organization or key, exporting account data, and deleting the account.
7. Personal data breaches
Inferbase will notify Customer without undue delay, and in any case within 48 hours, after becoming aware of a personal data breach affecting Customer Personal Data, with the information Customer reasonably needs to meet its obligations, and will update it as more becomes known.
8. Deletion and return
Request content is retained as set out in Annex I and can be deleted by Customer at any time. On termination of the Agreement Inferbase deletes Customer Personal Data within 30 days, except copies in backups, which expire within 90 days, and data the law requires it to keep. Before termination Customer may export what the Service offers for export.
9. International transfers
Where Customer Personal Data is transferred out of the EEA, the UK or Switzerland to a country without an adequacy decision, the standard contractual clauses (module two, controller to processor, or module three where Customer is a processor) and, for UK transfers, the UK International Data Transfer Addendum are incorporated by reference, with Annex I and Annex II of this DPA completing their appendices, Indian law governing, and Bengaluru as the forum.
10. Audits
Inferbase will make available the information reasonably necessary to demonstrate compliance with this DPA, including written answers to security questionnaires once a year. Where Data Protection Law requires more, Customer may audit on 30 days' notice, during business hours, at its own cost, under confidentiality, and no more than once a year unless a breach or regulator requires it.
11. Liability and precedence
Each party's liability under this DPA is subject to the limitations in the Agreement. If this DPA conflicts with the Agreement on the processing of Customer Personal Data, this DPA prevails.
Annex I: Details of processing
| Item | Detail |
|---|---|
| Subject matter | providing the Inferbase AI gateway: routing, policy enforcement, serving and logging of API requests |
| Duration | the term of the Agreement, plus the retention periods below |
| Nature and purpose | receiving API requests, classifying them for routing, applying Customer's policies and guardrails, forwarding them to the model provider that serves them, returning outputs, storing request content when enabled, and measuring routing accuracy on stored content |
| Data subjects | whoever Customer's content is about: Customer's users, end users and any person named in prompts or files |
| Categories of data | whatever Customer sends; Customer must not send special categories of data unless agreed in writing |
| Retention | request content: 30 days by default, or not stored when Customer disables storage for a user, organization or key, and deletable at any time; usage and routing records without content: up to 365 days; saved playground conversations: until deleted |
| Subprocessors | inferbase.ai/subprocessors |
Annex II: Technical and organizational measures
Every measure below exists in the Service as of 2026-10-01.
- Encryption in transit: TLS for the website, the API and connections to model providers.
- Encryption at rest of secrets: Customer's provider keys, cloud credentials, MCP tokens and authenticator secrets are encrypted with versioned keys that can be rotated; passwords are hashed; API keys are stored only as hashes.
- Keyless cloud access: AWS accounts through an IAM role assumed with an external id bound to Customer's organization; Google Cloud through workload identity federation with short-lived tokens; no long-lived cloud secret stored for either.
- Access control: role-based access inside each organization (owners, admins, members; project roles). Inferbase staff access to the administration portal requires two-factor authentication, and every change staff make requires a time-limited elevation with a reason, which is recorded.
- Audit logging: append-only logs of security-relevant account and organization actions, viewable by the account owner and organization admins.
- Data minimization and retention: content storage can be disabled per user, organization or key; stored content is purged automatically after 30 days; routing records hold labels and measurements, not content.
- Network and application security: request size limits, rate limits, CSRF protection, security headers, trusted-host checks, bot protection on sign-up, and validation of Customer-supplied URLs (MCP and webhook endpoints are pinned to public addresses).
- Availability and recovery: managed database snapshots by the hosting provider, plus an encrypted weekly backup held off the hosting provider for 90 days, with restores tested and recorded.
- Monitoring: error tracking, service health and failure-rate alerts, provider health probes and automatic failover between providers.
- Webhook integrity: outbound webhooks are signed so Customer can verify them.