Invoicing API FAQ: Versions, Amendments, and Edits

If you are building against the invoicing API, most of your questions are not about authentication. They are about behavior. What happens when you edit a sent invoice? When does a change become a new version? What can the recipient do without your code knowing? Here are direct answers to the questions that come up most.

Can I create and send an invoice entirely through the API?

Yes. The automated invoicing API lets you create an invoice with line items, pricing, currency, terms, due date, bank details, and your branding, then move it to Sent. You get back the private link your recipient opens. They do not create an account to view or work with it. There is also an MCP server if you want to drive the same actions from an agent or assistant rather than raw HTTP calls.

If you would rather see the whole flow by hand first, you can create an invoice in the UI and watch what each field does before you automate it.

What is the difference between a version and an amendment?

This trips up almost everyone, so it is worth getting straight before you write a line of code.

A version is created when the content changes: line items, pricing, discounts, currency, payment terms, or due date. Change any of those and you get V1, V2, V3, and so on. Each version is a snapshot you can look back at.

An amendment is tracked against the current version and does not bump the version number. PO number and billing edits are amendments. So if the recipient adds a PO number to V2, you still have V2, with the PO recorded as an amendment to it.

The short rule: money and terms make a new version, administrative details are amendments on the current one. If you want the longer explanation with examples, the piece on versions versus amendments in practice covers it.

Which fields can the recipient change, and will my integration hear about it?

The recipient can edit four fields directly: PO number, billing entity, billing address, and AP contact. These are the fields they can edit themselves. When they do, you are notified and you can revert the change. These edits land as amendments, not new versions.

Everything that touches the numbers is sender-only. Line items, pricing, discounts, currency, payment terms, and due date cannot be edited by the recipient. If they want one of those changed, they leave a comment asking for it, and you decide whether to make the edit through your code or the UI. There is no formal approve or decline workflow and no approval button on the recipient side. The invoice moves through Draft, Sent, Viewed, Paid, and that is the whole lifecycle.

Which fields can never change once the invoice is issued?

Four are locked the moment the invoice is issued: invoice number, issue date, sender details, and bank details. Your code cannot patch them afterward, and neither can the recipient. This is deliberate. An invoice number that shifts after you send it is the kind of thing that wrecks bookkeeping and gets you questions from an auditor.

So plan your numbering before you issue. If you are generating numbers in your own system, read up on keeping invoice numbers sequential so you do not end up with gaps or duplicates that you cannot fix later.

How do I handle a client who wants a PO number added after I sent the invoice?

You usually do not have to do anything. The recipient can add the PO number themselves on the invoice link, and it records as an amendment to the current version. If you want to set it programmatically instead, patch the PO field through the API and it behaves the same way: tracked amendment, no new version, no change to the number or issue date.

Either way the invoice stays the same document AP already has in its queue. That matters, because a resent PDF with a new number can restart their clock. The walkthrough on adding a PO number after sending shows why the amendment approach keeps the invoice from going to the back of the line.

Can I create quotes through the API too?

Yes. Quotes support a valid-until date and an accept step where the recipient types their name to sign. Once a quote is accepted you can turn it into an invoice. If your product has a sales flow that ends in a signature before billing, you can wire the whole thing without a human in the loop. The quotes feature is the same shape as invoicing, with the accept step added.

Does JupiterInvoice take the payment?

No. JupiterInvoice is not a payment processor and does not hold or move money. It presents your payment details and tracks the invoice to Paid. You can connect your own Stripe account so the recipient can pay by card, in which case the money flows through your Stripe, not through us. We are not the merchant of record. If you pull reporting from the API, treat Paid as a status your code sets or that the Stripe connection sets, not as a ledger of funds we are holding on your behalf.

What happens to recipient edits after an invoice is marked paid?

They stop. Once an invoice is Paid, the recipient can no longer edit the amendable fields. If something genuinely needs to change after payment, that is a bookkeeping event on your side, usually a credit note, not an edit to a settled invoice. Build your automation so it does not expect to patch a paid invoice.

Where should I start?

Read the API and MCP reference for the endpoints and the exact field names, then create one invoice end to end against a real recipient before you batch anything. If you want a narrative version of the full build, automating invoicing from start to finish walks through it. And if a specific behavior is not covered here, tell us what you are building and we will give you a straight answer.