Restore a deleted sales invoice
POSThttps://
Clears the soft-delete marker and returns the invoice in the detail view.
Access
- Token scope
- api:
write: sales_invoices Without it:
403 insufficient-token-scope. - Permission
- sales_invoices::
create Without it:
403 insufficient-permission. - Feature
- Needs the billing feature on your organisation.
Without it:
404 endpoint-not-found. - Rate cost
- 1 unit, write bucket. A write costs the same whatever
viewyou ask for. - Also
- Accepts
Idempotency-Key. AcceptsIf-Match. Never cached:private, no-store. Unknown query parameters are refused, never ignored.
Both are checked, scope first. A token never does more than its user. How access is checked
Restoring additionally requires sales_invoices::delete as well as sales_invoices::create. Restoring is not a full undo: deleting the invoice unlinked every worklog that had been settled against its rows and returned those hours to the uninvoiced pool, and restoring brings back the invoice and its rows but not those links, so the hours can be invoiced a second time unless you check them. Restoring an invoice that is not deleted succeeds and returns an already_in_target_state warning. The restore finds a deleted invoice on its own, so the trashed parameter is not accepted.
Path parameters
Query parameters
Unknown parameters are refused with 400, naming the parameter.
Request headers
A correlation id of your own. It is recorded in our logs next to the server's request id but never returned: the response header always carries the server's id. A value that does not match the pattern is discarded silently, never rejected.
Response 200
Returns a SalesInvoice in the detail view.
Headers
ETag- A strong validator of exactly this representation.
Idempotency-Replayedtruewhen this response was replayed from a storedIdempotency-Keyrather than produced by a new write.RateLimit- The IETF
httpapi-ratelimit-headersform of your remaining allowance on the tightest bucket this request touched. RateLimit-Policy- The ceiling and window of that bucket, as
<limit>;w=<seconds>. X-Request-Id- The server-generated ULID correlating this response with our logs.
Every response also carries Cache-Control, Vary, X-Content-Type-Options, X-Plnnrly-Api-Version, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset. Headers and versioning
The customer this invoice is billed to. Expanding it with ?include=customer additionally requires the customers::read permission and a token scope covering the customers prefix.
Customer subscription this invoice was generated from, when it was generated from a renewal.
Invoice number, allocated by the server from the organisation's yearly sequence: B-26-00001 for an invoice raised in this flow, L-1234 for one converted from a legacy invoice. It also works in the path: GET sales-invoices/B-26-00001 works. This is the field ?q= searches.
The customer's own reference, typically a purchase-order number, reproduced on the invoice.
Invoice date, a zone-free calendar date. Newest first is the default sort.
Date payment is due, a zone-free calendar date. Null when no term was applied.
Lifecycle status. Resolved by the server on create and never writable: a caller without sales_invoices::finalize creates a pending_approval invoice, and any update by such a caller returns the invoice to pending_approval.
draftpending_approvalsentpaidoverduecancelled
New values may be added.
Whether the invoice is emailed to the customer when it syncs. The email is sent through the accounting integration, so it is forced to false in an organisation with no integration configured. Writing it requires sales_invoices::finalize.
Sum of the row line totals excluding VAT, as a decimal string. Recomputed from the rows; never written directly.
2 decimal places, may be negative
Sum of the row VAT amounts, as a decimal string. Recomputed from the rows; never written directly.
2 decimal places, may be negative
Subtotal plus VAT, as a decimal string. Recomputed from the rows; never written directly.
2 decimal places, may be negative
The accounting system's own identifier for this invoice, written by the sync. Not a local id.
Sales journal the invoice is booked in, resolved from the organisation's accounting settings on create. Null in an organisation with no integration configured.
How far the invoice has got through the accounting sync. Set on create: local in an organisation with no integration configured, pending otherwise.
pendingsyncedfailedlocal
New values may be added.
Why the last sync attempt failed, verbatim from the accounting system. Null while nothing has failed.
When the invoice last synced successfully.
When the invoice was last handed to the sync, successfully or not.
When the invoice was settled. Set on create for a local invoice that is immediately definitive; otherwise written when payment is registered.
Whether this invoice was converted from a legacy invoice. Such an invoice is read-only: PATCH and DELETE answer 409 state-conflict with reason locked_by_legacy.
The id of the legacy invoice this invoice was converted from, so it can be matched with GET /api/v2/invoices. The legacy invoice may since have been removed.
Notes for colleagues. Never rendered on the invoice the customer receives.
Last-write timestamp; use for incremental sync. It also feeds the ETag revision, because a sales invoice has no version field.
Errors
409 Conflict.
412 Precondition failed.
7 errors every operation can return: 400, 401, 404, 406, 429, 500, 503
400 Bad request.
idempotency-key-requiredinvalid-cursorinvalid-query-parametermalformed-requestunsupported-parameter
401 Unauthenticated.
404 Not found.
406 Not acceptable.
429 Too many requests.
500 Server error.
503 Service unavailable.
This path allows POST. Anything else answers 405.
Something wrong or missing on this page? Tell us