The SupaGamma Python SDK is on PyPI

Every SupaGamma endpoint has always been a plain REST call, and plenty of customers were happy writing their own requests against it. But the parts worth getting right — pagination, the estimate-then-download flow, keeping an API key out of your source — are the parts everybody ends up re-implementing. So we wrote the client.

It is on PyPI now:

• pip install supagamma
• Python 3.9 and up. One runtime dependency (httpx), MIT licensed, source on GitHub.

Sync and async from the same package

SupaGamma and AsyncSupaGamma expose an identical surface, so moving a script into an async service does not mean rewriting your data layer. Both read SUPAGAMMA_API_KEY from the environment if you do not pass a key explicitly — the format is validated locally, so a mistyped key fails immediately instead of costing you a round trip and a confusing 401.

Nine namespaces, matching the API

• client.markets — the market catalogue, stats, and cost estimates
• client.trades — raw fills, OHLCV bars, recent trades
• client.series — the stream catalogue and its estimates
• client.download — paid data delivery in CSV, Parquet, or JSON
• client.orders — cart checkout with idempotency
• client.billing — balance, transactions, subscription
• client.account — identity, usage, API keys, GDPR export
• client.system — health and platform stats

Pagination you do not have to write

The catalogue runs to well over a million markets, so anything interesting starts with paging through it. auto_paginate handles that as an iterator — you write a for loop over markets and the client walks the pages underneath, instead of you tracking offsets and deciding when to stop.

Know the cost before you spend it

Downloads are metered, so guessing is expensive. Every paid dataset has an estimate call that reports the rows, the size, and the price for a given window without charging anything — and the SDK exposes it right next to the download it prices. Check first, then pull. Subscribers on an in-tier pull see it come back free; pay-as-you-go customers see exactly what the pull will cost.

What it deliberately does not do

In 0.x the SDK hands back parsed JSON rather than typed response models. That is a considered choice, not an oversight: inventing response types would mean asserting a contract the server does not yet guarantee on every route. We would rather give you the real shape than a confident-looking type that drifts. Typed models land once the API publishes a machine-readable spec to generate them from.

It is version 0.1.0 — early, and shaped by what people actually hit. Issues and requests are welcome on GitHub.