Building an embeddable calculator widget from a REST API: how ReceiptEdit ships sales tax as an iframe

#api #html #rest #webdev

Continuing the open sales-tax dataset thread — the useful trick I did not think would matter as much as it did: shipping the data as an embeddable iframe widget, not just a REST API.

The API alone is at receiptedit.com/api/sales-tax — clean JSON, no auth, CORS. But an API needs a developer to consume it. A widget just needs someone to paste an iframe:

<iframe
  src="https://receiptedit.com/api/embed/sales-tax/california"
  width="380" height="540"
  style="border:0;max-width:100%"
  loading="lazy"
  title="California Sales Tax Calculator">
</iframe>

Swap california for any state slug in our 50-state directory and you get the exact same calculator, live, on their page.

Why an iframe wins over a JS SDK

Zero JS on their side. No npm install, no webpack, no CSP conflicts. Blogs on Medium, WordPress, Ghost all accept iframes.
Style isolation. Their CSS cannot break my calculator; my CSS cannot break their page. Same-origin cookies stay separate.
Instant updates. When 2027 rates change I re-render the embed on my server; every embedder gets the new data with zero action.
Server-side render. First byte is HTML; renders before their JS even starts. No layout shift.

The endpoint shape

GET /api/sales-tax/:state
→ { state, code, state_sales_tax_pct, avg_combined_sales_tax_pct, grocery_taxed, lodging_taxes[...] }

GET /api/embed/sales-tax/:state
→ text/html with calculator + inline styles + a small vanilla-JS calc handler

Both endpoints hit the same underlying dataset: github.com/receiptedit/us-sales-tax-2026 (MIT, ~29 KB JSON for all 50 states).