This Data Processing Addendum (the "Addendum") forms part of the Terms of Service between Roxy Labs, operating the RoxyAPI service ("Processor", "we", "us"), and the subscribing customer ("Controller", "you"). It governs any processing of personal data that is subject to the EU General Data Protection Regulation (Regulation (EU) 2016/679, "GDPR"), the UK GDPR, or the Swiss Federal Act on Data Protection.

This Addendum is available to every customer on every plan at no additional cost. Article 28 GDPR makes a written processor contract a precondition for lawful processing, so we do not treat it as a paid feature. To put it in force, see How to execute below.

Where this Addendum conflicts with the Terms of Service, this Addendum prevails for matters of data protection. Where it conflicts with the Standard Contractual Clauses referenced in section 11, those Clauses prevail.

1. Roles of the Parties

You are the Controller for all personal data you submit to the API. You determine the purposes and means of processing, you hold the relationship with the individuals whose data you submit, and you are responsible for having a lawful basis for that submission. We are the Processor and act only on your instructions.

Your use of the API constitutes your instruction to compute and return the requested result. We are also an independent controller for a narrow, separate set of data: your account email address, subscription records, and billing metadata, which we process to operate your subscription. That processing is described in the Privacy Policy and is outside the scope of this Addendum.

Payment providers act as independent controllers or as merchants of record for payment data, not as our subprocessors. They are identified on the subprocessor page. We store no payment instrument data of any kind. Card and wallet details are entered on a page hosted by the provider and never reach our systems, so no card number, expiry, security code, or payment token exists in our environment, masked or otherwise. Cardholder data is therefore out of scope for this Addendum in fact and not only by allocation of roles.

2. Processing on Documented Instructions

We process personal data contained in API requests only to compute and return the requested result, and only on your documented instructions, including with regard to transfers to a third country as set out in section 11. We do not process it for any other purpose.

Specifically, and as a contractual commitment rather than a statement of current practice: we do not use personal data submitted through the API to train, fine tune, or evaluate machine learning models; we do not use it for marketing, profiling, advertising, or analytics; and we do not sell, rent, or disclose it to any third party except the subprocessors listed under section 6 or where compelled by law under section 3.

If we believe an instruction from you infringes the GDPR or other applicable data protection law, we will inform you without undue delay.

3. Confidentiality and Legally Compelled Disclosure

Every person authorised to process personal data under this Addendum is bound by a duty of confidentiality that survives the end of their engagement. Access is limited to named personnel who require it to operate and support the service.

If we receive a legally binding request from a public authority for personal data processed under this Addendum, we will notify you before disclosing anything unless the law prohibits that notification. We will review each request for validity, challenge requests that appear unlawful or overbroad, and disclose only the minimum the request compels. Where notification is prohibited we will use reasonable efforts to obtain a waiver and will keep a record of the request for later disclosure.

We have not received any government request for customer personal data as at the date at the top of this page.

4. Security Measures

We implement and maintain the technical and organisational measures set out in Annex II, taking into account the state of the art, the costs of implementation, and the nature, scope, context, and purposes of processing, as required by Article 32 GDPR. We may update those measures over time provided the level of protection is not reduced.

5. What We Store and What We Do Not

This section is the written confirmation EU controllers commonly ask for. It is deliberately precise, including where the answer is less convenient than a blanket denial.

5.1 Request bodies are never persisted

The content of an API request, including birth date, birth time, name, coordinates, and any free-text question, is processed in memory to compute the result and is never written to any database, log, or file. No component of the service records request bodies. When a request fails validation we record the error code and the names of the fields that were invalid, so you can see what to correct. We record field names only, never the values submitted.

5.2 Computed responses may be cached for up to 24 hours

Our calculations are deterministic: identical inputs always produce an identical result. On many calculation endpoints the computed response is therefore held in a short-lived cache so that a repeated identical request does not recompute. The cache entry is addressed by a cryptographic digest of the request, not by the request itself, and expires automatically after at most 24 hours. No account identifier, email address, or name is attached to a cache entry.

We treat that digest as pseudonymised personal data rather than anonymous data, because the set of possible inputs is finite. Responses are never cached at the content delivery network edge: API responses are served with no-store directives, so the cache described here is the only copy that exists anywhere.

5.3 You can switch the cache off per request

Send the standard Cache-Control: no-store request header and we skip the cache entirely: nothing is read from it and nothing is written to it. The response carries X-Cache: BYPASS so you can verify the behaviour in your own integration tests. This is available on every plan and is a commitment under this Addendum, which means an auditor can rely on it. With this header in use, no output derived from the personal data of your end users is retained by us at any point.

5.4 Usage metadata

For billing, rate limiting, and security we record one row per request containing the timestamp, the endpoint path, the response status, the response time, the API key, and the originating IP address and user agent. IP address and user agent are retained for forensic and payment-dispute defence. This metadata is retained for 120 days, sized to the card network dispute window, after which it is deleted automatically. The earliest row for each subscription is preserved as evidence that the subscription was used.

5.5 The website chat assistant is separate

The AI assistant on our website is not part of the API and is not covered by your instructions under this Addendum. Text a visitor types into it is sent to a third-party language model provider identified on the subprocessor page, and because the assistant can run a calculation when a visitor asks it to, that provider also receives the result of any such calculation. Transcripts are retained for 7 days, and birth details supplied in a conversation are retained for 2 hours so the assistant does not have to ask twice. If your compliance posture requires that no personal data reach a language model provider, use the API and do not use the website assistant. No customer API request or response is ever sent to that provider.

5.6 What you do with results is your processing

We do not send data you submit through the API to any language model or analytics provider. Whether you do is your decision and outside our knowledge. Passing our output to a language model is a common and intended use, and it is what our remote MCP servers and our open source AI chatbot template exist to support, so we want the allocation of roles to be unambiguous rather than implied.

Where you forward personal data or results to a model provider, an analytics tool, or any other recipient of your choosing, you are the controller for that disclosure. You select the recipient, you hold the contract with them, and you determine the lawful basis. We are not a party to it, we have no visibility into it, and it is not a subprocessing arrangement under section 6 of this Addendum. Our remote MCP servers are a delivery channel you point at a client of your choosing; the fact that a model client can call them does not make the operator of that client our subprocessor.

6. Subprocessors

You give general authorisation for our engagement of subprocessors. The current list, with the legal entity, role, location, and transfer basis for each, is maintained at roxyapi.com/policy/subprocessors and forms Annex III to this Addendum.

Only two subprocessors are in the API request path, and both are infrastructure providers. Every other subprocessor supports the website, email, or billing and never receives an API request or response.

Before adding or replacing a subprocessor that would process personal data submitted through the API, we will give you at least 30 days notice by email to the address on your account. You may object on reasonable data protection grounds within that period. If we cannot accommodate a reasonable objection, you may terminate the affected subscription and receive a pro rata refund of prepaid fees for the unused remainder of the term.

We impose data protection obligations on every subprocessor that are no less protective than those in this Addendum, and we remain fully liable to you for the performance of each subprocessor.

7. Assistance with Data Subject Requests

We hold no identifier that links an API request to a named individual. We do not store request bodies, and we do not receive the account identifiers your own system uses. In practice this means we are unable to locate an individual in our systems from a name or email address, and there is normally nothing for us to retrieve, correct, export, or erase.

Where a data subject request nonetheless requires action on our side, the scope is limited to the short-lived response cache described in section 5.2 and the usage metadata in section 5.4. On your written request we will delete a specific cache entry, and we will confirm the retention period applicable to metadata. We will respond to a request for assistance within 5 business days.

Requests reaching us directly from one of your end users will be redirected to you as Controller rather than actioned, and we will tell you that it happened.

8. Personal Data Breach Notification

Article 33(2) GDPR requires a processor to notify the controller of a personal data breach without undue delay. The 72-hour deadline in Article 33(1) is your obligation to your supervisory authority, not ours, so our notification is designed to leave you time to meet it.

We will notify you by email to the address on your account within 48 hours of becoming aware of a personal data breach affecting personal data processed under this Addendum. The notification will describe the nature of the breach, the categories and approximate volume of data and data subjects affected so far as known, the likely consequences, the measures taken or proposed, and a named point of contact. Where the full picture is not yet established we will send an initial notification within that window and follow up in phases without further undue delay.

We will assist you in meeting your own obligations under Articles 33 and 34, and we maintain a record of breaches and remedial action.

9. Deletion and Return on Termination

On termination of your subscription, API access stops and no further personal data can be submitted. Because request bodies are never persisted, there is no store of submitted personal data to return or delete. Any remaining cache entry expires automatically within 24 hours of the final request.

At your choice we will delete or return any personal data processed on your behalf that does remain, and delete existing copies, except where retention is required by law. Usage metadata is deleted on the 120 day cycle described in section 5.4. Account and billing records are retained for the period stated in the Privacy Policy to meet financial and tax obligations, which is a legal requirement rather than a processing purpose of yours.

Results you already retrieved during a paid term remain yours to keep and use after termination. See the License page for the terms of that grant.

10. Audits and Evidence of Compliance

We will make available the information necessary to demonstrate compliance with Article 28. In practical terms, and stated plainly so you can plan your own assessment:

We do not hold a SOC 2 report or an ISO 27001 certificate of our own. We will not imply otherwise.
Our hosting provider holds an ISO/IEC 27001:2022 certificate covering the data centre where your data is processed. The certificate is published by that provider and is identified on the subprocessor page.
We will complete a written security and data protection questionnaire on request, and provide a summary of our most recent internal security review.
You may audit our compliance with this Addendum once in any 12-month period, on 30 days written notice, conducted remotely, during business hours, subject to confidentiality undertakings, and without access to the data of other customers. We will bear our own costs for one such audit per period. Additional audits, or an audit conducted by a third party you appoint, are at your cost.
Where a supervisory authority requires an on-site inspection, we will cooperate and will not treat the frequency limit above as a reason to refuse.

11. International Transfers

Personal data submitted through the API is stored and processed in Germany. The servers, the database, and the cache are located in Nuremberg, Germany, inside the European Union. Data at rest does not leave the EU.

There is one third-country element and we state it plainly rather than leave you to discover it. Roxy Labs is established in New Delhi, India, and our engineering personnel administer the infrastructure remotely from there. Under European Data Protection Board Guidelines 05/2021, remote access from a third country is a transfer even where it consists only of data being displayed on a screen. We therefore treat that administrative access as a restricted transfer.

For that transfer, and for any onward transfer to a subprocessor outside the EU, we rely on the Standard Contractual Clauses adopted by the European Commission in Implementing Decision (EU) 2021/914, Module Two (controller to processor), which are incorporated into this Addendum by reference and executed as part of it. For UK transfers the International Data Transfer Addendum to those Clauses applies. For Swiss transfers the Clauses apply with references read as references to the Swiss Act and the Federal Data Protection and Information Commissioner.

India is not the subject of an adequacy decision under Article 45 GDPR. We do not suggest otherwise, and we do not ask you to rely on an expectation that one is forthcoming.

12. Transfer Impact Information

A transfer impact assessment is yours to make as Controller. Our part is to give you accurate facts to make it with. The following is provided for that purpose and may be quoted directly in your assessment.

What is transferred. Nothing is exported in bulk. The transfer consists of the possibility of authenticated administrative access to systems located in Germany. The categories of data that could in principle be visible are those in Annex I.
What an administrator can actually reach. Because request bodies are never persisted, there is no store of submitted birth data to access. The only place output derived from end-user personal data exists is the cache described in section 5.2, holding computed results for at most 24 hours, addressed by digest, with no name or account attached, and switchable off by you under section 5.3. This is the substantive supplementary measure and it is stronger than an access control, because it limits what exists rather than who may look at it.
Who may access it. A small number of named engineering personnel, using individual authenticated accounts with multi-factor authentication. There is no shared administrative credential and no bulk export facility in the product.
Applicable third-country law. India has enacted the Digital Personal Data Protection Act 2023, which establishes duties for data fiduciaries and a Data Protection Board. Indian law also contains state powers of access, including under the Information Technology Act 2000 and the Telegraph Act 1885, and section 36 of the 2023 Act permits the government to require information from a data fiduciary. Any such power would in practice be directed at data held by us, which for API request content is nothing.
Practical likelihood. We are a small commercial provider of deterministic calculation services. We are not a communications provider, we hold no bulk personal dataset, and we have received no government access request to date. We will notify you of any such request under section 3 unless prohibited.
Your levers. Sending the no-store header removes retained derived output entirely. Submitting coordinates rather than a place name, and omitting names or other direct identifiers from requests, further reduces what is ever transmitted, and the API does not require a name to compute a chart.

13. Liability

The limitations and exclusions of liability in the Terms of Service apply to this Addendum, except that nothing in this Addendum limits any liability that cannot be limited under applicable data protection law, including liability to a data subject under Article 82 GDPR or under the Standard Contractual Clauses.

Annex I: Description of Processing

Parties

Data exporter and Controller: the subscribing customer, as identified by the account and billing details on the subscription. Contact: the account email address.

Data importer and Processor: Roxy Labs, a sole proprietorship established in New Delhi, Delhi, India, operating the RoxyAPI service. Data protection enquiries reach us through the contact page. The full registered address, the named data protection contact, and the name and capacity of the signatory are set out in the executed copy of this Addendum, which we provide on request under How to execute below.

Subject matter, nature, and purpose

Provision of a hosted calculation and reference API. The nature of the processing is computation of a deterministic result from the inputs supplied in a request, and return of that result to the Controller. The purpose is limited to producing the requested result.

Categories of data subjects

The end users of the Controller, and any other individual whose details the Controller chooses to submit, for example a second person in a compatibility calculation.

Categories of personal data

Date of birth, time of birth, place of birth or geographic coordinates, and optionally a name and a free-text question. The Controller decides what to send. A name is not required to compute any result.

Special categories of data

The Controller should assume that date of birth combined with time and place of birth, and any free-text question, may reveal or imply information capable of falling within Article 9 GDPR, including philosophical or religious belief and in some contexts information relating to health. We do not require the Controller to send such data and we apply the same in-memory-only treatment to every request body regardless of category. The Controller is responsible for establishing an Article 9 condition where one is required.

Frequency and duration

Continuous, on each API request, for the duration of the subscription. Retention is as set out in section 5.

Annex II: Technical and Organisational Measures

Measures in force as at the date at the top of this page, provided under Article 32 GDPR. Where a measure is not in place we say so rather than omit it.

Data minimisation by architecture

Request bodies are never written to persistent storage. This is the primary measure and the one that limits the impact of every other risk on this list.
The service is stateless with respect to end users. No end-user account, profile, or history exists.
Failure diagnostics record field names and error codes only, never submitted values.
Derived output is retained for at most 24 hours and can be disabled per request.

Encryption

All traffic to the API and the website is encrypted in transit with TLS. Plain HTTP requests are redirected and modern cipher suites are enforced.
Traffic between the edge network and the origin server is encrypted, and the origin accepts connections only from the edge network.
API keys are stored as keyed cryptographic signatures rather than in a recoverable form, so a key cannot be read back out of our systems. We describe this as signing rather than encryption because that is what it is.
Full-disk encryption at rest on the hosting volume is not claimed, and we state that plainly rather than imply otherwise. Two facts bound what it would protect. Request bodies are never persisted, so the data at rest consists of account, subscription, and usage-metadata records rather than end-user personal data. And the primary risk that at-rest encryption addresses, recovery of data from decommissioned media, is covered by the hosting provider: replaced drives are physically destroyed on site and never leave the premises in a recoverable form.

Deletion and media disposal

Retention limits in section 6 are enforced by scheduled deletion rather than by manual review, so expiry does not depend on anyone remembering to act.
Cached derived output expires automatically by time to live and is not deleted by hand.
Storage media replaced by the hosting provider are physically destroyed on site.

Access control

Administrative access is limited to named personnel with individual authenticated accounts and multi-factor authentication. No shared administrative credentials.
The database and the cache are not exposed to any public network interface and are reachable only from the application on a private network.
Administrative interfaces are authenticated, excluded from search indexing, and additionally restricted by geography.
Customer API keys are scoped to the subscription that owns them and can be revoked by the customer immediately from the account dashboard.
Browser-safe publishable keys support an origin allowlist so a key embedded in a web page cannot be reused from another site.

Network and application security

A managed edge network provides DDoS mitigation and a web application firewall.
Per-key rate limiting and quota enforcement, with automated abuse detection and blocking of hosts probing for vulnerabilities.
Bot challenge on public form submissions.
Content Security Policy, strict transport security, and related response headers on all site responses.
All input is validated against a published schema before processing, and validation failures are rejected without reaching calculation logic.

Organisational measures

Confidentiality obligations for all personnel with access to systems.
Written data protection instructions equivalent to this Addendum imposed on every subprocessor.
Internal security review, with findings and remediation status tracked.
Documented incident response covering detection, containment, notification under section 8, and post-incident review.
Change control through version-controlled deployment with automated checks.

Availability and resilience

Uptime monitoring with alerting, and a published service status commitment.
Calculation results are reproducible from inputs by design, so a computed response can always be regenerated and is never the sole copy of anything.
Account and subscription records are backed up automatically every day, retained on a rolling schedule of seven daily, four weekly, and six monthly copies. Backups contain no API request payloads, because those are never stored.
Two limits on that backup regime, stated rather than glossed. The copies are held on the same infrastructure rather than replicated off site, and they are compressed but not encrypted. Off-site encrypted backup is a known gap we are addressing. It does not affect end-user personal data, which is not stored at all.

Subprocessor assurance

The hosting provider operates an information security management system certified to ISO/IEC 27001:2022 covering the data centre in use.
Each subprocessor is engaged under a data processing agreement incorporating Standard Contractual Clauses where it is established outside the EU.

Annex III: Subprocessors

Maintained as a living list at roxyapi.com/policy/subprocessors, which forms part of this Addendum and records the date of the most recent change.

How to Execute

This Addendum takes effect automatically for every customer whose processing falls within its scope, with no signature required. Publication here is deliberate: it means you can complete your assessment before you pay us anything.

If your procurement process needs a counter-signed document, request one through our contact page. We will return a signed copy carrying the full registered address and signatory details, with the Standard Contractual Clauses and annexes attached, normally within 2 business days. Reasonable redlines are available on the Business and Enterprise plans.

Data protection enquiries, including notices under this Addendum, reach us through the contact page.