Astrology API Contract Terms: A Vendor Diligence Guide
Ten contract terms decide whether you can leave an astrology API vendor. Data ownership, training rights, benchmarking, and what to check before you sign.
TL;DR
- The terms that matter are not price and uptime. They are ownership of results after cancellation, training rights, benchmark permission, and notice periods.
- Ask for all of them in writing before integrating, because the cost of switching rises with every user whose saved chart depends on the vendor.
- RoxyAPI grants a perpetual and irrevocable licence to every result retrieved during a paid term, and that licence survives cancellation.
- Read the four governing documents yourself. Every claim below points at the clause it comes from.
Most astrology API evaluations stop at the pricing table. That is the cheapest part of the decision to reverse and the least likely to hurt later. The expensive part is what happens in month eighteen, when fifty thousand users have a saved birth chart, the provider raises prices or removes an endpoint, and the answer to a simple question turns out to be buried in a document nobody read.
The question is: if this vendor becomes unusable tomorrow, what can you keep? Not what can you download, which every API allows in practice, but what are you contractually permitted to continue serving to paying users after the subscription ends. Providers differ enormously on that point, and almost none of them lead with it. Here is the diligence list, the clauses each item lives in, and the honest gaps.
Which contract terms decide whether you can leave an API vendor
Ten terms carry almost all the switching risk, and none of them are visible from a pricing page. They decide what survives the relationship ending, which is a different question from what the API can do while it is healthy. Ranked by how expensive each is to discover late:
- Survival of the result licence after cancellation. Whether stored responses stay usable when billing stops.
- Derived works. Whether translations, summaries, and adaptations you built are yours to keep serving.
- Model training rights. Whether the vendor may train on the data your users submit.
- Storage and caching rights. Whether you may keep responses in your own database indefinitely.
- Benchmark permission. Whether you may test the vendor against another and publish the result.
- Price change notice. How much warning arrives before a renewal costs more.
- Subprocessor change notice. Whether you can object when the vendor adds a new data processor.
- Endpoint removal notice. How much warning arrives before a route disappears.
- Order of precedence. Which document wins when the terms and the data addendum disagree.
- Governing law and venue. Where a dispute is actually heard.
Four published documents answer these, and reading them takes less time than a sales call.
| Document | Governs | Check for |
|---|---|---|
| Terms of Service | Licence survival, availability, precedence, venue | Sections 4, 5.2, 5.4, 15.2 |
| Licence Policy | Scope and duration of rights in API output | Storage, white-label, resale limits |
| Data Processing Addendum | Training, subprocessors, deletion | Training restriction, notice period |
| Refund Policy | Outage compensation, cancellation | Prolonged-outage remedy |
Ready to evaluate against these? The Astrology API publishes all four documents publicly, and pricing is flat per request with every domain on one key.
Who owns the chart data your users depend on after you cancel
This is the single most consequential clause in an API contract and the one most often left vague. The risk is not losing access to new calls, which is expected. The risk is a term that revokes the right to keep using results already delivered, which turns cancellation into a product outage for every user with a saved chart.
RoxyAPI section 5.2 states that the licence to any result lawfully retrieved during a paid term is perpetual and irrevocable and survives cancellation or expiry. A subscription ending stops new API calls and does not require deleting or ceasing use of results already delivered. Section 5.4 extends that to derived works: translations, rewrites, summaries, and structured adaptations are your works, and you may keep producing new outputs from them afterwards, including for customers acquired later.
The limits are narrow. Responses may not be packaged into a bulk data product, sold as a standalone dataset, or re-exposed through a competing API, and plan quota may not be shared with third parties who are not using your product.
Does the API vendor train models on the data you send
Birth data is personal data almost everywhere it is regulated, and a birth chart request carries a date, a time, and a place precise enough to identify a person. Any vendor receiving that stream is in a position to train on it, so the question belongs in diligence rather than in a privacy review after launch.
The RoxyAPI data processing addendum states that personal data submitted through the API is not used to train, fine tune, or evaluate machine learning models, and is not used for marketing, profiling, or advertising. The restriction runs the other way too: customers may not use API responses as training, fine-tuning, or distillation data without prior written consent.
Two things are routinely confused here and the distinction is worth stating plainly. Passing a response through a model at inference time to translate, summarise, narrate, or answer a user question is an ordinary permitted use that needs no consent and no notice, and it is what a Remote MCP integration does on every turn. Training a model on the responses is the separate, gated activity.
Are you allowed to benchmark the vendor and publish the result
Restrictions on publishing benchmark results are a long-standing feature of software and database licensing, and they carry straight into API terms of service. The clause is normally framed as protection against misleading tests. The effect on a buyer is the same either way: the comparison you run before signing becomes something you are not allowed to discuss, so check for it explicitly rather than assuming the right exists.
RoxyAPI section 2.4 permits comparison against other sources for integration testing, discrepancy investigation, quality assurance, and regression testing, with no consent and no notice required. Publishing comparison results that identify RoxyAPI is also permitted, on the condition that the method and the inputs are disclosed so a reader can reproduce them. The comparison harness we run against NASA JPL Horizons is published under an MIT licence at astrology-api-benchmark for that purpose.
This is worth checking on every shortlisted provider, because it is the term that decides whether the accuracy bake-off you run before signing can ever be discussed publicly. A vendor confident in the numbers has no reason to forbid it.
Where RoxyAPI makes no commitment at all
A diligence guide that finds no gaps in its own vendor is marketing. Three items above are not covered.
There is no published endpoint-removal or deprecation window. Item 8 has no clause behind it. The public changelog records what changed and when, but a log is not a notice commitment. If a guaranteed window matters to your build, ask for it in writing rather than assuming it.
There is no contractual service-level credit at the Starter tier. Section 4 sets the target at 99.95 percent uptime, publishes the live figure on an independent status page, and says plainly that no credit is published at Starter. Discretionary compensation for a prolonged outage is available on every plan. A target with a discretionary remedy is not an SLA.
There is no price lock. Prices may change with at least 30 days notice by email, effective on or after the next renewal. That is a notice period rather than protection against an increase, and annual billing is the only lever that fixes a rate.
One further item is a fact rather than a gap: governing law is India and disputes go to arbitration in Mumbai. Surface that early rather than at signature.
How to run the export drill before you sign
The contract answers what you are permitted to keep. The export drill answers whether you could actually leave, and it takes about ten minutes. Run it during evaluation, while switching is still free.
Resolve a birth place first, because every chart endpoint needs coordinates and a timezone rather than a city name:
curl -s "https://roxyapi.com/api/v2/location/search?q=berlin&limit=1" \
-H "X-API-Key: YOUR_KEY"
Then request a chart and store the entire response, not the fields your current screen happens to render:
curl -s -X POST https://roxyapi.com/api/v2/astrology/natal-chart \
-H "X-API-Key: YOUR_KEY" \
-H "Content-Type: application/json" \
-d '{"date":"1990-07-15","time":"14:30:00","latitude":52.5244,"longitude":13.4105,"timezone":"Europe/Berlin"}' \
> chart.json
The response is about 30 KB and carries the angles, planets, houses, aspects, patterns, and per-placement interpretation text together:
{
"ascendant": { "longitude": 210.51743045285548, "sign": "Scorpio", "degree": 0.5174304528554785 },
"midheaven": { "longitude": 131.55265619093097, "sign": "Leo", "degree": 11.552656190930975 }
}
Three checks close the drill. Confirm the stored payload alone can rebuild the user-facing screen with no further calls. Confirm the machine-readable specification is public, so a replacement client can be generated rather than hand-written. Confirm the licence permits serving that stored payload after cancellation, which for RoxyAPI is section 5.2.
FAQ
Can I keep using astrology API data after I cancel my subscription?
With RoxyAPI, yes. The licence to any result retrieved during a paid term is perpetual and irrevocable and survives cancellation, so stored charts continue to serve your users after billing stops. Cancelling ends new API calls only. Verify the equivalent clause on any provider before integrating, because many revoke on termination.
Do astrology API providers train AI models on birth data?
Some do and some do not, and the answer belongs in the data processing addendum rather than the marketing copy. The RoxyAPI addendum states that personal data submitted through the API is not used to train, fine tune, or evaluate machine learning models, nor for marketing, profiling, or advertising. Ask for the clause in writing from any vendor handling birth data.
Am I allowed to benchmark an astrology API and publish the results?
Under the RoxyAPI terms, yes, provided the method and the inputs are disclosed so a reader can reproduce the test. No consent and no notice are required. Our own comparison harness against NASA JPL Horizons is published under an MIT licence so the methodology is reproducible. Check this term specifically on every provider rather than assuming the right exists, because restrictions on publishing benchmarks have a long history in software licensing.
What notice does RoxyAPI give before a price change?
At least 30 days advance notice by email to the address on the subscription, with the change effective only on or after the next renewal date. This is a notice period rather than a price lock. Annual billing fixes the rate for the billing year, which is the only contractual protection against an increase.
Does RoxyAPI offer an SLA with service credits?
Not at the Starter tier. The published target is 99.95 percent uptime with the live figure on an independent third-party status page, and the terms state plainly that no contractual service-level credit is published at that tier. Discretionary compensation for a prolonged outage is available on every plan through the refund policy.
Conclusion
The terms that decide whether an astrology API is safe to build on are ownership of results after cancellation, training rights, benchmark permission, and notice periods, none of which appear on a pricing page. Read the governing documents during evaluation, run the export drill while switching is still cheap, and ask for anything missing in writing.
Every clause referenced here is published rather than negotiated, including the gaps. Start with the Astrology API documents and hold every other provider on the shortlist to the same reading.