API reference
64 endpoints over the podcast corpus. JSON over HTTPS, one bearer token, and a credit price on every route.
Your first call
curl -s "https://api.pods.wiki/v1/people?limit=5" \ -H "Authorization: Bearer $PODS_WIKI_API_KEY"
Create a key at your dashboard. Every key in a team draws on one credit pool and one rate limit, so you can issue one per application and revoke any of them without taking the others down.
What a response tells you
- X-Credits-Cost
- what this call spent
- X-Credits-Remaining
- what the team has left, across every key
So a client can watch the balance without asking for it. The number is the team’s, not the key’s: five keys share one pool, so five clients see the same figure fall.
When it says no
- 401
- the key is missing, wrong, or revoked
- 402
- out of credits. Buy a top-up, or change plan
- 403
- the key is not scoped here, or your plan excludes it
- 429
- rate limited. Back off and retry
A refused request costs nothing, so a client retrying against a 402 does not dig itself deeper. Your monthly allowance refills on your billing date; credits bought as a top-up never expire and are spent only once the monthly allowance is gone.
What things cost
An endpoint costs what it costs us to serve. These prices are generated from the running API, so they cannot disagree with the meter.
| 0 | Free. Liveness and the catalogue itself. |
| 1 | One record, read by id. |
| 3 | A filtered, paginated listing. |
| 5 | One subject, joined across the corpus. |
| 10 | An aggregate over the whole corpus. |
| 25 | A heavy aggregate. Slow to build, and priced to say so. |
| 50 | Spends an embedding on your text. |
| 200 | Spends a model call. |
| 500 | Spends research budget on a live lookup. |
Working in an assistant rather than a script? The same corpus is an MCP server. .