Skip to content

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.

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:

Terminal window
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.)

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.

API spec v0.1.0 · docs 0e4f5ec