A live system you can inspect.
API Indonesia is live, public, and open to inspection. It shows the product layer around an API, from keys and quotas to documentation and billing.
API Indonesia
We designed it, built it, and we operate it. A REST API platform that turns scattered Indonesian public data into unified, documented endpoints. It is not a case study written after the fact. It is a running product with a self serve dashboard, published pricing, and a free tier anyone can sign up for.
- Indonesian public data is spread across separate agencies and portals.
- The same information arrives in different shapes, with different codes.
- Most teams write the same fetching, cleaning, and matching code again.
- One REST surface over 23 API groups, with consistent responses.
- 77 MCP tools, so an agent can call the same data without glue code.
- A dashboard, documentation, and a billing path around the endpoints.
- Single x-api-key authentication with a self serve dashboard.
- Credit quotas where only successful requests are counted.
- Free and paid plans, deployed on the Cloudflare edge network.
Provinces down to villages, plus postal codes
Schools by NPSN code and universities
Hospital directory across Indonesia
BMKG earthquake feed, refreshed hourly
Prayer schedules, national holidays, Hijri dates
Halal certificates and BPOM product registry
Every figure above is on the live product, not reported only here.
Patterns we build.
These are example system shapes. They show the kinds of workflows and internal tools we build.
Intake to record
A form, an inbox, or a marketplace order becomes a validated record in the system of truth. Duplicates are caught, and bad input is held with its context instead of disappearing.
Lead routing and CRM sync
Deduplicate, enrich, assign to a named owner, and write back. The first response stops depending on who happens to be awake.
Scheduled reporting
Figures pulled from several tools on a schedule, reconciled, and delivered as one report where every number can be traced to its source.
Each of these is built the same way: error handling written alongside the happy path, alerts routed to a named owner, and a runbook handed over at the end. See how a build is scoped.
Judge the work, then bring us the workflow you are tired of babysitting.
A fit check is a short conversation about what is breaking and how often. If it is not a fit, we say so in that call.