Skip to main content

OpenAPI Specification

Asterwise serves two OpenAPI 3.1 specifications. Use whichever fits your toolchain.

The two specs

SpecURLUse case
Full spechttps://api.asterwise.com/openapi.jsonDocumentation, API exploration, complete reference
SDK-filtered spechttps://api.asterwise.com/openapi-sdk.jsonCode generation (OpenAPI Generator, openapi-typescript, etc.)

Both are auto-generated from the live FastAPI application, so they stay in sync with deployed behavior.

Why two specs?

The full spec includes every route the application serves — including internal endpoints like authentication, billing webhooks, and OAuth dance routes. Those aren't useful in a customer SDK and produce ugly client method names like auth_callback_oauth_callback_get.

The SDK-filtered spec excludes routes under these prefixes:

  • /v1/auth/
  • /v1/oauth/
  • /v1/billing/
  • /v1/account/
  • /v1/keys/
  • /v1/internal/

It also applies stable operation IDs from a curated 118-entry mapping, producing client methods like getNatalChart() instead of chart_post_v1_astro_chart_post.

Quick start

# Full spec
curl -O https://api.asterwise.com/openapi.json

# SDK-filtered spec
curl -O https://api.asterwise.com/openapi-sdk.json

Spec metadata

The OpenAPI document declares:

  • OpenAPI version: 3.1.0
  • API title: Asterwise API
  • API version: 2026-03-01
  • Server URL: https://api.asterwise.com
  • Auth scheme: HTTP Bearer (with aw_ prefix on tokens)

Already-published Asterwise SDKs

If you're working in Python or TypeScript, you don't need to generate a client — Asterwise publishes maintained SDKs:

Both are built from the SDK-filtered spec and ship with typed ErrorCode enums that narrow correctly inside conditional branches.

Schema stability

Field additions, new endpoints, and new error codes appear in the OpenAPI spec as soon as they ship. The versioning contract still applies — additive changes are non-breaking, and breaking changes would require v2.