Data Processing Agreement

This Data Processing Agreement (“DPA”) is executed by Octri, LLC and forms part of the Terms of Service. It applies automatically to every customer whose use of Octri involves us processing personal data on their behalf.

You do not need to sign anything. By accepting the Terms, you accept this DPA, and it is in force for your organisation from that moment. We have pre-signed it, which is why there is no countersignature step and no delay while a document goes round.

If your procurement process needs a countersigned PDF naming your legal entity, email founders@octri.dev with the entity name and address and we will return one. That copy restates these terms; it does not change them.

If you have negotiated a separate written data processing agreement with us, that document governs and this one does not apply. Where this DPA conflicts with the Terms of Service on the handling of personal data, this DPA wins.

Three relationships run through Octri, and mixing them up is the usual source of confusion:

• You are the controller of the personal data you put into Octri, and of the personal data your own application sends to monitoring. You decide what goes in, why, and on what lawful basis. We are your processor for all of it. That is what this DPA governs.
• We are the controller of data about our own customers: who holds an Octri account, their organisation, and how they use the dashboard. That is governed by the Privacy Policy, not by this DPA.
• Paddle is an independent controller for payment data. It is our merchant of record, not our processor, and card details never reach our systems.

“Personal data”, “processing”, “controller”, “processor”, “data subject” and “personal data breach” carry the meanings given in the GDPR. “Data Protection Law” means the EU GDPR, the UK GDPR and the Data Protection Act 2018, the Swiss FADP, and US state privacy laws including the CCPA as amended, each as applicable to the processing.

This is Annex I to this DPA. The subject matter of the processing is the provision of the Octri platform; the duration is the term of your subscription plus the deletion window in section 12.

Categories of data subject: your team members who use the dashboard, the readers of your documentation, and, where your application sends it, your own end users.

Special-category data. Octri is not designed for health, biometric, genetic, racial, political, religious or sexual-life data, nor for criminal-offence data, payment card numbers or government identifiers. Do not send it, and do not configure monitoring in a way that captures it.

Monitoring deserves its own section because it is the one part of Octri where personal data about your users can arrive continuously, automatically, and without anyone at either company deciding it should. An unhandled exception carries whatever was in scope when it was thrown. That is the point of error tracking, and it is also the risk.

What arrives

Errors and stack traces, log lines, distributed traces and spans, metrics, release markers, uptime check results, and uploaded source maps. Each event can carry a user identifier, tags, breadcrumbs and a context object, all populated by your instrumentation. We do not decide what any of those contain.

What we strip before storing it

Every ingested payload passes through redaction before it is written to storage, not on the way out to a screen. Two layers run:

• By key. Any field whose name looks sensitive has its value replaced outright. The list covers passwords, secrets, tokens, access and refresh tokens, API keys, authorization and cookie headers, session identifiers, card numbers, CVV, SSN, PIN, private keys and client secrets. Matching ignores separators and case, so api_key, apiKey and api-key all match.
• By value. Strings matching high-confidence patterns are masked even when the key looks harmless: payment card numbers, JSON Web Tokens and bearer tokens, wherever they appear, including inside exception messages and stack frames.

Email addresses are partially masked rather than removed (j***@acme.com), so an issue can still be grouped and counted per affected user without our storing the address. If you would rather they did not arrive at all, do not attach them.

Redaction is a safety net, not a compliance boundary. It catches the shapes it knows. It cannot know that a field you called notesholds a customer’s home address. Deciding what leaves your application is your responsibility as controller, and configuring your instrumentation to send less is the only measure that removes the risk rather than reducing it.

Where it lives

Monitoring data is stored in our own analytics database, on infrastructure we operate. It is not sent to a third-party observability vendor, and it is never used to train any model.

Raw events are deleted after the retention window your plan includes, which runs from 7 days on Free to 365 on Enterprise; the per-plan figures are published in the Fair Use Policy. After that only aggregate rollups survive, and those carry no event payload, so the historical charts stay intact without the underlying records. Uptime check results are kept for 30 days. Expiry is enforced by the storage engine on each record rather than by a sweep job, so it does not depend on anything running on schedule.

Volume is capped, not silently discarded. Ingestion is admitted past your plan allowance up to a burst ceiling so that an incident is never the moment your telemetry stops. Past that ceiling we refuse a reservation with a 429 and a Retry-After, so your SDK backs off rather than losing the batch without noticing. The limits are on the Fair Use Policy.

Deleting it

You can ask us to delete monitoring data for an environment, a project or your whole organisation at any time, and we will do it within 30 days. If a data subject exercises an erasure right against you and their identifier is in your monitoring data, tell us the identifier and we will remove the matching events on the same timeline.

We process personal data only on your documented instructions, including on international transfers, unless we are required to do otherwise by law. Where the law compels us, we will tell you before processing unless that law forbids the notice.

Your instructions are: the Terms of Service, this DPA, the configuration you set in the product, and any further written instruction we agree to. Using a feature is an instruction to perform the processing that feature requires.

We will tell you if, in our opinion, an instruction infringes Data Protection Law. We may suspend the affected processing until the instruction is changed or confirmed.

We do not sell personal data, we do not share it for cross-context behavioural advertising, and we do not use it for our own purposes. Aggregate, de-identified statistics that cannot be attributed to any person or customer may be used to operate and improve the service.

Access to personal data is limited to personnel who need it to deliver the service or to answer a support request you raised. They are bound by written confidentiality obligations that survive their engagement, and their access to a customer organisation is written to that organisation’s own audit log under their own email address, so support access is visible to you rather than invisible.

We implement appropriate technical and organisational measures under Article 32, taking account of the state of the art, the cost of implementation, and the risk to data subjects. The measures in force are listed in section 16, which is Annex II to this DPA.

We may update those measures as the platform changes. We will not reduce the overall level of security during the term. The security page carries the same detail in plainer language, along with our vulnerability disclosure policy.

You give general written authorisation for us to engage subprocessors. The current list, what each one does, what reaches it and where it operates, is maintained on the subprocessors page, which forms Annex III to this DPA.

Before we add or replace a subprocessor that will handle personal data processed under this DPA, we will update that page and email account owners at least 30 days beforehand. You may object on reasonable data-protection grounds within those 30 days by writing to founders@octri.dev. We will work with you to find an alternative; if we cannot, you may terminate the affected part of the service and we will refund any prepaid fees covering the period after termination. That refund is an exception to the no-refund rule in the Terms, and it exists because you should not be locked into a subprocessor you reasonably object to.

Each subprocessor is engaged under a written contract imposing data-protection obligations no less protective than these. We remain liable to you for their performance.

Services you connect — package registries, your DNS provider, your identity provider — are not our subprocessors. Data reaches them on your credentials, at your instruction.

Three features send data to model providers: documentation generation sends the relevant part of your spec, Ask-the-docs sends the reader’s question with the matching documentation passages, and search indexing sends documentation text to an embedding provider. The providers are named on the subprocessors page.

They process this traffic under commercial API terms that prohibit training on it. Neither they nor we train models on your content. Account data, billing data and monitoring payloads are never sent to a model provider.

If your data-protection assessment does not permit sending your content to these providers, the AI features are the ones to leave switched off. Documentation hosting, SDK generation and monitoring all work without them.

Requests come to you, not to us: you are the controller. Taking account of the nature of the processing, we will assist you with appropriate technical and organisational measures, so far as this is possible, in meeting your obligations to respond.

Much of it you can do without us:

• Read, edit and delete documentation, specs and pages directly.
• Export your specs and generated SDKs from the dashboard.
• Read your organisation’s audit log.
• Delete a project, which removes its documentation, analytics, chat sessions and generated artifacts.

For anything the product does not expose, including erasure inside monitoring data, email support@octri.dev and we will act within 30 days. If a data subject contacts us directly about data we hold for you, we will not respond on the substance; we will tell them to contact you, and pass the request on where we can identify you.

We will notify you without undue delay after becoming aware of a personal data breach affecting personal data processed under this DPA, and in any case in time for you to meet your own 72-hour obligation. The notice will describe the nature of the breach, the categories and approximate number of data subjects and records concerned, the likely consequences, the measures taken or proposed, and a contact point. Where we cannot provide all of it at once, we will send what we have and follow up.

Notice is sent to the email address on the account owner’s profile, so keep it current. Notifying you is not an admission of fault by either of us.

We will also assist you, taking account of the nature of processing and the information available to us, with your obligations under Articles 32 to 36: security of processing, breach notification to authorities and data subjects, data protection impact assessments, and prior consultation with a supervisory authority.

You can delete most data yourself at any time, and deletion through the product is immediate for the records it covers.

On termination of the service, or on your written request at any time, we will delete the personal data we process for you within 30 days, except where Data Protection Law requires us to keep it. Backups roll off on their own cycle within the same window. We keep only the minimum needed for tax, accounting and dispute records, which is account and billing data rather than your content.

Export before you terminate. Specs and generated SDKs are downloadable from the dashboard for as long as your account is active. If you need an export we do not offer in-product, ask before termination and we will help.

Anything you deliberately published to a public destination — a public documentation site, a package registry — is outside our control once published, and deletion here does not recall it from third parties.

We will make available the information necessary to demonstrate compliance with Article 28, and allow for and contribute to audits, including inspections, conducted by you or an auditor you mandate.

In practice: send a security questionnaire to founders@octri.dev and we will complete it. For anything beyond that, an audit is on reasonable notice of at least 30 days, no more than once in any twelve-month period unless a breach or a regulator requires otherwise, during business hours, without unreasonable disruption, and subject to confidentiality. You bear your own costs and ours where the audit goes beyond a questionnaire.

We do not hold a SOC 2 or ISO 27001 certification. We would rather say so here than let you discover it in procurement.

Octri is operated from the United States, and our subprocessors operate in the United States and the United Kingdom. Where personal data subject to the GDPR or the UK GDPR is transferred outside the EEA, the UK or Switzerland to a country without an adequacy decision, the transfer is made under the following, which are incorporated into this DPA by reference:

• The EU Standard Contractual Clauses (Commission Implementing Decision (EU) 2021/914), Module Two (controller to processor), with you as data exporter and Octri, LLC as data importer. Clause 7 (docking) applies. Under Clause 9, option 2 (general written authorisation) applies with a 30-day notice period, as set out in section 8. Under Clause 11, the optional independent dispute-resolution body does not apply. Under Clause 17, the Clauses are governed by the law of Ireland. Under Clause 18(b), disputes go to the courts of Ireland. Annexes I, II and III to the Clauses are sections 3, 16 and the subprocessors page respectively.
• The UK International Data Transfer Addendum (version B1.0) to the EU Clauses, for transfers subject to the UK GDPR. Tables 1 to 3 are populated from this DPA and the identified parties; in Table 4, neither party may end the Addendum as set out in Section 19.
• For Swiss transfers,the EU Clauses apply with references to the GDPR read as references to the FADP, the Swiss Federal Data Protection and Information Commissioner as supervisory authority, and “member state” read so as not to deprive data subjects in Switzerland of their right to sue in their place of habitual residence.

Where a term of this DPA conflicts with the Standard Contractual Clauses, the Clauses prevail.

Where you are a business subject to the CCPA as amended and we process personal information on your behalf, we act as a service provider. We do not sell or share that personal information as those terms are defined, do not retain, use or disclose it for any purpose other than performing the service, do not use it outside our direct business relationship with you, and do not combine it with personal information from other sources except as the CCPA permits a service provider to do.

We will notify you if we determine we can no longer meet those obligations, and you may take reasonable steps to stop and remediate unauthorised use. Equivalent terms apply for other US state privacy laws that impose comparable obligations on a processor.

As controller you are responsible for:

• having a lawful basis for the personal data you put into Octri, and giving your own users the notice their law requires, including about monitoring;
• the accuracy of the data you send, and the lawfulness of the instruction that puts it there;
• keeping secrets out of your OpenAPI specs, which end up in published documentation and in SDKs on public registries;
• configuring your monitoring instrumentation to send only what you need, and not sending special-category data through it;
• managing who has access to your organisation, and revoking members and API keys you no longer need;
• responding to data subject requests that reach you.

This DPA takes effect when you accept the Terms and continues while we process personal data for you. Sections on deletion, confidentiality and transfers survive termination for as long as we hold any of the data.

Each party’s liability under this DPA is subject to the limitations and exclusions in the Terms of Service. Nothing here limits a data subject’s rights under the Standard Contractual Clauses or under Data Protection Law.

We may update this DPA to reflect a change in law, in the service, or in our subprocessors. Material changes are posted here and emailed to account owners at least 30 days before they take effect, on the same terms as the subprocessor notice in section 8. Every version carries the date it was last updated.

This DPA is governed by the law of Delaware, United States, except that the Standard Contractual Clauses are governed as stated in section 13.

Octri, LLC
[Registered address to be confirmed before launch]
Data protection and DPA requests: founders@octri.dev
Privacy questions: support@octri.dev

These are the measures referred to in section 7, and Annex II to the Standard Contractual Clauses. They describe what the platform implements today.

For transfers under the Standard Contractual Clauses, these measures apply to the subprocessors listed in Annex III as well, through the contracts described in section 8.