hobok.se invoicing API

Answers without a key and without touching the database. Intended for container health checks; it reports that this process is alive and routing, not that its dependencies are reachable.

Unauthenticated, because a code generator needs the specification before the customer has a key.

The integrator's smoke test. Proves the key works, names the hobby business it belongs to, and returns the two values the other endpoints default to: the next invoice number and the payment terms used when due_date is omitted.

Note payment_options here means what the seller offers to be paid through and is printed on the invoice. It is not the same thing as GET /payment-methods, which is how an arrived payment is recorded.

The canonical list, so a client can build its own dropdown without hard-coding strings that then have to be kept in step with this server by hand.

value is what you send and what is stored — and what is printed on the receipt. It stays Swedish even in an English API: three of the five are Swedish payment rails with no English name, and translating the stored value would change what an issued receipt says.

Newest first by invoice number. Line items are omitted here — fetch a single invoice to get them.

Creates an invoice with status sent, allocates the next number in the seller's own sequence, and stores an immutable HTML snapshot that /pdf renders from.

Identify the buyer with either client_id or an inline buyer object — sending both is rejected rather than resolved by a precedence rule. Either way the invoice keeps its own copy of the buyer's details, so editing the customer afterwards never changes an issued invoice.

Rendered from the snapshot stored when the invoice was issued, never from the current templates or settings — an issued invoice must look exactly as it did when it was issued.

Invoices imported from Stripe's own invoicing product have no such snapshot and return 409; use stripe.pdf_url from the invoice instead, which is the document the buyer actually received.

Flips the invoice to paid, stores a receipt snapshot, and books an income transaction so the payment appears in the year's figures.

Only an invoice with status sent can be marked paid; anything else is 409. That guard is what stops a retry booking the income twice — which would overstate the surplus, and the surplus is what the Swedish tax return is filed on. Send an Idempotency-Key to turn that 409 back into the original success.

The Swedish kvitto for a paid invoice, rendered from the snapshot taken when it was marked paid. Available only once the invoice is paid.

Queues the receipt for delivery to the invoice's buyer address. A 200 means queued, never delivered — a separate mailer sends it.

A customer is a convenience for reuse. It is never required: an invoice can be created with an inline buyer instead, and keeps its own copy of the details either way.

Ordered by name, which is how the catalogue is read — by someone choosing something, not in the order things were added.

A product is a copy source for invoice lines and nothing more. There is no product_id on an invoice line: fetch the catalogue and build the lines from it, and the invoice keeps its own copy of what was sold — so editing a product later never changes an invoice already issued.