Customer invoices
Scopes: invoices:read to read, invoices:write to modify.
Read
GET /user-companies/{company_id}/customer-invoices
GET /user-companies/{company_id}/customer-invoices/{invoice_id}
GET /user-companies/{company_id}/customers/{customer_id}/customer-invoices
The third form lists the invoices belonging to a single customer.
Create
POST /user-companies/{company_id}/customers/{customer_id}/customer-invoices
Required fields
Field |
Type |
Description |
|---|---|---|
|
string |
|
|
string |
Three-letter ISO code. |
|
array |
Invoice line objects. |
Optional fields
Field |
Description |
|---|---|
|
Customer identifier. |
|
|
|
|
|
Days until due, as an alternative to |
|
|
|
Amount excluding VAT. |
|
VAT amount. |
|
VAT rate. |
|
Total amount to pay. |
|
Invoice template to render with. |
|
Reference to an order. |
|
Order number shown on the invoice. |
Row object
{
"description": "Product A",
"price": 100.00,
"amount": 1,
"vat": 25.00,
"vat_percent": 25,
"products_id": 0
}
Update and delete
PUT and DELETE are available on the invoice resources, under
invoices:write.
Practical notes
Create a credit note rather than deleting. A sent invoice that turns out to
be wrong should be credited with a type: "CR" invoice referencing the
original, not removed. That is both what the law expects and what the customer
can reconcile against.
Totals. The amount fields are optional because the rows carry the detail, but sending them explicitly lets you verify that your calculation and Economydesk’s agree. Compare rather than assume.
Customers must exist before customer-invoice POST. Create the customer
first through the customer resource using a PAT with both
customers:write and customers:read, or use an existing customer created
in the application. The customer resource is PAT-only; this does not change
the invoice endpoints’ scopes, company gate or existing legacy support.