Indonesian public data, behind one API key.
A REST API platform that turns scattered Indonesian public data into unified, documented endpoints. We designed it, built it, and we operate it. This page is the long version of how it works, because it is the clearest evidence of what we can build for someone else.
- API groups
- 23API groups
- MCP tools
- 77MCP tools
- Districts covered
- 514Districts covered
Every figure on this page is published on the live product. Follow the link and check it.
The data exists. Using it is the hard part.
Indonesian public data is published. It is just published in pieces, by different bodies, in different shapes, with no shared way to ask a question across them.
Scattered sources
Administrative regions, school registers, hospital directories, and earthquake feeds each live somewhere else, published by a different body, on a different schedule.
Inconsistent shapes
The same idea arrives as a different field name, a different code, a different casing, and sometimes a different file format, depending on where you found it.
Awkward to consume
A developer who wants a list of villages in one district ends up downloading a whole dataset, reshaping it by hand, and rebuilding that work in the next project.
Nobody owns the upkeep
Sources change. A copy pasted into a repository is correct on the day it lands and quietly wrong a year later, with no signal that anything moved.
One shape, one key, one place to ask.
The platform sits between scattered public sources and the application that needs them. Each layer below removes a decision the developer would otherwise have to make themselves.
- 01IngestScattered public sources brought together in one place, on one schedule, under one owner.
- 02NormalizeField names, casing, and identifiers made consistent across groups, so the same client code keeps working as you add another.
- 03ServeREST endpoints grouped by subject, documented per endpoint, and deployed on the Cloudflare edge network.
- 04MeterA single x-api-key header identifies the caller, and credits are counted per successful request.
- 05Expose23 API groups on the REST surface, plus 77 MCP tools for agent and assistant use.
Dataset catalog
PRODUCTIONCounts are the published figures on API Indonesia. The product also reports 99.9% uptime and sub-100ms responses on its own site. Those are its figures, measured by it, not a claim we are making here.
One header. One path. A response you can use.
There is no token exchange step and no client library to install first. Send the key in a header, read the JSON, move on. The panel on the right is drawn for illustration. The exact response for each endpoint is documented on the product itself.
Read the endpoint documentation{
"success": true,
"data": [
{ "code": "11", "name": "Aceh" },
{ "code": "31", "name": "DKI Jakarta" },
{ "code": "35", "name": "Jawa Timur" }
]
}Illustrative shape and values. Endpoint paths, fields, and pagination are documented per endpoint on API Indonesia.
Endpoints are the easy half.
Anyone can return JSON. Turning that into something a stranger will pay for and depend on means keys, credits, plans, a dashboard, documentation, and a deployment somebody keeps an eye on. That is the part we have already shipped.
- 01
Authentication
One x-api-key header. No token exchange, no session, nothing a developer has to read twice before the first call works.
We can build thisKey issuance, rotation, and revocation - 02
Quota accounting
Credits are counted per request, and only successful requests consume them. A failure on our side is not something the caller pays for.
We can build thisCredit ledgers and fair failure handling - 03
Plans and billing
A free tier for evaluation, two paid tiers, and custom plans for anyone whose volume does not fit the published ones.
We can build thisTier design, limits, and upgrade paths - 04
Dashboard
Self-serve. Daily usage, remaining quota, and API key management, so nobody has to email support to find out where they stand.
We can build thisUsage views developers trust - 05
Documentation
Written per endpoint rather than as one long page, because the question is always about one endpoint at a time.
We can build thisReference docs that stay current - 06
Edge deployment
Deployed on the Cloudflare edge network, which keeps the serving path short and the operational surface small.
We can build thisDeployment and rate limiting
What the product charges.
These are API Indonesia's own published prices, listed here so the commercial design is visible alongside the technical one. They are not Khaisa Studio service rates.
Free
no cost- Allowance
- 1,000 requests per month
- Rate limit
- 10 requests per second
For evaluation and small projects
Pro
per month- Allowance
- 50,000 credits
- Rate limit
- 20 requests per second
For a product in production
Business
per month- Allowance
- 250,000 credits
- Rate limit
- 60 requests per second
For higher volume and burst traffic
Custom plans
Volumes that do not fit the published tiers are handled as custom plans. Across every tier the same accounting rule applies: only successful requests consume credits.
Prices, quotas, and rate limits shown here are the figures published on API Indonesia at the time of writing. The live pricing page is the authority.
Check the live pricingShipping it is different from reading about it.
Most of what goes wrong in an API product is not in the endpoint. It is in the questions you only meet after real people start calling it. We have already answered them once, on our own product, with our own money and our own on-call.
- What a credit is, and what happens when a request fails halfway
- How a developer finds out they are near their limit before they hit it
- What a key rotation does to a customer already in production
- Which numbers belong on a dashboard and which ones only look useful
- How documentation stays true after the fourth endpoint changes
- What the deployment does at three in the morning with nobody watching
Have data that should be an API product?
Start with a short fit check. We look at the data, the callers, and the commercial shape, then say plainly whether it is worth building.