6 design choices that got developers to actually adopt our free public 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.

Top comments (0)