Every API, on every plan

The unit everything is priced in. Each API has a price in credits, and a request that is answered costs that many:

• 1 — every calculation: a kundli, a dasha tree, the divisional charts, a day's panchang, a match, a drawn chart;
• 5 — each written reading, and the horoscope by sign;
• 10 — upcoming events and Sade Sati, which scan a span of time against a kundli;
• 20 — a month of panchang, a month of ephemeris, a gochar scan, the transit events of a year;
• 500 or 1,000 — a PDF.

The full table is Credits per API. Choosing less inside a request does not change its price: divisional charts cost 1 whether you ask for sixteen or three.

Three things cost no credits at all: GET /v1/reference/* (the static tables of planets, signs, nakshatras, ayanamsas and the rest), GET /v1/timezone (which zone covers a coordinate, and its offset then), and GET /v1/health. The first two still want a key and still spend a token from your per-minute bucket; the last wants neither.

No. Every plan, Free included, can call every calculation, every written reading and every scan. Plans differ in how many credits they hold, how many requests a minute they allow, and what a credit costs — not in what you may call.

The one exception is PDFs, which are not on Free. They are on every paid plan, with a monthly cap (below).

No. The credits are reserved before the calculation starts and given back the moment the request is refused, so a validation error, an invalid key, a rate limit, a quota stop or a failure on our side all cost nothing. Only an answer is charged for.

The refusal still appears in your usage as an error, because knowing your error rate is the point of the chart.

Yes, and at the same price. A cache hit is an answer — you asked, you got the numbers — so it costs what a fresh one does. The cache exists to make the answer fast, not free.

It also means asking the same question twice is honest: identical requests give identical answers for 24 hours, and X-KJ-Cache: hit in the response tells you which one you got. Five endpoints are never cached because their answer is about the moment it was computed — the dasha chain, the Kota chakra, a comparison, a transit "now" and an events feed with no window.

It is on the answer. Every JSON response carries meta.credits, and every metered response — a PDF included — carries the header X-KJ-Credits. A request made with a secret key also gets X-KJ-Credits-Remaining: what is left of the month and of your packs together. A publishable key never gets that header, because it sits in a web page and your balance is not your visitors' business.

GET /v1/reference/credits returns the table in force, and the dashboard shows credits and requests by endpoint and by day.

Five endpoints compute a great deal more than the others. They are open on every plan, and they carry their own limit of 10 requests a minute on top of the plan's rate, because a credit price does not stop ten month-long scans arriving in the same second:

• POST /v1/panchang/month — the panchang of every date in a month;
• POST /v1/ephemeris/month — a month of daily positions, ingresses and stations;
• POST /v1/transit/scan — every gochar event in a window of up to 366 days;
• POST /v1/transit/events — the year's ingresses and stations, the same for everyone;
• POST /v1/match/batch — many Ashtakoot pairs in one request.

The PDF routes share that limit. The scan, the batch and the PDFs are also closed to publishable (kj_pub_…) keys, whatever plan the account is on: a key that lives in a web page should not be able to start a year-long scan. The two month endpoints and the year's transit events are open to them, so a calendar on a web page works without a server.

By what is in them. A match batch costs 1 credit per pair: thirty pairs, thirty credits. The whole kundli report costs 5 credits per part: 40 for all eight, 15 if you ask for three. Both cost exactly what the separate requests would — they save you the round trips, not the credits.

The batch schema allows up to 100 pairs; the 8 KB body limit means about thirty in practice. A pair that cannot be computed returns its own error inside the response without costing the others their answer.

PDFs — a printable kundli, match, varshphal or monthly panchang with your own name, logo and colours — are on every paid plan, and not on Free. A kundli PDF costs 1,000 credits; a match, varshphal or monthly panchang PDF costs 500. That is far more than the same content over the API, on purpose: rendering is what costs us.

Each PDF also counts against a monthly cap: 50 on Starter, 200 on Growth, 500 on Scale, 2,500 on Enterprise (or as your contract says), reset on your billing day with the credits. The same PDF asked for again within 24 hours comes back from the cache without using the cap; it still costs its credits. Past the cap the answer is 402 pdf_quota_exceeded, and everything else keeps working. The PDF guide has the details.

Extra credits on the plan you are already on, for the month that runs over: 10,000 for ₹349 ($4) on Starter, 50,000 for ₹1,099 ($13) on Growth, 250,000 for ₹2,999 ($35) on Scale. You buy one from the dashboard's Plan page, as often as you need. Free has no packs — it upgrades — and Enterprise has what its contract says.

• Your plan's monthly credits are spent first, then packs, oldest first.
• A pack lasts 12 months from the day it is paid for. It does not reset with the month.
• A pack is not refundable and cannot be moved to another account.
• A pack counts only while you are on the plan you bought it on, or a higher one. On a lower plan it is frozen, not lost: it counts again when you move back up, until it expires.
• Packs add credits only. They do not raise the monthly PDF cap.

A credit from a pack costs more than a credit from the plan above, so past a point upgrading is the better deal: on Starter, packs cost more than Growth beyond about 107,000 credits a month. The dashboard tells you when that is true of your usage.

The API answers 402 with the code quota_exceeded until the month rolls over, you buy a credit pack, or you move up a plan. Nothing is silently throttled and nothing extra is billed without you choosing it.

A request that costs more than you have left is refused the same way, and the message says so — a cheaper request still goes through.

Going too fast is different: that is 429 rate_limited with a Retry-After header, and it costs nothing. Every response carries X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset so you can pace yourself before it happens.

Indian accounts are billed in rupees, GST included — the rupee price above is what you pay. GoAppsters Private Limited issues a GST tax invoice for every payment, on the Plan page of your dashboard. Accounts everywhere else are billed in US dollars by card. The country on your account decides which.

Yes — ten months' price for twelve months. Same limits, one invoice. The credits still arrive monthly, and packs are bought separately at the same price either way.

Any time, from the dashboard, on the subscription you already have — changing plan never starts a second one. An upgrade applies immediately, with the difference for the rest of the period pro-rated by Razorpay and charged to the card on file; a downgrade or cancellation takes effect at the end of the period you have paid for, and costs nothing on the day you ask. Your keys keep working across the change.

There is no refund for the unused part of a period, and none for a credit pack, but a first payment for a plan can be refunded in full within 7 days if you have barely used it. The whole of it is in the Refund and Cancellation Policy.

A negotiated contract. The card above is the starting point — 2,500,000 credits a month, 600 requests a minute and 2,500 PDFs — and the real allowance, rate and response time are whatever the contract says; a data-processing agreement comes with it, and PDFs can carry different branding on each request. If you are reselling charts at scale, or need terms your legal team wrote, email support@goappsters.in.

We compute the answer and forget them. Birth details are never written to a database, request bodies are never logged, and the response cache is keyed on a hash of the normalised request rather than on the request itself. What we keep is usage metadata: which endpoint, when, what status, how long — never what was in the body.