# Data Protection and GDPR

Everything RoxyAPI stores sits in Germany, inside the European Union, and API request payloads are never written to disk at all. If you are evaluating RoxyAPI as a data processor for an EU product, the three pages below are the authoritative documents and this page only routes you to them.

**This page deliberately carries no figures, clause text, or contract terms.** Retention windows, technical measures, transfer bases, and breach commitments live in the documents themselves so there is exactly one authoritative copy of each. Quote those pages, never this one.

## Where the data is

All stored data is hosted in Germany by our infrastructure provider, whose data centre holds its own ISO/IEC 27001 certification. Data at rest never leaves the European Union.

The content of an API request is processed in memory and never written to any database, log, or file. That includes birth date, birth time, name, coordinates, and any free-text question. When a request fails validation we record the error code and the names of the invalid fields, never the values you sent.

## Article 28 Data Processing Addendum

Our processor terms are published and included on every plan, with no signature required to rely on them:

**[Data Processing Addendum](/policy/dpa)**

It carries the Article 28(3) obligations, the processing description, the technical and organisational measures, the subprocessor terms, EU Standard Contractual Clauses, and the transfer information an EU controller needs for its own transfer impact assessment. If your procurement process needs a counter-signed copy carrying our full registered address and signatory, ask through the [contact page](/contact).

## Subprocessors

**[Subprocessor register](/policy/subprocessors)**

The register is dated and names every provider with its legal entity, purpose, location, and transfer basis. It is published separately from the addendum on purpose, so a routine change to the list never edits the contract document you assessed. Only infrastructure providers are ever in the path of an API request; everything else on that page supports the website, email, or abuse handling and never receives an API request or response.

## Caching and the no-store header

Because calculations are deterministic, computed responses are cached briefly on many endpoints. A cache entry is addressed by a cryptographic digest of the request and carries no account, name, or email.

You can switch that off per request. Send the standard `Cache-Control: no-store` header and the cache is skipped entirely, read and write:

```bash
curl -X POST https://roxyapi.com/api/v2/astrology/natal-chart \
  -H "X-API-Key: YOUR_KEY" \
  -H "Content-Type: application/json" \
  -H "Cache-Control: no-store" \
  -d '{"date":"1990-05-15","time":"14:30:00","latitude":40.7128,"longitude":-74.006,"timezone":-5}'
```

The response carries `X-Cache: BYPASS` so you can assert it in your own tests. Available on every plan and committed in the addendum.

## Privacy policy and data subject requests

**[Privacy policy](/policy/privacy)**

It covers what we collect for your account, what the usage logs contain, retention, and how to exercise data subject rights. Because we hold no identifier linking an API request to a named individual, an access or erasure request about an end user is normally a no-op on our side.