Credits & metering
Usage is metered in credits. Every successful response tells you exactly what it cost, in the response itself:
{ "data": { "positions": [ /* ... */ ] }, "meta": { "calc_version": "0.1.0", "settings_resolved": { /* ... */ }, "subject_resolved": { /* ... */ }, "credits_charged": 1 }}meta.credits_charged is present on every success response, without exception. This is deliberate. The standing complaint against metered calculation APIs is credit-burn opacity: you find out what a month of traffic cost from a dashboard, after the fact, with no way to reconcile the number against your own request logs. We refuse to replicate that. With the charge reported in-band, your own logs are the audit trail — sum credits_charged and you have your bill’s usage line, computed independently of ours.
Current prices
Section titled “Current prices”| Endpoint | Credits |
|---|---|
POST /v1/western/positions |
1 |
GET /health |
Free, unmetered |
GET /ready |
Free, unmetered |
Verify it yourself — this call charges exactly one credit and says so:
curl -s https://astral-external-api-iksoi6t3nq-ue.a.run.app/v1/western/positions \ -H "Authorization: Bearer $API_KEY" \ -H "Content-Type: application/json" \ -d '{ "subject": { "datetime": "1992-11-22T08:45:00+05:30", "location": { "latitude": 28.6139, "longitude": 77.209 } } }' | jq .(Assumes API_KEY is exported — see Authentication.)
Errors are never charged
Section titled “Errors are never charged”A 4xx or 5xx response charges zero credits. A request rejected for validation, a 401, a malformed body, a bug on our side, a shed-load 503 — none of them meter. You pay for answers, not attempts. This also means retrying a 503 costs nothing until the retry actually succeeds.
Error responses are problem documents and carry no meta envelope at all, so there is no credits_charged field to misread as a charge.
Planned pricing
Section titled “Planned pricing”Rate limiting
Section titled “Rate limiting”API spec v0.1.0 · docs 0e4f5ec