Astrology API Data Residency: A GDPR Buyer Checklist

You are about to send a stranger the exact minute and place a person was born. That is not an edge case in an astrology product, it is the primary input, and it arrives on the first screen before the user has decided to trust you with anything else.

Most vendor privacy copy answers a different question than the one your legal reviewer will ask. "We do not sell your data" is not a residency statement. "GDPR compliant" is not a document. "EU friendly" is not a country. When an astrology API handles birth data for a European product, the questions that actually decide the review are where the bytes land, which legal entity is responsible for them, and whether you can read the processor terms before you commit.

This is a checklist you can run against any provider, including this one.

Why birth data is not ordinary personal data

Birth date, birth time and birth place are personal data under Article 4 of the GDPR, and the combination is unusually identifying. A date plus a time to the minute plus a town narrows a population to a handful of people, often to one. It is also permanent: a user can rotate a password or change an email address, but nobody gets a second birth minute.

That permanence changes the risk calculation. A breach of birth data cannot be remediated by rotation, only by deletion, so the safest architecture is one where the data was never stored to begin with. When you evaluate a provider, "how well do you secure the birth data you store" is the weaker question. "Do you store it at all" is the one worth asking first.

Ready to build this? The Astrology API returns a complete natal chart in one call and writes no request payload to disk. See pricing.

What to ask a provider before you send it birth data

Ten questions, ordered so the cheapest ones come first. Each is answerable from public information or a single request, and a provider unable to answer any of them has told you something useful.

1. Which country are the servers in? Not which region, not which cloud. A country name, and ideally a city.
2. Does data at rest ever leave that country? Residency is meaningless if backups replicate elsewhere.
3. Are request payloads written to disk at all? Logs, error traces and debug captures count as storage.
4. What does the provider record when a request fails validation? The safe answer is the error code and the names of the invalid fields, never the values submitted.
5. Which legal entity signs the processor terms, and where is it established? Hosting location and controlling entity are separate questions, and only one of them appears on a marketing page.
6. Can you read the Data Processing Addendum before paying? A document behind a checkout, a sales call, or a signature request is one you cannot use in a build-versus-buy decision.
7. Is the addendum on every plan or above a price threshold? Privacy sold as a tier is a pricing decision, not an architectural one.
8. Is there a dated subprocessor register naming each entity, its purpose and its location? Undated lists cannot be diffed.
9. Which subprocessors are actually in the request path? Most of a register supports the website, email or billing and never sees an API payload. That distinction matters to a reviewer.
10. Can you switch caching off per request? Deterministic results are usually cached. You want an explicit, documented way to opt out.

How to verify a data-handling claim instead of trusting it

Four of those checks do not require anyone to answer an email. Run them yourself and compare the result against what the marketing page says.

Read the addendum with an anonymous request. curl -o /dev/null -w "%{http_code}" https://provider.example/policy/dpa returns 200 if the document is genuinely public. A 302 to a login, a 404, or a PDF that only appears in a dashboard after the first charge each answer question six.

Diff the subprocessor register. Save it, check back in a month. A register that carries a revision date and changes when the vendor changes tells you the page is maintained rather than decorative.

Send a deliberately invalid request and read the error body. If it echoes the birth values you submitted back to you, assume those values also reached a log. Post a malformed date to the RoxyAPI chart endpoint and the 400 names the field and the format it expected, with the value you sent absent from the response.

Watch the cache headers, which is the check almost nobody runs. It is covered next, because it is the one that produces a verifiable artifact rather than an opinion.

How to check cache behavior from your own terminal

Every coordinate-dependent call starts with a place lookup, so resolve the city first and feed the result into the chart request. The RoxyAPI location endpoint returns latitude, longitude and an IANA timezone name for exactly this purpose.

# 1. Resolve the birthplace
curl -s "https://roxyapi.com/api/v2/location/search?q=Berlin&limit=1" \
  -H "X-API-Key: YOUR_KEY"

# 2. Chart request, then the same request with caching switched off
curl -i -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":52.52,"longitude":13.405,"timezone":"Europe/Berlin"}'

import requests

h = {"X-API-Key": "YOUR_KEY", "Content-Type": "application/json"}
city = requests.get(
    "https://roxyapi.com/api/v2/location/search",
    params={"q": "Berlin", "limit": 1}, headers=h).json()["cities"][0]

body = {"date": "1990-05-15", "time": "14:30:00",
        "latitude": city["latitude"], "longitude": city["longitude"],
        "timezone": city["timezone"]}

r = requests.post("https://roxyapi.com/api/v2/astrology/natal-chart",
                  json=body, headers={**h, "Cache-Control": "no-store"})
print(r.headers["X-Cache"])

Repeat the chart request without the Cache-Control header and the response carries X-Cache: HIT. Send it with the header and the same request returns X-Cache: BYPASS, captured on both paths against production. That single header is the difference between a documented behavior and an assertion, and you can assert it in your own test suite so a future change on our side breaks your build rather than your compliance posture.

Full request and response schemas are in the API reference, which runs live in the browser with no signup or key required.

When self-hosting is the better privacy answer

If your product covers one tradition, you already run infrastructure in the jurisdiction you need, and you have someone in house who can validate astronomical output, a self-hosted ephemeris library removes the third party from the diagram entirely. That is the strongest privacy position available and no hosted vendor can beat it.

Take the honest version of the trade, though, because the licensing half is the part that surprises teams. The library much of this category is built on, Swiss Ephemeris, is dual licensed: a paid commercial licence, or the AGPL. RoxyAPI does not use it, and runs Roxy Ephemeris instead, but if you are self hosting then this becomes your question rather than a vendor question. AGPL copyleft is triggered by network access rather than distribution, so shipping it behind your own API can reach the code you serve it from, which is why Google bans AGPL dependencies company-wide and says the risks heavily outweigh the benefits. That is survivable: buy the commercial licence, or accept the obligation deliberately. It is only expensive when nobody reads it until diligence. You also inherit the accuracy verification and the on-call.

The calculation is different once a second domain, a second country, or a procurement review enters the picture. At that point the work is no longer the ephemeris, it is the paperwork and the evidence: a processor addendum somebody will read, a register somebody will diff, and headers somebody can reproduce. That is the part worth outsourcing, and it is the part most providers have not written down.

Does a vendor compliance badge make your product compliant?

No, and this is the misreading that costs the most time in a security review. Compliance is a conclusion your own reviewer reaches about your product, your users and your regulator. No vendor can reach it for you, and no badge in a footer transfers it.

Notice that none of the ten checks above asked whether a provider is compliant. What a provider owes you is the raw material for that conclusion: a country, a legal entity, a readable document, a dated register, and behavior you can reproduce from outside. A vendor that supplies all five lets your legal review finish in an afternoon. A vendor that supplies a region word and a compliance claim has quietly moved the work onto your side of the table, and you usually discover that in the week you least want to.

FAQ

Is birth data considered personal data under GDPR?

Yes. Birth date, birth time and birth place are personal data under Article 4, and in combination they are strongly identifying because a date, a minute and a town usually narrow to a single person. Unlike a password or an email address, birth data cannot be rotated after a breach, so storage avoidance matters more than storage hardening.

Where does RoxyAPI store birth data?

It does not store it. Request and response bodies are never written to any database, log or file, which covers birth date, birth time, name, coordinates and any free-text question. What RoxyAPI does store, meaning accounts, subscriptions and usage records, is held in Germany inside the European Union, and that data at rest does not leave the EU. The detail is on the data protection page.

Do I need an enterprise plan to get a Data Processing Addendum?

No. The Article 28 addendum is included on every RoxyAPI plan and published rather than negotiated, so you can read it before you buy and no signature is required to rely on it. It carries the processing description, the technical and organisational measures, EU Standard Contractual Clauses, and the transfer information an EU controller needs for its own assessment. Read the Data Processing Addendum in full before you decide.

How do I stop an astrology API from caching a request?

Send the standard Cache-Control: no-store header. On RoxyAPI the cache is then skipped for both read and write, and the response returns X-Cache: BYPASS so you can assert the behavior in your own tests. Without the header, deterministic responses are cached briefly under a cryptographic digest of the request that carries no account, name or email.

Does calling a hosted astrology API create AGPL obligations for my app?

Not with RoxyAPI. Calculations run on Roxy Ephemeris, an in-house engine verified against NASA JPL Horizons, with no AGPL or copyleft exposure, and every plan carries commercial usage rights so you can ship closed source. The question is worth asking any provider, because a hosted API built on an AGPL library without a commercial licence is carrying an obligation somewhere, and you want to know it is on their side of the line.

What should a subprocessor register actually tell me?

It should name each provider as a legal entity, with its purpose, its location and its transfer basis, and it should carry a date so you can diff it. It should also make clear which entries are in the path of an API request, because most entries on a typical register support the website, email or billing and never receive a payload. The RoxyAPI register is published separately from the addendum, so a routine change to the list never edits the contract document you already assessed.

Conclusion

Residency is a question with a country as its answer, and every claim worth making about it can be reproduced from outside by someone who has not paid you yet. Run the ten checks against whichever provider you are evaluating, and keep the four that leave an artifact.

Whichever way the decision goes, run the checks before the integration rather than during the security review, because the cost of discovering the answer late is a migration rather than an email. Start with the Astrology API, where the processor terms, the register and the cache behavior are all readable before you spend anything.