Skip to content
AstroWay/api v2.190.0 · agent-setup
all systems operational

Gotchas

None of this is a bug. It is behaviour better learned from documentation than from picking apart a response.

The free plan and any keyless call get an extra _footer field in the body with a credit line. Paid keys never see it. If your parser is strict about unknown fields, this is the first thing it will trip on.

An identical request inside the cache window returns X-Cache: HIT, and such a call spends no credits: the response carries X-Credits-Used: 0 and the balance is handed back. So you cannot measure cost by hammering the same request: you pay once.

aw_test_* spends no credits and does not count toward the account allowance. That is zero, not a small quota. Develop against it and switch to aw_live_* when you are testing billing itself.

The body accepts extra keys and ignores them. The only exception is the explicitly refused short spellings (lat, tz and the rest, see Field formats). So a typo in a field name usually will not announce itself: you get a 200 and a chart computed without your parameter.

Beyond the polar circle the house system is substituted

Section titled “Beyond the polar circle the house system is substituted”

For quadrant systems at |latitude| > 66.5° Swiss Ephemeris quietly returns Porphyry. We do not hide it: the response grows a warning field. Whole Sign and Equal work at any latitude.

The neighbouring case we closed by refusing instead: an unknown houseSystem code no longer returns Placidus under someone else’s name, it returns 400.

A browser pk_ key and a secret aw_ key can carry three limits at once, and none of them substitutes for another:

LimitWhat it saysRefusal
origin listwhere it may be called from403 ORIGIN_REQUIRED / ORIGIN_NOT_ALLOWED
credits_cap_cyclewhat this key may spend429 KEY_BUDGET_EXHAUSTED
allowed_endpointswhat it may call403 ENDPOINT_NOT_IN_SCOPE

The endpoint scope does not exempt account reads: a key narrowed to embed/* cannot read its own usage either. That is deliberate; the reasoning is in Authentication.

A key edit takes effect on the next request

Section titled “A key edit takes effect on the next request”

Keys are cached for 60 seconds, but any change through PATCH /v1/keys/{id} evicts that cache at once. There is no minute to wait out.

Was this helpful?
Suggest an edit

Last updated: