6 design choices that got developers to actually adopt our free public REST API

Publishing an open dataset on GitHub is easy. Getting developers to use it is a different problem. Here is what I learned shipping ReceiptEdit's 2026 US sales tax dataset as a free REST API. 1. No auth. No sign-up. Ever. Every API-key ceremony is a step where trial users bounce. The dataset is public. https://receiptedit.com/api/sales-tax/california — that is the entire contract. 2. Match the data shape to how it will actually be consumed 90% of consumers ask "What's the sales tax for X state?" So the top-level endpoint is /api/sales-tax/:state — one state per response. When someone needs all 50 for analysis, the CSV/JSON files sit next to the API at github.com/receiptedit/us-sales-tax-2026 . 3. CORS on. Cache long. Access-Control-Allow-Origin: * Cache-Control: public, max-age=86400, s-maxage=604800 4. Ship an embed alongside the API <iframe src= "https://receiptedit.com/api/embed/sales-tax/california" width= "380" height= "540" style= "border:0" loading= "lazy" ></iframe> Bloggers on Medium/WordPress cannot install an npm package. They can paste an iframe. 5. License permissively Real MIT. Attribution appreciated, never required. Try it API: https://receiptedit.com/api/sales-tax Source: https://github.com/receiptedit/us-sales-tax-2026 Embed: https://receiptedit.com/api/embed/sales-tax/california Docs: https://receiptedit.com/developers Product: https://receiptedit.com Happy to talk API-design tradeoffs in comments.