Invoice API for Developers

An invoice API for developers takes structured invoice data, usually JSON, and returns a finished invoice, usually a PDF, so your app can bill customers without anyone opening an editor. Invoice Studio's public API is not live yet. It is in early access, and the form above puts you on the list. This page shows the planned JSON to PDF endpoint as a design preview, labelled draft and subject to change, so you can tell us whether it fits your stack before we freeze it.

What works today is the web app: 28 invoice templates, your logo and brand colour, PDF download, CSV import and export, recurring invoices and emailing with the PDF attached. I have wired invoice generation into client projects more than once, and the bugs were never in the PDF part. They were in rounding, numbering and tax lines. Most of this guide is about getting those right, whichever tool you end up using.

Invoice API for developers: what works today and what is planned?

The API is not live yet. There is no public REST invoice API, no API key and no invoice webhook you can call today, and anyone who tells you otherwise is wrong. The invoice generator API is planned, and developers on the early access list will get the first keys and a say in the request format.

Here is the honest split. "Today" means it works in Invoice Studio right now. "Planned" means it is on the roadmap, not available, and may change.

If you need to generate 10,000 invoices a month from your backend next week, we are not ready for you yet. If you need clean invoices for a few hundred customers a month, the CSV import already gets you most of the way.

What is an invoice generation API?

An invoice generation API is a web service that accepts invoice fields (seller, buyer, line items, tax, currency, dates) and returns a rendered invoice document, usually a PDF. You call it from your own code. This is programmatic invoicing: invoices are created by events such as a completed order, a monthly billing run or a signed contract, rather than by a person typing.

The term covers three quite different products, and the SERP mixes them up:

1. Template to PDF services. You design a template, send JSON, get a PDF. They are good at layout and weak at invoice logic. Most will happily render a total that does not match the lines, because they never calculate anything.
2. Billing platforms with an invoices endpoint. Payment processors and subscription tools create invoices as part of charging a card. The Stripe Invoices API is the best known example. They are strong on payment and weak if you just want a branded document for a bank transfer client.
3. Invoicing apps with an API. The app already knows about invoice numbers, taxes, credit notes and payment status, and the API exposes that. This is where Invoice Studio's planned API sits.

How would the planned JSON to PDF invoice endpoint work?

The plan is one main endpoint, an invoice PDF API: you send an invoice as JSON, Invoice Studio calculates the totals with the same engine as the web app, and you get back the PDF plus the totals it calculated. Everything below is a draft, subject to change, and shared so you can push back before we build it.

1. Authenticate. A secret key in an Authorization header, created in your account settings. Test keys and live keys would be separate.
2. Send the invoice. POST the payload to a render endpoint, draft path /v1/invoices/render. The final hostname and path will be confirmed at launch.
3. Get the result. The response carries the PDF and a JSON summary: subtotal, each tax line, discounts, total and the invoice number used.
4. Retry safely. Send an idempotency key with each request so a network retry does not create a second invoice. This is the same idea as Stripe's idempotent requests, and I would not ship an invoicing API without it.

Draft request payload

This is the payload shape we are designing around. Field names follow what the web app already stores, so nothing here is invented for marketing. The template field also makes it an invoice template API: you pick any of the 28 designs by name.

Draft, subject to change. No endpoint is live. Do not build production code against these field names yet; join the list and we will send the final spec, published as an OpenAPI document, before keys go out.

Draft response

The planned response returns the totals as well as the file. That way your code can compare our total with yours and refuse to send the invoice if they differ by even one cent. Errors would come back in the problem details format from RFC 9457, with the failing field named, for example "items[2].rate must be a decimal string".

One design choice we have not settled: whether to return the PDF bytes directly or a download link. Links that expire after an hour are the most common complaint I hear about PDF APIs, because a customer clicks an old email and gets an error. Our current leaning is to return the bytes and keep the invoice in your account, so nothing expires. If you need hosted links, say so on the form.

What should an invoice API payload include? A worked example

A good invoice payload includes everything a tax authority expects on the document plus enough detail for the API to check the maths. Here is a real-shaped example: a $2,400 website project billed by a small US dev studio, with 50% due upfront.

In the payload, the cleanest way to bill the deposit is one line, "Deposit, 50% of website project (quote Q-0098)", at $1,200.00, with the full breakdown in the notes. Then the final invoice lists all three lines and a negative line for the deposit already paid. Your accountant will thank you, because each invoice stands on its own.

Two things that payload gets right:

• Money as decimal strings. "55.00", not 55.0 as a float. In most languages 0.1 + 0.2 is not 0.3, and invoices are where that shows up.
• A reference back to the quote. Quote Q-0098 in the notes makes approval and matching far easier for the client's accounts payable team.

Rounding: the one-cent bug

Rounding is the bug that reaches customers. Take a UK invoice with 3 items at £19.99 and 20% VAT. Round VAT per unit and you get £4.00 × 3 = £12.00. Round per line and you get 20% of £59.97 = £11.994, so £11.99. Same invoice, one penny apart. Neither is wrong, but your code and your invoice tool must use the same rule. Pick one with your accountant, write it down, and test it with awkward prices like £19.99 and quantities like 3 or 7.

Invoice API vs PDF library vs HTML to PDF: which should you use?

Use an invoice API when you want invoice logic and design handled for you; use a PDF library or an HTML to PDF invoice pipeline when you already have the logic and want full control of the file.

My opinion: if you are under 200 invoices a month, do not build a PDF pipeline. Export a CSV from your database, import it, check the totals on screen, and send. You will spend an afternoon instead of a sprint, and when the API launches you swap the CSV step for a request.

How do invoice numbers, taxes and currencies work through an API?

An invoice API must keep numbers sequential and unique, print the tax details the buyer's country requires, and store money in the invoice currency without silent conversion. Get these three right and the PDF is the easy part.

Invoice numbers

Numbers should come from one sequence per series, issued by one system. If your app and a person in the web editor can both create invoices, let the invoicing system assign the number, and pass your own order ID as a reference instead. Never reuse a number after a failed request; a gap with an explanation is better than a duplicate. Our invoice number format guide covers prefixes and yearly resets, and you can test formats with the free invoice generator.

Corrections

Do not edit an issued invoice through an API. Issue a credit note against it and a new invoice. That keeps your audit trail clean, and in many VAT countries it is the expected way to correct a mistake. See credit memo vs credit note for the wording.

Country notes

Rules vary and change, so treat these as a checklist and confirm with your local tax authority or accountant.

• United States. No federal VAT. Sales tax depends on the state and on what you sell; many services are untaxed in some states and taxed in others. Keep invoice records; the IRS record-keeping guidance explains how long, usually at least 3 years.
• United Kingdom. VAT-registered businesses must show a unique sequential number, the VAT number, the tax point and the VAT amount. GOV.UK's VAT invoice rules list every field. Your payload needs a tax_id on the seller and a tax_pct on each line.
• European Union. Cross-border B2B sales often use the reverse charge, so the invoice shows 0% VAT, both VAT numbers and a reverse charge note. Structured e-invoicing is coming under the EU's VAT in the Digital Age (ViDA) package, built on the EN 16931 e-invoicing standard. A PDF alone will not satisfy those mandates where they apply, so plan for structured data as well, usually UBL or CII files sent over the Peppol network.
• Canada. Show your GST/HST registration number. Rates differ by province, for example 13% HST in Ontario and 5% GST in Alberta, so the buyer's province matters.
• Australia. A GST-registered seller issues a "Tax invoice" with an ABN and 10% GST shown. Put "Tax invoice" in the document title, not just the notes.
• India. GST invoices need GSTIN, HSN or SAC codes and place of supply, with CGST plus SGST inside a state or IGST across states. Large businesses also fall under e-invoicing on the government portal. Details in our GST invoice format guide.
• Bangladesh. Standard VAT is 15%, and registered sellers use the Mushak-6.3 format. Payment details for bKash and Nagad print under "How to pay", which suits local clients who will not do a bank transfer.

Currencies

Send amounts in the invoice currency and let the document show that currency only. If you convert, do it in your system, record the rate and date, and put "Converted at 1 USD = 0.79 GBP on 5 Nov 2026" in the notes. The multi-currency invoicing page has worked examples for GBP, EUR, INR and AUD.

What can you automate today without the API?

Quite a lot. Before the API launches, you can export from your system and CSV import invoices into your account, repeat fixed bills automatically, and create one-off invoices by voice. Here is how to do it now.

1. CSV import for billing runs. Export the month's billable rows from your database, one row per line item, and import them. Check the totals on screen, then email each invoice with the PDF attached. For 50 invoices this takes about 20 minutes once your export query is saved.
2. Recurring invoices for fixed fees. Retainers, hosting and support plans repeat weekly, monthly, quarterly or yearly, with a new number each time. Set it up once on the recurring invoices page and stop touching it.
3. Templates that match your product. Pick one of the 28 invoice templates and set your brand colour, so API-made invoices later look identical to the ones you send now.
4. Voice for the odd one. The one-off consulting day or a quick change for a client is faster to say than to code. The voice invoice generator builds the invoice from a sentence.

If you sell invoicing to your own customers under your brand, that is a different need. Read the white-label invoicing page, and if your clients want a login to see their invoices, the client portal page. Both are also early access.

What mistakes do developers make with invoice PDFs?

The common mistakes are about money and identity, not layout: floats for currency, duplicate numbers on retries, dates shifted by time zones and PDFs that cannot be reproduced later. I have made at least four of these myself.

• Floats for money. Store integer cents or decimal types, send decimal strings. One float bug on 1,000 invoices is 1,000 support emails.
• No idempotency key. A timeout, a retry, and the client gets two invoices with two numbers. Use a key based on your order ID.
• Timestamps instead of dates. 23:30 on 31 October in New York is already 1 November in London. Send plain dates.
• Regenerating old PDFs. If you rebuild a 2025 invoice with this year's template or tax rate, it no longer matches what the client received. Keep the file you sent.
• Missing buyer details. A B2B invoice without the buyer's company name, address or tax ID often gets rejected by accounts payable, which delays payment by a full cycle.
• Totals calculated twice, differently. Your app says $1,200.00, the PDF says $1,199.99. Compare totals before sending, every time.
• No payment instructions. An invoice without "How to pay" is a request, not a bill. Print the bank, Wise, PayPal or bKash details on the document.

Copy-paste wording for automated invoices

Automated invoices still need human wording. Clients read the note and the email, not your JSON. These are the lines I use, ready to drop into the notes field or your email template.

Invoice notes

Deposit invoice: 50% of the website project in quote Q-0098 ($2,400.00). The balance of $1,200.00 will be invoiced on launch. Payment due within 14 days by bank transfer or card link.

Usage invoice for 1 to 31 October 2026: 18,400 API calls at the rate in your order form. A full usage report is attached as CSV. Questions to billing@yourcompany.com, quoting the invoice number.

Reverse charge: customer to account for VAT under Article 196 of Council Directive 2006/112/EC. Supplier VAT number DE123456789, customer VAT number FR12345678901.

Email sent with an automated invoice

Hi Priya, your invoice NOVA-2026-0142 for $1,200.00 is attached as a PDF. It is due on 19 November 2026. Payment details are under "How to pay" on the invoice. This email was sent automatically when your project deposit was approved; reply to it and a real person will answer.

When an automated invoice was wrong

Hi Priya, invoice NOVA-2026-0142 went out with the wrong tax rate. I have issued credit note CN-0019 to cancel it in full and a corrected invoice, NOVA-2026-0143, both attached. Please pay the corrected one only. Sorry for the extra step.

Always say an email was automatic and give a human reply path. Clients forgive a robot; they do not forgive a no-reply address on a bill. More sending tips in how to send an invoice.

Invoice API pricing and launch date: what do we know?

We have not set API pricing or a launch date, and we will not guess here. What we can say is how we are deciding: early access developers will test the endpoint, tell us their monthly volume, and get keys before anyone else.

For reference, the web app plans today are Free, Starter at $3 a month, Pro at $7, Business at $10 and Enterprise at $29, with yearly and lifetime options on the pricing page. The API may sit inside those plans or be priced per invoice. Tell us on the form which you prefer, the rate limit you would need, whether you want an SDK or plain HTTP calls, and how many invoices you would send in a month: 100, 1,000 or 10,000 changes the design more than you would think.

What happens after you join the list

1. You get one email confirming you are on the list. No newsletter unless you ask for it.
2. When the draft spec is ready, we send it to the list for comments before writing the final version.
3. Test keys go to early access developers first, in the order people joined, with priority for anyone who told us their use case.
4. We tell you plainly when it is live, what changed from this preview, and what it costs.

Meanwhile, build your data model so it maps to the payload table above. If your invoices table already has decimal money, plain dates, a units column and a buyer tax ID, switching from CSV to the API will be a small change. If you want more background on picking invoicing tools, the free invoice app guide compares options, and the rest of the Invoice Studio blog covers the tax and payment side.

InvoiceStudio: create invoices by voice, automate billing, and get paid faster. The API is the next step of that. Until then, the free generator on this page and the PDF invoice generator do the job today.