Elorus

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. DESTRUCTIVE and with no undo in this integration: permanently delete one bill -- a purchase invoice a supplier issued to this organization. Elorus answers 204 with no body. A document that has been sent or paid usually cannot be deleted at all and is voided instead -- see the void tool for the same resource where one exists via DELETE /v1.1/bills/{id}/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. DESTRUCTIVE and with no undo in this integration: permanently delete one cash payment -- money paid OUT, against a bill or a supplier. Elorus answers 204 with no body. A document that has been sent or paid usually cannot be deleted at all and is voided instead -- see the void tool for the same resource where one exists via DELETE /v1.1/cashpayments/{id}/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. DESTRUCTIVE and with no undo in this integration: permanently delete one cash receipt -- money taken IN, against an invoice or a client. Elorus answers 204 with no body. A document that has been sent or paid usually cannot be deleted at all and is voided instead -- see the void tool for the same resource where one exists via DELETE /v1.1/cashreceipts/{id}/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. DESTRUCTIVE and with no undo in this integration: permanently delete one contact -- a client or supplier, with its billing and shipping addresses. Elorus answers 204 with no body. A document that has been sent or paid usually cannot be deleted at all and is voided instead -- see the void tool for the same resource where one exists via DELETE /v1.1/contacts/{id}/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. DESTRUCTIVE and with no undo in this integration: permanently delete one credit note -- credit issued TO a client, which can then be applied against invoices. Elorus answers 204 with no body. A document that has been sent or paid usually cannot be deleted at all and is voided instead -- see the void tool for the same resource where one exists via DELETE /v1.1/creditnotes/{id}/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. DESTRUCTIVE: un-apply one credit application from a credit note -- credit issued TO a client, which can then be applied against invoices -- which puts the amount back on the credit and back onto the document's balance. Elorus answers 204 with no body via DELETE /v1.1/creditnotes/{parent_pk}/applied-credit/{id}/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. DESTRUCTIVE and with no undo in this integration: permanently delete one email template -- the subject and body Elorus uses when it emails a document. Elorus answers 204 with no body. A document that has been sent or paid usually cannot be deleted at all and is voided instead -- see the void tool for the same resource where one exists via DELETE /v1.1/emailtemplates/{id}/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. DESTRUCTIVE and with no undo in this integration: permanently delete one estimate -- a quotation sent to a client before any invoice exists. Elorus answers 204 with no body. A document that has been sent or paid usually cannot be deleted at all and is voided instead -- see the void tool for the same resource where one exists via DELETE /v1.1/estimates/{id}/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. DESTRUCTIVE and with no undo in this integration: permanently delete one expense -- a cost recorded against the organization, optionally billable to a project. Elorus answers 204 with no body. A document that has been sent or paid usually cannot be deleted at all and is voided instead -- see the void tool for the same resource where one exists via DELETE /v1.1/expenses/{id}/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. DESTRUCTIVE and with no undo in this integration: permanently delete one invoice -- a sales invoice issued to a client. Elorus answers 204 with no body. A document that has been sent or paid usually cannot be deleted at all and is voided instead -- see the void tool for the same resource where one exists via DELETE /v1.1/invoices/{id}/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. DESTRUCTIVE: un-apply one credit application from an invoice -- a sales invoice issued to a client -- which puts the amount back on the credit and back onto the document's balance. Elorus answers 204 with no body via DELETE /v1.1/invoices/{parent_pk}/applied-credit/{id}/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. DESTRUCTIVE and with no undo in this integration: permanently delete one numbering sequence -- the counter Elorus draws document numbers from. Elorus answers 204 with no body. A document that has been sent or paid usually cannot be deleted at all and is voided instead -- see the void tool for the same resource where one exists via DELETE /v1.1/numberingsequence/{id}/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. DESTRUCTIVE and with no undo in this integration: permanently delete one product -- a product or service line item, with its price and stock. Elorus answers 204 with no body. A document that has been sent or paid usually cannot be deleted at all and is voided instead -- see the void tool for the same resource where one exists via DELETE /v1.1/products/{id}/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. DESTRUCTIVE and with no undo in this integration: permanently delete one recurring invoice -- the schedule Elorus issues repeating invoices from. Elorus answers 204 with no body. A document that has been sent or paid usually cannot be deleted at all and is voided instead -- see the void tool for the same resource where one exists via DELETE /v1.1/recurringinvoices/{id}/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. DESTRUCTIVE and with no undo in this integration: permanently delete one supplier credit -- credit received FROM a supplier, which can then be applied against bills. Elorus answers 204 with no body. A document that has been sent or paid usually cannot be deleted at all and is voided instead -- see the void tool for the same resource where one exists via DELETE /v1.1/suppliercredits/{id}/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. DESTRUCTIVE: un-apply one credit application from a supplier credit -- credit received FROM a supplier, which can then be applied against bills -- which puts the amount back on the credit and back onto the document's balance. Elorus answers 204 with no body via DELETE /v1.1/suppliercredits/{parent_pk}/applied-credit/{id}/

DESTRUCTIVE and with no undo in this integration: permanently delete one bill -- a purchase invoice a supplier issued to this organization. Elorus answers 204 with no body. A document that has been sent or paid usually cannot be deleted at all and is voided instead -- see the void tool for the same resource where one exists via DELETE /v1.2/bills/{id}/

DESTRUCTIVE and with no undo in this integration: permanently delete one attachment from a bill -- a purchase invoice a supplier issued to this organization -- together with its stored file. Elorus answers 204 with no body, and this integration cannot upload a replacement via DELETE /v1.2/bills/{parent_pk}/attachments/{id}/

DESTRUCTIVE and with no undo in this integration: permanently delete one internal note from a bill -- a purchase invoice a supplier issued to this organization. Elorus answers 204 with no body via DELETE /v1.2/bills/{parent_pk}/notes/{id}/

DESTRUCTIVE and with no undo in this integration: permanently delete one cash payment -- money paid OUT, against a bill or a supplier. Elorus answers 204 with no body. A document that has been sent or paid usually cannot be deleted at all and is voided instead -- see the void tool for the same resource where one exists via DELETE /v1.2/cashpayments/{id}/

DESTRUCTIVE and with no undo in this integration: permanently delete one attachment from a cash payment -- money paid OUT, against a bill or a supplier -- together with its stored file. Elorus answers 204 with no body, and this integration cannot upload a replacement via DELETE /v1.2/cashpayments/{parent_pk}/attachments/{id}/

DESTRUCTIVE and with no undo in this integration: permanently delete one internal note from a cash payment -- money paid OUT, against a bill or a supplier. Elorus answers 204 with no body via DELETE /v1.2/cashpayments/{parent_pk}/notes/{id}/

DESTRUCTIVE and with no undo in this integration: permanently delete one cash receipt -- money taken IN, against an invoice or a client. Elorus answers 204 with no body. A document that has been sent or paid usually cannot be deleted at all and is voided instead -- see the void tool for the same resource where one exists via DELETE /v1.2/cashreceipts/{id}/

DESTRUCTIVE and with no undo in this integration: permanently delete one attachment from a cash receipt -- money taken IN, against an invoice or a client -- together with its stored file. Elorus answers 204 with no body, and this integration cannot upload a replacement via DELETE /v1.2/cashreceipts/{parent_pk}/attachments/{id}/

DESTRUCTIVE and with no undo in this integration: permanently delete one internal note from a cash receipt -- money taken IN, against an invoice or a client. Elorus answers 204 with no body via DELETE /v1.2/cashreceipts/{parent_pk}/notes/{id}/

DESTRUCTIVE and with no undo in this integration: permanently delete one contact -- a client or supplier, with its billing and shipping addresses. Elorus answers 204 with no body. A document that has been sent or paid usually cannot be deleted at all and is voided instead -- see the void tool for the same resource where one exists via DELETE /v1.2/contacts/{id}/

DESTRUCTIVE and with no undo in this integration: permanently delete one attachment from a contact -- a client or supplier, with its billing and shipping addresses -- together with its stored file. Elorus answers 204 with no body, and this integration cannot upload a replacement via DELETE /v1.2/contacts/{parent_pk}/attachments/{id}/

DESTRUCTIVE and with no undo in this integration: permanently delete one internal note from a contact -- a client or supplier, with its billing and shipping addresses. Elorus answers 204 with no body via DELETE /v1.2/contacts/{parent_pk}/notes/{id}/

DESTRUCTIVE and with no undo in this integration: permanently delete one credit note -- credit issued TO a client, which can then be applied against invoices. Elorus answers 204 with no body. A document that has been sent or paid usually cannot be deleted at all and is voided instead -- see the void tool for the same resource where one exists via DELETE /v1.2/creditnotes/{id}/

DESTRUCTIVE: un-apply one credit application from a credit note -- credit issued TO a client, which can then be applied against invoices -- which puts the amount back on the credit and back onto the document's balance. Elorus answers 204 with no body via DELETE /v1.2/creditnotes/{parent_pk}/applied-credit/{id}/

DESTRUCTIVE and with no undo in this integration: permanently delete one attachment from a credit note -- credit issued TO a client, which can then be applied against invoices -- together with its stored file. Elorus answers 204 with no body, and this integration cannot upload a replacement via DELETE /v1.2/creditnotes/{parent_pk}/attachments/{id}/

DESTRUCTIVE and with no undo in this integration: permanently delete one client-facing discussion message from a credit note -- credit issued TO a client, which can then be applied against invoices. Elorus answers 204 with no body via DELETE /v1.2/creditnotes/{parent_pk}/discussions/{id}/

DESTRUCTIVE and with no undo in this integration: permanently delete one internal note from a credit note -- credit issued TO a client, which can then be applied against invoices. Elorus answers 204 with no body via DELETE /v1.2/creditnotes/{parent_pk}/notes/{id}/

DESTRUCTIVE and with no undo in this integration: permanently delete one delivery note -- a despatch document for goods sent to a client. Elorus answers 204 with no body. A document that has been sent or paid usually cannot be deleted at all and is voided instead -- see the void tool for the same resource where one exists via DELETE /v1.2/deliverynotes/{id}/

DESTRUCTIVE and with no undo in this integration: permanently delete one attachment from a delivery note -- a despatch document for goods sent to a client -- together with its stored file. Elorus answers 204 with no body, and this integration cannot upload a replacement via DELETE /v1.2/deliverynotes/{parent_pk}/attachments/{id}/

DESTRUCTIVE and with no undo in this integration: permanently delete one internal note from a delivery note -- a despatch document for goods sent to a client. Elorus answers 204 with no body via DELETE /v1.2/deliverynotes/{parent_pk}/notes/{id}/

DESTRUCTIVE: delete one numbering sequence from a document type -- one of the organization's document kinds, which owns its own numbering sequences. The sequence to remove is named in the REQUEST BODY rather than in the path, which is why this tool takes a body on a DELETE; documents already numbered from it keep their numbers via DELETE /v1.2/documenttypes/{parent_pk}/sequences/delete/

DESTRUCTIVE and with no undo in this integration: permanently delete one email template -- the subject and body Elorus uses when it emails a document. Elorus answers 204 with no body. A document that has been sent or paid usually cannot be deleted at all and is voided instead -- see the void tool for the same resource where one exists via DELETE /v1.2/emailtemplates/{id}/

DESTRUCTIVE and with no undo in this integration: permanently delete one estimate -- a quotation sent to a client before any invoice exists. Elorus answers 204 with no body. A document that has been sent or paid usually cannot be deleted at all and is voided instead -- see the void tool for the same resource where one exists via DELETE /v1.2/estimates/{id}/

DESTRUCTIVE and with no undo in this integration: permanently delete one attachment from an estimate -- a quotation sent to a client before any invoice exists -- together with its stored file. Elorus answers 204 with no body, and this integration cannot upload a replacement via DELETE /v1.2/estimates/{parent_pk}/attachments/{id}/

DESTRUCTIVE and with no undo in this integration: permanently delete one client-facing discussion message from an estimate -- a quotation sent to a client before any invoice exists. Elorus answers 204 with no body via DELETE /v1.2/estimates/{parent_pk}/discussions/{id}/

DESTRUCTIVE and with no undo in this integration: permanently delete one internal note from an estimate -- a quotation sent to a client before any invoice exists. Elorus answers 204 with no body via DELETE /v1.2/estimates/{parent_pk}/notes/{id}/

DESTRUCTIVE and with no undo in this integration: permanently delete one expense -- a cost recorded against the organization, optionally billable to a project. Elorus answers 204 with no body. A document that has been sent or paid usually cannot be deleted at all and is voided instead -- see the void tool for the same resource where one exists via DELETE /v1.2/expenses/{id}/

DESTRUCTIVE and with no undo in this integration: permanently delete one attachment from an expense -- a cost recorded against the organization, optionally billable to a project -- together with its stored file. Elorus answers 204 with no body, and this integration cannot upload a replacement via DELETE /v1.2/expenses/{parent_pk}/attachments/{id}/

DESTRUCTIVE and with no undo in this integration: permanently delete one internal note from an expense -- a cost recorded against the organization, optionally billable to a project. Elorus answers 204 with no body via DELETE /v1.2/expenses/{parent_pk}/notes/{id}/

DESTRUCTIVE and with no undo in this integration: permanently delete one goods receipt -- a record of stock received into a warehouse. Elorus answers 204 with no body. A document that has been sent or paid usually cannot be deleted at all and is voided instead -- see the void tool for the same resource where one exists via DELETE /v1.2/goodsreceipts/{id}/

DESTRUCTIVE and with no undo in this integration: permanently delete one internal note from a goods receipt -- a record of stock received into a warehouse. Elorus answers 204 with no body via DELETE /v1.2/goodsreceipts/{parent_pk}/notes/{id}/

DESTRUCTIVE: delete one goods-receipt numbering sequence -- the counter Elorus draws goods-receipt numbers from. The sequence to remove is named in the REQUEST BODY rather than in the path, which is why this tool takes a body on a DELETE; goods receipts already numbered from it keep their numbers via DELETE /v1.2/goodsreceiptsequences/delete/

DESTRUCTIVE and with no undo in this integration: permanently delete one invoice -- a sales invoice issued to a client. Elorus answers 204 with no body. A document that has been sent or paid usually cannot be deleted at all and is voided instead -- see the void tool for the same resource where one exists via DELETE /v1.2/invoices/{id}/

DESTRUCTIVE: un-apply one credit application from an invoice -- a sales invoice issued to a client -- which puts the amount back on the credit and back onto the document's balance. Elorus answers 204 with no body via DELETE /v1.2/invoices/{parent_pk}/applied-credit/{id}/

DESTRUCTIVE and with no undo in this integration: permanently delete one attachment from an invoice -- a sales invoice issued to a client -- together with its stored file. Elorus answers 204 with no body, and this integration cannot upload a replacement via DELETE /v1.2/invoices/{parent_pk}/attachments/{id}/

DESTRUCTIVE and with no undo in this integration: permanently delete one client-facing discussion message from an invoice -- a sales invoice issued to a client. Elorus answers 204 with no body via DELETE /v1.2/invoices/{parent_pk}/discussions/{id}/

DESTRUCTIVE and with no undo in this integration: permanently delete one internal note from an invoice -- a sales invoice issued to a client. Elorus answers 204 with no body via DELETE /v1.2/invoices/{parent_pk}/notes/{id}/

DESTRUCTIVE and with no undo in this integration: permanently delete one organization branch -- a branch or establishment of the organization. Elorus answers 204 with no body. A document that has been sent or paid usually cannot be deleted at all and is voided instead -- see the void tool for the same resource where one exists via DELETE /v1.2/organizationbranch/{id}/

DESTRUCTIVE and with no undo in this integration: permanently delete one product -- a product or service line item, with its price and stock. Elorus answers 204 with no body. A document that has been sent or paid usually cannot be deleted at all and is voided instead -- see the void tool for the same resource where one exists via DELETE /v1.2/products/{id}/

DESTRUCTIVE and with no undo in this integration: permanently delete one internal note from a product -- a product or service line item, with its price and stock. Elorus answers 204 with no body via DELETE /v1.2/products/{parent_pk}/notes/{id}/

DESTRUCTIVE: delete one stock adjustment from a product -- a product or service line item, with its price and stock, which MOVES THE STOCK LEVEL BACK. Elorus answers 204 with no body via DELETE /v1.2/products/{parent_pk}/stockadjustments/{id}/

DESTRUCTIVE and with no undo in this integration: permanently delete one project -- a billable engagement that time entries and expenses hang off. Elorus answers 204 with no body. A document that has been sent or paid usually cannot be deleted at all and is voided instead -- see the void tool for the same resource where one exists via DELETE /v1.2/projects/{id}/

DESTRUCTIVE and with no undo in this integration: permanently delete one attachment from a project -- a billable engagement that time entries and expenses hang off -- together with its stored file. Elorus answers 204 with no body, and this integration cannot upload a replacement via DELETE /v1.2/projects/{parent_pk}/attachments/{id}/

DESTRUCTIVE and with no undo in this integration: permanently delete one client-facing discussion message from a project -- a billable engagement that time entries and expenses hang off. Elorus answers 204 with no body via DELETE /v1.2/projects/{parent_pk}/discussions/{id}/

DESTRUCTIVE and with no undo in this integration: permanently delete one internal note from a project -- a billable engagement that time entries and expenses hang off. Elorus answers 204 with no body via DELETE /v1.2/projects/{parent_pk}/notes/{id}/

DESTRUCTIVE: delete one extra fee from a project -- a billable engagement that time entries and expenses hang off, which lowers what the project's next invoice will bill. Elorus answers 204 with no body via DELETE /v1.2/projects/{parent_pk}/projectextrafees/{id}/

DESTRUCTIVE and with no undo in this integration: permanently delete one recurring invoice -- the schedule Elorus issues repeating invoices from. Elorus answers 204 with no body. A document that has been sent or paid usually cannot be deleted at all and is voided instead -- see the void tool for the same resource where one exists via DELETE /v1.2/recurringinvoices/{id}/

DESTRUCTIVE and with no undo in this integration: permanently delete one internal note from a recurring invoice -- the schedule Elorus issues repeating invoices from. Elorus answers 204 with no body via DELETE /v1.2/recurringinvoices/{parent_pk}/notes/{id}/

DESTRUCTIVE and with no undo in this integration: permanently delete one supplier credit -- credit received FROM a supplier, which can then be applied against bills. Elorus answers 204 with no body. A document that has been sent or paid usually cannot be deleted at all and is voided instead -- see the void tool for the same resource where one exists via DELETE /v1.2/suppliercredits/{id}/

DESTRUCTIVE: un-apply one credit application from a supplier credit -- credit received FROM a supplier, which can then be applied against bills -- which puts the amount back on the credit and back onto the document's balance. Elorus answers 204 with no body via DELETE /v1.2/suppliercredits/{parent_pk}/applied-credit/{id}/

DESTRUCTIVE and with no undo in this integration: permanently delete one attachment from a supplier credit -- credit received FROM a supplier, which can then be applied against bills -- together with its stored file. Elorus answers 204 with no body, and this integration cannot upload a replacement via DELETE /v1.2/suppliercredits/{parent_pk}/attachments/{id}/

DESTRUCTIVE and with no undo in this integration: permanently delete one internal note from a supplier credit -- credit received FROM a supplier, which can then be applied against bills. Elorus answers 204 with no body via DELETE /v1.2/suppliercredits/{parent_pk}/notes/{id}/

DESTRUCTIVE and with no undo in this integration: permanently delete one task -- a billable activity type time entries are recorded against. Elorus answers 204 with no body. A document that has been sent or paid usually cannot be deleted at all and is voided instead -- see the void tool for the same resource where one exists via DELETE /v1.2/tasks/{id}/

DESTRUCTIVE and with no undo in this integration: permanently delete one time entry -- tracked time on a project, billable or not. Elorus answers 204 with no body. A document that has been sent or paid usually cannot be deleted at all and is voided instead -- see the void tool for the same resource where one exists via DELETE /v1.2/timeentries/{id}/

DESTRUCTIVE and with no undo in this integration: permanently delete one unit of measurement -- the unit a product quantity is expressed in. Elorus answers 204 with no body. A document that has been sent or paid usually cannot be deleted at all and is voided instead -- see the void tool for the same resource where one exists via DELETE /v1.2/unitofmeasurement/{id}/

DESTRUCTIVE and with no undo in this integration: permanently delete one warehouse -- a stock location goods receipts and adjustments move stock through. Elorus answers 204 with no body. A document that has been sent or paid usually cannot be deleted at all and is voided instead -- see the void tool for the same resource where one exists via DELETE /v1.2/warehouse/{id}/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. List this organization's bills -- a purchase invoice a supplier issued to this organization -- with the filtering, search, ordering and page-size query parameters the contract declares. Returns one page; walk it with `page` and `page_size` Elorus also filters this listing by tracking category with a `tc_<trackingcategory_id>` query parameter, which is NOT offered here: its name embeds the id of one of your own tracking categories, so it is a family of parameter names rather than one parameter, and no fixed tool argument can express it. via GET /v1.1/bills/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. Read one bill by id -- a purchase invoice a supplier issued to this organization -- including the nested detail a listing omits via GET /v1.1/bills/{id}/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. Read the email Elorus WOULD send for one bill -- a purchase invoice a supplier issued to this organization -- its recipients, subject and body, resolved from the organization's email template. Nothing is sent: this is the dry run for the POST tool on the same path via GET /v1.1/bills/{id}/email/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. Render one bill -- a purchase invoice a supplier issued to this organization -- to PDF using the organization's document template. Elorus answers a redirect to the generated file, which this integration follows because the method is safe via GET /v1.1/bills/{id}/pdf/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. List this organization's cash payments -- money paid OUT, against a bill or a supplier -- with the filtering, search, ordering and page-size query parameters the contract declares. Returns one page; walk it with `page` and `page_size` Elorus also filters this listing by tracking category with a `tc_<trackingcategory_id>` query parameter, which is NOT offered here: its name embeds the id of one of your own tracking categories, so it is a family of parameter names rather than one parameter, and no fixed tool argument can express it. via GET /v1.1/cashpayments/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. Read one cash payment by id -- money paid OUT, against a bill or a supplier -- including the nested detail a listing omits via GET /v1.1/cashpayments/{id}/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. List this organization's cash receipts -- money taken IN, against an invoice or a client -- with the filtering, search, ordering and page-size query parameters the contract declares. Returns one page; walk it with `page` and `page_size` Elorus also filters this listing by tracking category with a `tc_<trackingcategory_id>` query parameter, which is NOT offered here: its name embeds the id of one of your own tracking categories, so it is a family of parameter names rather than one parameter, and no fixed tool argument can express it. via GET /v1.1/cashreceipts/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. Read one cash receipt by id -- money taken IN, against an invoice or a client -- including the nested detail a listing omits via GET /v1.1/cashreceipts/{id}/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. Render one cash receipt -- money taken IN, against an invoice or a client -- to PDF using the organization's document template. Elorus answers a redirect to the generated file, which this integration follows because the method is safe via GET /v1.1/cashreceipts/{id}/pdf/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. List this organization's contacts -- a client or supplier, with its billing and shipping addresses -- with the filtering, search, ordering and page-size query parameters the contract declares. Returns one page; walk it with `page` and `page_size` Elorus also filters this listing by tracking category with a `tc_<trackingcategory_id>` query parameter, which is NOT offered here: its name embeds the id of one of your own tracking categories, so it is a family of parameter names rather than one parameter, and no fixed tool argument can express it. via GET /v1.1/contacts/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. Read one contact by id -- a client or supplier, with its billing and shipping addresses -- including the nested detail a listing omits via GET /v1.1/contacts/{id}/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. List this organization's credit notes -- credit issued TO a client, which can then be applied against invoices -- with the filtering, search, ordering and page-size query parameters the contract declares. Returns one page; walk it with `page` and `page_size` Elorus also filters this listing by tracking category with a `tc_<trackingcategory_id>` query parameter, which is NOT offered here: its name embeds the id of one of your own tracking categories, so it is a family of parameter names rather than one parameter, and no fixed tool argument can express it. via GET /v1.1/creditnotes/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. Read one credit note by id -- credit issued TO a client, which can then be applied against invoices -- including the nested detail a listing omits via GET /v1.1/creditnotes/{id}/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. Read the email Elorus WOULD send for one credit note -- credit issued TO a client, which can then be applied against invoices -- its recipients, subject and body, resolved from the organization's email template. Nothing is sent: this is the dry run for the POST tool on the same path via GET /v1.1/creditnotes/{id}/email/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. Render one credit note -- credit issued TO a client, which can then be applied against invoices -- to PDF using the organization's document template. Elorus answers a redirect to the generated file, which this integration follows because the method is safe via GET /v1.1/creditnotes/{id}/pdf/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. List the credit-note or supplier-credit amounts already applied against one credit note -- credit issued TO a client, which can then be applied against invoices -- with each application's id and amount via GET /v1.1/creditnotes/{parent_pk}/applied-credit/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. List this organization's document types -- one of the organization's document kinds, which owns its own numbering sequences -- with the filtering, search, ordering and page-size query parameters the contract declares. Returns one page; walk it with `page` and `page_size` via GET /v1.1/documenttypes/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. Read one document type by id -- one of the organization's document kinds, which owns its own numbering sequences -- including the nested detail a listing omits via GET /v1.1/documenttypes/{id}/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. List this organization's email templates -- the subject and body Elorus uses when it emails a document -- with the filtering, search, ordering and page-size query parameters the contract declares. Returns one page; walk it with `page` and `page_size` via GET /v1.1/emailtemplates/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. Read one email template by id -- the subject and body Elorus uses when it emails a document -- including the nested detail a listing omits via GET /v1.1/emailtemplates/{id}/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. List this organization's estimates -- a quotation sent to a client before any invoice exists -- with the filtering, search, ordering and page-size query parameters the contract declares. Returns one page; walk it with `page` and `page_size` via GET /v1.1/estimates/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. Read one estimate by id -- a quotation sent to a client before any invoice exists -- including the nested detail a listing omits via GET /v1.1/estimates/{id}/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. Read the email Elorus WOULD send for one estimate -- a quotation sent to a client before any invoice exists -- its recipients, subject and body, resolved from the organization's email template. Nothing is sent: this is the dry run for the POST tool on the same path via GET /v1.1/estimates/{id}/email/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. Render one estimate -- a quotation sent to a client before any invoice exists -- to PDF using the organization's document template. Elorus answers a redirect to the generated file, which this integration follows because the method is safe via GET /v1.1/estimates/{id}/pdf/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. List this organization's expense categories -- the bucket an expense is booked to -- with the filtering, search, ordering and page-size query parameters the contract declares. Returns one page; walk it with `page` and `page_size` via GET /v1.1/expensecategories/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. Read one expense category by id -- the bucket an expense is booked to -- including the nested detail a listing omits via GET /v1.1/expensecategories/{id}/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. List this organization's expenses -- a cost recorded against the organization, optionally billable to a project -- with the filtering, search, ordering and page-size query parameters the contract declares. Returns one page; walk it with `page` and `page_size` Elorus also filters this listing by tracking category with a `tc_<trackingcategory_id>` query parameter, which is NOT offered here: its name embeds the id of one of your own tracking categories, so it is a family of parameter names rather than one parameter, and no fixed tool argument can express it. via GET /v1.1/expenses/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. Read one expense by id -- a cost recorded against the organization, optionally billable to a project -- including the nested detail a listing omits via GET /v1.1/expenses/{id}/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. List this organization's invoices -- a sales invoice issued to a client -- with the filtering, search, ordering and page-size query parameters the contract declares. Returns one page; walk it with `page` and `page_size` Elorus also filters this listing by tracking category with a `tc_<trackingcategory_id>` query parameter, which is NOT offered here: its name embeds the id of one of your own tracking categories, so it is a family of parameter names rather than one parameter, and no fixed tool argument can express it. via GET /v1.1/invoices/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. Read one invoice by id -- a sales invoice issued to a client -- including the nested detail a listing omits via GET /v1.1/invoices/{id}/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. Read the email Elorus WOULD send for one invoice -- a sales invoice issued to a client -- its recipients, subject and body, resolved from the organization's email template. Nothing is sent: this is the dry run for the POST tool on the same path via GET /v1.1/invoices/{id}/email/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. Render one invoice -- a sales invoice issued to a client -- to PDF using the organization's document template. Elorus answers a redirect to the generated file, which this integration follows because the method is safe via GET /v1.1/invoices/{id}/pdf/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. List the credit-note or supplier-credit amounts already applied against one invoice -- a sales invoice issued to a client -- with each application's id and amount via GET /v1.1/invoices/{parent_pk}/applied-credit/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. List this organization's numbering sequences -- the counter Elorus draws document numbers from -- with the filtering, search, ordering and page-size query parameters the contract declares. Returns one page; walk it with `page` and `page_size` via GET /v1.1/numberingsequence/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. Read one numbering sequence by id -- the counter Elorus draws document numbers from -- including the nested detail a listing omits via GET /v1.1/numberingsequence/{id}/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. List this organization's payment gateways -- an online payment method configured for this organization -- with the filtering, search, ordering and page-size query parameters the contract declares. Returns one page; walk it with `page` and `page_size` via GET /v1.1/paymentgateways/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. List this organization's products -- a product or service line item, with its price and stock -- with the filtering, search, ordering and page-size query parameters the contract declares. Returns one page; walk it with `page` and `page_size` Elorus also filters this listing by tracking category with a `tc_<trackingcategory_id>` query parameter, which is NOT offered here: its name embeds the id of one of your own tracking categories, so it is a family of parameter names rather than one parameter, and no fixed tool argument can express it. via GET /v1.1/products/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. Read one product by id -- a product or service line item, with its price and stock -- including the nested detail a listing omits via GET /v1.1/products/{id}/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. List this organization's projects -- a billable engagement that time entries and expenses hang off -- with the filtering, search, ordering and page-size query parameters the contract declares. Returns one page; walk it with `page` and `page_size` via GET /v1.1/projects/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. Read one project by id -- a billable engagement that time entries and expenses hang off -- including the nested detail a listing omits via GET /v1.1/projects/{id}/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. List this organization's recurring invoices -- the schedule Elorus issues repeating invoices from -- with the filtering, search, ordering and page-size query parameters the contract declares. Returns one page; walk it with `page` and `page_size` Elorus also filters this listing by tracking category with a `tc_<trackingcategory_id>` query parameter, which is NOT offered here: its name embeds the id of one of your own tracking categories, so it is a family of parameter names rather than one parameter, and no fixed tool argument can express it. via GET /v1.1/recurringinvoices/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. Read one recurring invoice by id -- the schedule Elorus issues repeating invoices from -- including the nested detail a listing omits via GET /v1.1/recurringinvoices/{id}/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. List this organization's supplier credits -- credit received FROM a supplier, which can then be applied against bills -- with the filtering, search, ordering and page-size query parameters the contract declares. Returns one page; walk it with `page` and `page_size` Elorus also filters this listing by tracking category with a `tc_<trackingcategory_id>` query parameter, which is NOT offered here: its name embeds the id of one of your own tracking categories, so it is a family of parameter names rather than one parameter, and no fixed tool argument can express it. via GET /v1.1/suppliercredits/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. Read one supplier credit by id -- credit received FROM a supplier, which can then be applied against bills -- including the nested detail a listing omits via GET /v1.1/suppliercredits/{id}/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. Read the email Elorus WOULD send for one supplier credit -- credit received FROM a supplier, which can then be applied against bills -- its recipients, subject and body, resolved from the organization's email template. Nothing is sent: this is the dry run for the POST tool on the same path via GET /v1.1/suppliercredits/{id}/email/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. Render one supplier credit -- credit received FROM a supplier, which can then be applied against bills -- to PDF using the organization's document template. Elorus answers a redirect to the generated file, which this integration follows because the method is safe via GET /v1.1/suppliercredits/{id}/pdf/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. List the credit-note or supplier-credit amounts already applied against one supplier credit -- credit received FROM a supplier, which can then be applied against bills -- with each application's id and amount via GET /v1.1/suppliercredits/{parent_pk}/applied-credit/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. List this organization's taxes -- a tax rate available on document lines -- with the filtering, search, ordering and page-size query parameters the contract declares. Returns one page; walk it with `page` and `page_size` via GET /v1.1/taxes/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. Read one tax by id -- a tax rate available on document lines -- including the nested detail a listing omits via GET /v1.1/taxes/{id}/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. List this organization's document templates -- the print/PDF layout a document is rendered with -- with the filtering, search, ordering and page-size query parameters the contract declares. Returns one page; walk it with `page` and `page_size` via GET /v1.1/templates/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. Read one document template by id -- the print/PDF layout a document is rendered with -- including the nested detail a listing omits via GET /v1.1/templates/{id}/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. List this organization's tracking categories -- a reporting dimension documents can be tagged with -- with the filtering, search, ordering and page-size query parameters the contract declares. Returns one page; walk it with `page` and `page_size` via GET /v1.1/trackingcategories/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. Read one tracking category by id -- a reporting dimension documents can be tagged with -- including the nested detail a listing omits via GET /v1.1/trackingcategories/{id}/

List this organization's bills -- a purchase invoice a supplier issued to this organization -- with the filtering, search, ordering and page-size query parameters the contract declares. Returns one page; walk it with `page` and `page_size` Elorus also filters this listing by tracking category with a `tc_<trackingcategory_id>` query parameter, which is NOT offered here: its name embeds the id of one of your own tracking categories, so it is a family of parameter names rather than one parameter, and no fixed tool argument can express it. via GET /v1.2/bills/

Read one bill by id -- a purchase invoice a supplier issued to this organization -- including the nested detail a listing omits via GET /v1.2/bills/{id}/

Read the email Elorus WOULD send for one bill -- a purchase invoice a supplier issued to this organization -- its recipients, subject and body, resolved from the organization's email template. Nothing is sent: this is the dry run for the POST tool on the same path via GET /v1.2/bills/{id}/email/

Render one bill -- a purchase invoice a supplier issued to this organization -- to PDF using the organization's document template. Elorus answers a redirect to the generated file, which this integration follows because the method is safe via GET /v1.2/bills/{id}/pdf/

List the files attached to one bill -- a purchase invoice a supplier issued to this organization -- with each attachment's id, filename and metadata. UPLOADING an attachment is not offered by this integration: Elorus takes it as a multipart body, which the ledger marks `blocked_unsupported` for want of a bounded artifact transport via GET /v1.2/bills/{parent_pk}/attachments/

Read one attachment's record on a bill -- a purchase invoice a supplier issued to this organization -- its filename, size and metadata. The bytes come from the separate file tool via GET /v1.2/bills/{parent_pk}/attachments/{id}/

Fetch the stored FILE of one attachment on a bill -- a purchase invoice a supplier issued to this organization. Elorus answers 307 with a redirect to the file, which this integration follows because the method is safe; the reply is the file's own bytes rather than JSON via GET /v1.2/bills/{parent_pk}/attachments/{id}/file/

List the internal notes on one bill -- a purchase invoice a supplier issued to this organization. Notes are private to the organization: they are not printed on the document and not sent to the contact via GET /v1.2/bills/{parent_pk}/notes/

List the emails Elorus has already sent for one bill -- a purchase invoice a supplier issued to this organization -- with each message's recipients, timestamp and delivery state. Read-only history: this is where to look before emailing a document a second time via GET /v1.2/bills/{parent_pk}/sent-email-messages/

List this organization's cash payments -- money paid OUT, against a bill or a supplier -- with the filtering, search, ordering and page-size query parameters the contract declares. Returns one page; walk it with `page` and `page_size` Elorus also filters this listing by tracking category with a `tc_<trackingcategory_id>` query parameter, which is NOT offered here: its name embeds the id of one of your own tracking categories, so it is a family of parameter names rather than one parameter, and no fixed tool argument can express it. via GET /v1.2/cashpayments/

Read one cash payment by id -- money paid OUT, against a bill or a supplier -- including the nested detail a listing omits via GET /v1.2/cashpayments/{id}/

Render one cash payment -- money paid OUT, against a bill or a supplier -- to PDF using the organization's document template. Elorus answers a redirect to the generated file, which this integration follows because the method is safe via GET /v1.2/cashpayments/{id}/pdf/

List the files attached to one cash payment -- money paid OUT, against a bill or a supplier -- with each attachment's id, filename and metadata. UPLOADING an attachment is not offered by this integration: Elorus takes it as a multipart body, which the ledger marks `blocked_unsupported` for want of a bounded artifact transport via GET /v1.2/cashpayments/{parent_pk}/attachments/

Read one attachment's record on a cash payment -- money paid OUT, against a bill or a supplier -- its filename, size and metadata. The bytes come from the separate file tool via GET /v1.2/cashpayments/{parent_pk}/attachments/{id}/

Fetch the stored FILE of one attachment on a cash payment -- money paid OUT, against a bill or a supplier. Elorus answers 307 with a redirect to the file, which this integration follows because the method is safe; the reply is the file's own bytes rather than JSON via GET /v1.2/cashpayments/{parent_pk}/attachments/{id}/file/

List the internal notes on one cash payment -- money paid OUT, against a bill or a supplier. Notes are private to the organization: they are not printed on the document and not sent to the contact via GET /v1.2/cashpayments/{parent_pk}/notes/

List this organization's cash receipts -- money taken IN, against an invoice or a client -- with the filtering, search, ordering and page-size query parameters the contract declares. Returns one page; walk it with `page` and `page_size` Elorus also filters this listing by tracking category with a `tc_<trackingcategory_id>` query parameter, which is NOT offered here: its name embeds the id of one of your own tracking categories, so it is a family of parameter names rather than one parameter, and no fixed tool argument can express it. via GET /v1.2/cashreceipts/

Read one cash receipt by id -- money taken IN, against an invoice or a client -- including the nested detail a listing omits via GET /v1.2/cashreceipts/{id}/

Render one cash receipt -- money taken IN, against an invoice or a client -- to PDF using the organization's document template. Elorus answers a redirect to the generated file, which this integration follows because the method is safe via GET /v1.2/cashreceipts/{id}/pdf/

List the files attached to one cash receipt -- money taken IN, against an invoice or a client -- with each attachment's id, filename and metadata. UPLOADING an attachment is not offered by this integration: Elorus takes it as a multipart body, which the ledger marks `blocked_unsupported` for want of a bounded artifact transport via GET /v1.2/cashreceipts/{parent_pk}/attachments/

Read one attachment's record on a cash receipt -- money taken IN, against an invoice or a client -- its filename, size and metadata. The bytes come from the separate file tool via GET /v1.2/cashreceipts/{parent_pk}/attachments/{id}/

Fetch the stored FILE of one attachment on a cash receipt -- money taken IN, against an invoice or a client. Elorus answers 307 with a redirect to the file, which this integration follows because the method is safe; the reply is the file's own bytes rather than JSON via GET /v1.2/cashreceipts/{parent_pk}/attachments/{id}/file/

List the internal notes on one cash receipt -- money taken IN, against an invoice or a client. Notes are private to the organization: they are not printed on the document and not sent to the contact via GET /v1.2/cashreceipts/{parent_pk}/notes/

List this organization's contacts -- a client or supplier, with its billing and shipping addresses -- with the filtering, search, ordering and page-size query parameters the contract declares. Returns one page; walk it with `page` and `page_size` Elorus also filters this listing by tracking category with a `tc_<trackingcategory_id>` query parameter, which is NOT offered here: its name embeds the id of one of your own tracking categories, so it is a family of parameter names rather than one parameter, and no fixed tool argument can express it. via GET /v1.2/contacts/

Read one contact by id -- a client or supplier, with its billing and shipping addresses -- including the nested detail a listing omits via GET /v1.2/contacts/{id}/

List the files attached to one contact -- a client or supplier, with its billing and shipping addresses -- with each attachment's id, filename and metadata. UPLOADING an attachment is not offered by this integration: Elorus takes it as a multipart body, which the ledger marks `blocked_unsupported` for want of a bounded artifact transport via GET /v1.2/contacts/{parent_pk}/attachments/

Read one attachment's record on a contact -- a client or supplier, with its billing and shipping addresses -- its filename, size and metadata. The bytes come from the separate file tool via GET /v1.2/contacts/{parent_pk}/attachments/{id}/

Fetch the stored FILE of one attachment on a contact -- a client or supplier, with its billing and shipping addresses. Elorus answers 307 with a redirect to the file, which this integration follows because the method is safe; the reply is the file's own bytes rather than JSON via GET /v1.2/contacts/{parent_pk}/attachments/{id}/file/

List the internal notes on one contact -- a client or supplier, with its billing and shipping addresses. Notes are private to the organization: they are not printed on the document and not sent to the contact via GET /v1.2/contacts/{parent_pk}/notes/

List this organization's credit notes -- credit issued TO a client, which can then be applied against invoices -- with the filtering, search, ordering and page-size query parameters the contract declares. Returns one page; walk it with `page` and `page_size` Elorus also filters this listing by tracking category with a `tc_<trackingcategory_id>` query parameter, which is NOT offered here: its name embeds the id of one of your own tracking categories, so it is a family of parameter names rather than one parameter, and no fixed tool argument can express it. via GET /v1.2/creditnotes/

Read one credit note by id -- credit issued TO a client, which can then be applied against invoices -- including the nested detail a listing omits via GET /v1.2/creditnotes/{id}/

Read the email Elorus WOULD send for one credit note -- credit issued TO a client, which can then be applied against invoices -- its recipients, subject and body, resolved from the organization's email template. Nothing is sent: this is the dry run for the POST tool on the same path via GET /v1.2/creditnotes/{id}/email/

Render one credit note -- credit issued TO a client, which can then be applied against invoices -- to PDF using the organization's document template. Elorus answers a redirect to the generated file, which this integration follows because the method is safe via GET /v1.2/creditnotes/{id}/pdf/

List the credit-note or supplier-credit amounts already applied against one credit note -- credit issued TO a client, which can then be applied against invoices -- with each application's id and amount via GET /v1.2/creditnotes/{parent_pk}/applied-credit/

List the files attached to one credit note -- credit issued TO a client, which can then be applied against invoices -- with each attachment's id, filename and metadata. UPLOADING an attachment is not offered by this integration: Elorus takes it as a multipart body, which the ledger marks `blocked_unsupported` for want of a bounded artifact transport via GET /v1.2/creditnotes/{parent_pk}/attachments/

Read one attachment's record on a credit note -- credit issued TO a client, which can then be applied against invoices -- its filename, size and metadata. The bytes come from the separate file tool via GET /v1.2/creditnotes/{parent_pk}/attachments/{id}/

Fetch the stored FILE of one attachment on a credit note -- credit issued TO a client, which can then be applied against invoices. Elorus answers 307 with a redirect to the file, which this integration follows because the method is safe; the reply is the file's own bytes rather than JSON via GET /v1.2/creditnotes/{parent_pk}/attachments/{id}/file/

List the client-facing discussion thread on one credit note -- credit issued TO a client, which can then be applied against invoices. Unlike a note, a discussion message IS visible to the contact on the document's public page via GET /v1.2/creditnotes/{parent_pk}/discussions/

List the internal notes on one credit note -- credit issued TO a client, which can then be applied against invoices. Notes are private to the organization: they are not printed on the document and not sent to the contact via GET /v1.2/creditnotes/{parent_pk}/notes/

List the emails Elorus has already sent for one credit note -- credit issued TO a client, which can then be applied against invoices -- with each message's recipients, timestamp and delivery state. Read-only history: this is where to look before emailing a document a second time via GET /v1.2/creditnotes/{parent_pk}/sent-email-messages/

List this organization's delivery notes -- a despatch document for goods sent to a client -- with the filtering, search, ordering and page-size query parameters the contract declares. Returns one page; walk it with `page` and `page_size` via GET /v1.2/deliverynotes/

Read one delivery note by id -- a despatch document for goods sent to a client -- including the nested detail a listing omits via GET /v1.2/deliverynotes/{id}/

Read the email Elorus WOULD send for one delivery note -- a despatch document for goods sent to a client -- its recipients, subject and body, resolved from the organization's email template. Nothing is sent: this is the dry run for the POST tool on the same path via GET /v1.2/deliverynotes/{id}/email/

Render one delivery note -- a despatch document for goods sent to a client -- to PDF using the organization's document template. Elorus answers a redirect to the generated file, which this integration follows because the method is safe via GET /v1.2/deliverynotes/{id}/pdf/

List the files attached to one delivery note -- a despatch document for goods sent to a client -- with each attachment's id, filename and metadata. UPLOADING an attachment is not offered by this integration: Elorus takes it as a multipart body, which the ledger marks `blocked_unsupported` for want of a bounded artifact transport via GET /v1.2/deliverynotes/{parent_pk}/attachments/

Read one attachment's record on a delivery note -- a despatch document for goods sent to a client -- its filename, size and metadata. The bytes come from the separate file tool via GET /v1.2/deliverynotes/{parent_pk}/attachments/{id}/

Fetch the stored FILE of one attachment on a delivery note -- a despatch document for goods sent to a client. Elorus answers 307 with a redirect to the file, which this integration follows because the method is safe; the reply is the file's own bytes rather than JSON via GET /v1.2/deliverynotes/{parent_pk}/attachments/{id}/file/

List the internal notes on one delivery note -- a despatch document for goods sent to a client. Notes are private to the organization: they are not printed on the document and not sent to the contact via GET /v1.2/deliverynotes/{parent_pk}/notes/

List the emails Elorus has already sent for one delivery note -- a despatch document for goods sent to a client -- with each message's recipients, timestamp and delivery state. Read-only history: this is where to look before emailing a document a second time via GET /v1.2/deliverynotes/{parent_pk}/sent-email-messages/

List this organization's document types -- one of the organization's document kinds, which owns its own numbering sequences -- with the filtering, search, ordering and page-size query parameters the contract declares. Returns one page; walk it with `page` and `page_size` via GET /v1.2/documenttypes/

Read one document type by id -- one of the organization's document kinds, which owns its own numbering sequences -- including the nested detail a listing omits via GET /v1.2/documenttypes/{id}/

List the numbering sequences belonging to one document type -- one of the organization's document kinds, which owns its own numbering sequences -- each with its name and current counter via GET /v1.2/documenttypes/{parent_pk}/sequences/

List this organization's email templates -- the subject and body Elorus uses when it emails a document -- with the filtering, search, ordering and page-size query parameters the contract declares. Returns one page; walk it with `page` and `page_size` via GET /v1.2/emailtemplates/

Read one email template by id -- the subject and body Elorus uses when it emails a document -- including the nested detail a listing omits via GET /v1.2/emailtemplates/{id}/

List this organization's estimates -- a quotation sent to a client before any invoice exists -- with the filtering, search, ordering and page-size query parameters the contract declares. Returns one page; walk it with `page` and `page_size` via GET /v1.2/estimates/

Read one estimate by id -- a quotation sent to a client before any invoice exists -- including the nested detail a listing omits via GET /v1.2/estimates/{id}/

Read the email Elorus WOULD send for one estimate -- a quotation sent to a client before any invoice exists -- its recipients, subject and body, resolved from the organization's email template. Nothing is sent: this is the dry run for the POST tool on the same path via GET /v1.2/estimates/{id}/email/

Render one estimate -- a quotation sent to a client before any invoice exists -- to PDF using the organization's document template. Elorus answers a redirect to the generated file, which this integration follows because the method is safe via GET /v1.2/estimates/{id}/pdf/

List the files attached to one estimate -- a quotation sent to a client before any invoice exists -- with each attachment's id, filename and metadata. UPLOADING an attachment is not offered by this integration: Elorus takes it as a multipart body, which the ledger marks `blocked_unsupported` for want of a bounded artifact transport via GET /v1.2/estimates/{parent_pk}/attachments/

Read one attachment's record on an estimate -- a quotation sent to a client before any invoice exists -- its filename, size and metadata. The bytes come from the separate file tool via GET /v1.2/estimates/{parent_pk}/attachments/{id}/

Fetch the stored FILE of one attachment on an estimate -- a quotation sent to a client before any invoice exists. Elorus answers 307 with a redirect to the file, which this integration follows because the method is safe; the reply is the file's own bytes rather than JSON via GET /v1.2/estimates/{parent_pk}/attachments/{id}/file/

List the client-facing discussion thread on one estimate -- a quotation sent to a client before any invoice exists. Unlike a note, a discussion message IS visible to the contact on the document's public page via GET /v1.2/estimates/{parent_pk}/discussions/

List the internal notes on one estimate -- a quotation sent to a client before any invoice exists. Notes are private to the organization: they are not printed on the document and not sent to the contact via GET /v1.2/estimates/{parent_pk}/notes/

List the emails Elorus has already sent for one estimate -- a quotation sent to a client before any invoice exists -- with each message's recipients, timestamp and delivery state. Read-only history: this is where to look before emailing a document a second time via GET /v1.2/estimates/{parent_pk}/sent-email-messages/

List this organization's expense categories -- the bucket an expense is booked to -- with the filtering, search, ordering and page-size query parameters the contract declares. Returns one page; walk it with `page` and `page_size` via GET /v1.2/expensecategories/

Read one expense category by id -- the bucket an expense is booked to -- including the nested detail a listing omits via GET /v1.2/expensecategories/{id}/

List this organization's expenses -- a cost recorded against the organization, optionally billable to a project -- with the filtering, search, ordering and page-size query parameters the contract declares. Returns one page; walk it with `page` and `page_size` Elorus also filters this listing by tracking category with a `tc_<trackingcategory_id>` query parameter, which is NOT offered here: its name embeds the id of one of your own tracking categories, so it is a family of parameter names rather than one parameter, and no fixed tool argument can express it. via GET /v1.2/expenses/

Read one expense by id -- a cost recorded against the organization, optionally billable to a project -- including the nested detail a listing omits via GET /v1.2/expenses/{id}/

List the files attached to one expense -- a cost recorded against the organization, optionally billable to a project -- with each attachment's id, filename and metadata. UPLOADING an attachment is not offered by this integration: Elorus takes it as a multipart body, which the ledger marks `blocked_unsupported` for want of a bounded artifact transport via GET /v1.2/expenses/{parent_pk}/attachments/

Read one attachment's record on an expense -- a cost recorded against the organization, optionally billable to a project -- its filename, size and metadata. The bytes come from the separate file tool via GET /v1.2/expenses/{parent_pk}/attachments/{id}/

Fetch the stored FILE of one attachment on an expense -- a cost recorded against the organization, optionally billable to a project. Elorus answers 307 with a redirect to the file, which this integration follows because the method is safe; the reply is the file's own bytes rather than JSON via GET /v1.2/expenses/{parent_pk}/attachments/{id}/file/

List the internal notes on one expense -- a cost recorded against the organization, optionally billable to a project. Notes are private to the organization: they are not printed on the document and not sent to the contact via GET /v1.2/expenses/{parent_pk}/notes/

List this organization's goods receipts -- a record of stock received into a warehouse -- with the filtering, search, ordering and page-size query parameters the contract declares. Returns one page; walk it with `page` and `page_size` via GET /v1.2/goodsreceipts/

Read one goods receipt by id -- a record of stock received into a warehouse -- including the nested detail a listing omits via GET /v1.2/goodsreceipts/{id}/

Read the email Elorus WOULD send for one goods receipt -- a record of stock received into a warehouse -- its recipients, subject and body, resolved from the organization's email template. Nothing is sent: this is the dry run for the POST tool on the same path via GET /v1.2/goodsreceipts/{id}/email/

Render one goods receipt -- a record of stock received into a warehouse -- to PDF using the organization's document template. Elorus answers a redirect to the generated file, which this integration follows because the method is safe via GET /v1.2/goodsreceipts/{id}/pdf/

List the internal notes on one goods receipt -- a record of stock received into a warehouse. Notes are private to the organization: they are not printed on the document and not sent to the contact via GET /v1.2/goodsreceipts/{parent_pk}/notes/

List the emails Elorus has already sent for one goods receipt -- a record of stock received into a warehouse -- with each message's recipients, timestamp and delivery state. Read-only history: this is where to look before emailing a document a second time via GET /v1.2/goodsreceipts/{parent_pk}/sent-email-messages/

List this organization's goods-receipt numbering sequences -- the counter Elorus draws goods-receipt numbers from -- with the filtering, search, ordering and page-size query parameters the contract declares. Returns one page; walk it with `page` and `page_size` via GET /v1.2/goodsreceiptsequences/

List this organization's invoices -- a sales invoice issued to a client -- with the filtering, search, ordering and page-size query parameters the contract declares. Returns one page; walk it with `page` and `page_size` Elorus also filters this listing by tracking category with a `tc_<trackingcategory_id>` query parameter, which is NOT offered here: its name embeds the id of one of your own tracking categories, so it is a family of parameter names rather than one parameter, and no fixed tool argument can express it. via GET /v1.2/invoices/

Read one invoice by id -- a sales invoice issued to a client -- including the nested detail a listing omits via GET /v1.2/invoices/{id}/

Read the email Elorus WOULD send for one invoice -- a sales invoice issued to a client -- its recipients, subject and body, resolved from the organization's email template. Nothing is sent: this is the dry run for the POST tool on the same path via GET /v1.2/invoices/{id}/email/

Render one invoice -- a sales invoice issued to a client -- to PDF using the organization's document template. Elorus answers a redirect to the generated file, which this integration follows because the method is safe via GET /v1.2/invoices/{id}/pdf/

List the credit-note or supplier-credit amounts already applied against one invoice -- a sales invoice issued to a client -- with each application's id and amount via GET /v1.2/invoices/{parent_pk}/applied-credit/

List the files attached to one invoice -- a sales invoice issued to a client -- with each attachment's id, filename and metadata. UPLOADING an attachment is not offered by this integration: Elorus takes it as a multipart body, which the ledger marks `blocked_unsupported` for want of a bounded artifact transport via GET /v1.2/invoices/{parent_pk}/attachments/

Read one attachment's record on an invoice -- a sales invoice issued to a client -- its filename, size and metadata. The bytes come from the separate file tool via GET /v1.2/invoices/{parent_pk}/attachments/{id}/

Fetch the stored FILE of one attachment on an invoice -- a sales invoice issued to a client. Elorus answers 307 with a redirect to the file, which this integration follows because the method is safe; the reply is the file's own bytes rather than JSON via GET /v1.2/invoices/{parent_pk}/attachments/{id}/file/

List the client-facing discussion thread on one invoice -- a sales invoice issued to a client. Unlike a note, a discussion message IS visible to the contact on the document's public page via GET /v1.2/invoices/{parent_pk}/discussions/

List the internal notes on one invoice -- a sales invoice issued to a client. Notes are private to the organization: they are not printed on the document and not sent to the contact via GET /v1.2/invoices/{parent_pk}/notes/

List the emails Elorus has already sent for one invoice -- a sales invoice issued to a client -- with each message's recipients, timestamp and delivery state. Read-only history: this is where to look before emailing a document a second time via GET /v1.2/invoices/{parent_pk}/sent-email-messages/

List this organization's organization branches -- a branch or establishment of the organization -- with the filtering, search, ordering and page-size query parameters the contract declares. Returns one page; walk it with `page` and `page_size` via GET /v1.2/organizationbranch/

Read one organization branch by id -- a branch or establishment of the organization -- including the nested detail a listing omits via GET /v1.2/organizationbranch/{id}/

List this organization's payment gateways -- an online payment method configured for this organization -- with the filtering, search, ordering and page-size query parameters the contract declares. Returns one page; walk it with `page` and `page_size` via GET /v1.2/paymentgateways/

List this organization's products -- a product or service line item, with its price and stock -- with the filtering, search, ordering and page-size query parameters the contract declares. Returns one page; walk it with `page` and `page_size` Elorus also filters this listing by tracking category with a `tc_<trackingcategory_id>` query parameter, which is NOT offered here: its name embeds the id of one of your own tracking categories, so it is a family of parameter names rather than one parameter, and no fixed tool argument can express it. via GET /v1.2/products/

Read one product by id -- a product or service line item, with its price and stock -- including the nested detail a listing omits via GET /v1.2/products/{id}/

List the internal notes on one product -- a product or service line item, with its price and stock. Notes are private to the organization: they are not printed on the document and not sent to the contact via GET /v1.2/products/{parent_pk}/notes/

List the stock adjustments recorded against one product -- a product or service line item, with its price and stock -- each with its warehouse, quantity delta and reason via GET /v1.2/products/{parent_pk}/stockadjustments/

Read one stock adjustment recorded against a product -- a product or service line item, with its price and stock -- its warehouse, quantity delta and reason via GET /v1.2/products/{parent_pk}/stockadjustments/{id}/

List this organization's projects -- a billable engagement that time entries and expenses hang off -- with the filtering, search, ordering and page-size query parameters the contract declares. Returns one page; walk it with `page` and `page_size` Elorus also filters this listing by tracking category with a `tc_<trackingcategory_id>` query parameter, which is NOT offered here: its name embeds the id of one of your own tracking categories, so it is a family of parameter names rather than one parameter, and no fixed tool argument can express it. via GET /v1.2/projects/

Read one project by id -- a billable engagement that time entries and expenses hang off -- including the nested detail a listing omits via GET /v1.2/projects/{id}/

List the files attached to one project -- a billable engagement that time entries and expenses hang off -- with each attachment's id, filename and metadata. UPLOADING an attachment is not offered by this integration: Elorus takes it as a multipart body, which the ledger marks `blocked_unsupported` for want of a bounded artifact transport via GET /v1.2/projects/{parent_pk}/attachments/

Read one attachment's record on a project -- a billable engagement that time entries and expenses hang off -- its filename, size and metadata. The bytes come from the separate file tool via GET /v1.2/projects/{parent_pk}/attachments/{id}/

Fetch the stored FILE of one attachment on a project -- a billable engagement that time entries and expenses hang off. Elorus answers 307 with a redirect to the file, which this integration follows because the method is safe; the reply is the file's own bytes rather than JSON via GET /v1.2/projects/{parent_pk}/attachments/{id}/file/

List the client-facing discussion thread on one project -- a billable engagement that time entries and expenses hang off. Unlike a note, a discussion message IS visible to the contact on the document's public page via GET /v1.2/projects/{parent_pk}/discussions/

List the internal notes on one project -- a billable engagement that time entries and expenses hang off. Notes are private to the organization: they are not printed on the document and not sent to the contact via GET /v1.2/projects/{parent_pk}/notes/

List the extra fees attached to one project -- a billable engagement that time entries and expenses hang off -- the fixed amounts that are invoiced alongside its tracked time via GET /v1.2/projects/{parent_pk}/projectextrafees/

Read one extra fee attached to a project -- a billable engagement that time entries and expenses hang off -- its description and amount via GET /v1.2/projects/{parent_pk}/projectextrafees/{id}/

List this organization's recurring invoices -- the schedule Elorus issues repeating invoices from -- with the filtering, search, ordering and page-size query parameters the contract declares. Returns one page; walk it with `page` and `page_size` Elorus also filters this listing by tracking category with a `tc_<trackingcategory_id>` query parameter, which is NOT offered here: its name embeds the id of one of your own tracking categories, so it is a family of parameter names rather than one parameter, and no fixed tool argument can express it. via GET /v1.2/recurringinvoices/

Read one recurring invoice by id -- the schedule Elorus issues repeating invoices from -- including the nested detail a listing omits via GET /v1.2/recurringinvoices/{id}/

List the internal notes on one recurring invoice -- the schedule Elorus issues repeating invoices from. Notes are private to the organization: they are not printed on the document and not sent to the contact via GET /v1.2/recurringinvoices/{parent_pk}/notes/

List this organization's supplier credits -- credit received FROM a supplier, which can then be applied against bills -- with the filtering, search, ordering and page-size query parameters the contract declares. Returns one page; walk it with `page` and `page_size` Elorus also filters this listing by tracking category with a `tc_<trackingcategory_id>` query parameter, which is NOT offered here: its name embeds the id of one of your own tracking categories, so it is a family of parameter names rather than one parameter, and no fixed tool argument can express it. via GET /v1.2/suppliercredits/

Read one supplier credit by id -- credit received FROM a supplier, which can then be applied against bills -- including the nested detail a listing omits via GET /v1.2/suppliercredits/{id}/

Read the email Elorus WOULD send for one supplier credit -- credit received FROM a supplier, which can then be applied against bills -- its recipients, subject and body, resolved from the organization's email template. Nothing is sent: this is the dry run for the POST tool on the same path via GET /v1.2/suppliercredits/{id}/email/

Render one supplier credit -- credit received FROM a supplier, which can then be applied against bills -- to PDF using the organization's document template. Elorus answers a redirect to the generated file, which this integration follows because the method is safe via GET /v1.2/suppliercredits/{id}/pdf/

List the credit-note or supplier-credit amounts already applied against one supplier credit -- credit received FROM a supplier, which can then be applied against bills -- with each application's id and amount via GET /v1.2/suppliercredits/{parent_pk}/applied-credit/

List the files attached to one supplier credit -- credit received FROM a supplier, which can then be applied against bills -- with each attachment's id, filename and metadata. UPLOADING an attachment is not offered by this integration: Elorus takes it as a multipart body, which the ledger marks `blocked_unsupported` for want of a bounded artifact transport via GET /v1.2/suppliercredits/{parent_pk}/attachments/

Read one attachment's record on a supplier credit -- credit received FROM a supplier, which can then be applied against bills -- its filename, size and metadata. The bytes come from the separate file tool via GET /v1.2/suppliercredits/{parent_pk}/attachments/{id}/

Fetch the stored FILE of one attachment on a supplier credit -- credit received FROM a supplier, which can then be applied against bills. Elorus answers 307 with a redirect to the file, which this integration follows because the method is safe; the reply is the file's own bytes rather than JSON via GET /v1.2/suppliercredits/{parent_pk}/attachments/{id}/file/

List the internal notes on one supplier credit -- credit received FROM a supplier, which can then be applied against bills. Notes are private to the organization: they are not printed on the document and not sent to the contact via GET /v1.2/suppliercredits/{parent_pk}/notes/

List the emails Elorus has already sent for one supplier credit -- credit received FROM a supplier, which can then be applied against bills -- with each message's recipients, timestamp and delivery state. Read-only history: this is where to look before emailing a document a second time via GET /v1.2/suppliercredits/{parent_pk}/sent-email-messages/

List this organization's tasks -- a billable activity type time entries are recorded against -- with the filtering, search, ordering and page-size query parameters the contract declares. Returns one page; walk it with `page` and `page_size` via GET /v1.2/tasks/

Read one task by id -- a billable activity type time entries are recorded against -- including the nested detail a listing omits via GET /v1.2/tasks/{id}/

List this organization's taxes -- a tax rate available on document lines -- with the filtering, search, ordering and page-size query parameters the contract declares. Returns one page; walk it with `page` and `page_size` via GET /v1.2/taxes/

Read one tax by id -- a tax rate available on document lines -- including the nested detail a listing omits via GET /v1.2/taxes/{id}/

List this organization's document templates -- the print/PDF layout a document is rendered with -- with the filtering, search, ordering and page-size query parameters the contract declares. Returns one page; walk it with `page` and `page_size` via GET /v1.2/templates/

Read one document template by id -- the print/PDF layout a document is rendered with -- including the nested detail a listing omits via GET /v1.2/templates/{id}/

List this organization's time entries -- tracked time on a project, billable or not -- with the filtering, search, ordering and page-size query parameters the contract declares. Returns one page; walk it with `page` and `page_size` via GET /v1.2/timeentries/

Read one time entry by id -- tracked time on a project, billable or not -- including the nested detail a listing omits via GET /v1.2/timeentries/{id}/

List this organization's tracking categories -- a reporting dimension documents can be tagged with -- with the filtering, search, ordering and page-size query parameters the contract declares. Returns one page; walk it with `page` and `page_size` via GET /v1.2/trackingcategories/

Read one tracking category by id -- a reporting dimension documents can be tagged with -- including the nested detail a listing omits via GET /v1.2/trackingcategories/{id}/

List this organization's units of measurement -- the unit a product quantity is expressed in -- with the filtering, search, ordering and page-size query parameters the contract declares. Returns one page; walk it with `page` and `page_size` via GET /v1.2/unitofmeasurement/

Read one unit of measurement by id -- the unit a product quantity is expressed in -- including the nested detail a listing omits via GET /v1.2/unitofmeasurement/{id}/

List this organization's users -- a member of this Elorus organization -- with the filtering, search, ordering and page-size query parameters the contract declares. Returns one page; walk it with `page` and `page_size` via GET /v1.2/users/

List this organization's user teams -- a group of this organization's users -- with the filtering, search, ordering and page-size query parameters the contract declares. Returns one page; walk it with `page` and `page_size` via GET /v1.2/userteams/

List this organization's warehouses -- a stock location goods receipts and adjustments move stock through -- with the filtering, search, ordering and page-size query parameters the contract declares. Returns one page; walk it with `page` and `page_size` via GET /v1.2/warehouse/

Read one warehouse by id -- a stock location goods receipts and adjustments move stock through -- including the nested detail a listing omits via GET /v1.2/warehouse/{id}/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. Update one bill in place -- a purchase invoice a supplier issued to this organization -- sending only the fields to change. This is the safe partner of the PUT tool, which replaces the whole document via PATCH /v1.1/bills/{id}/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. Update one credit note in place -- credit issued TO a client, which can then be applied against invoices -- sending only the fields to change. This is the safe partner of the PUT tool, which replaces the whole document via PATCH /v1.1/creditnotes/{id}/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. Update one estimate in place -- a quotation sent to a client before any invoice exists -- sending only the fields to change. This is the safe partner of the PUT tool, which replaces the whole document via PATCH /v1.1/estimates/{id}/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. Update one invoice in place -- a sales invoice issued to a client -- sending only the fields to change. This is the safe partner of the PUT tool, which replaces the whole document via PATCH /v1.1/invoices/{id}/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. Update one supplier credit in place -- credit received FROM a supplier, which can then be applied against bills -- sending only the fields to change. This is the safe partner of the PUT tool, which replaces the whole document via PATCH /v1.1/suppliercredits/{id}/

Update one bill in place -- a purchase invoice a supplier issued to this organization -- sending only the fields to change. This is the safe partner of the PUT tool, which replaces the whole document via PATCH /v1.2/bills/{id}/

Change the metadata of one attachment on a bill -- a purchase invoice a supplier issued to this organization -- sending only the fields to change. The stored file itself is not replaced via PATCH /v1.2/bills/{parent_pk}/attachments/{id}/

Change the metadata of one attachment on a cash payment -- money paid OUT, against a bill or a supplier -- sending only the fields to change. The stored file itself is not replaced via PATCH /v1.2/cashpayments/{parent_pk}/attachments/{id}/

Change the metadata of one attachment on a cash receipt -- money taken IN, against an invoice or a client -- sending only the fields to change. The stored file itself is not replaced via PATCH /v1.2/cashreceipts/{parent_pk}/attachments/{id}/

Change the metadata of one attachment on a contact -- a client or supplier, with its billing and shipping addresses -- sending only the fields to change. The stored file itself is not replaced via PATCH /v1.2/contacts/{parent_pk}/attachments/{id}/

Update one credit note in place -- credit issued TO a client, which can then be applied against invoices -- sending only the fields to change. This is the safe partner of the PUT tool, which replaces the whole document via PATCH /v1.2/creditnotes/{id}/

Change the metadata of one attachment on a credit note -- credit issued TO a client, which can then be applied against invoices -- sending only the fields to change. The stored file itself is not replaced via PATCH /v1.2/creditnotes/{parent_pk}/attachments/{id}/

Update one delivery note in place -- a despatch document for goods sent to a client -- sending only the fields to change. This is the safe partner of the PUT tool, which replaces the whole document via PATCH /v1.2/deliverynotes/{id}/

Change the metadata of one attachment on a delivery note -- a despatch document for goods sent to a client -- sending only the fields to change. The stored file itself is not replaced via PATCH /v1.2/deliverynotes/{parent_pk}/attachments/{id}/

Update one estimate in place -- a quotation sent to a client before any invoice exists -- sending only the fields to change. This is the safe partner of the PUT tool, which replaces the whole document via PATCH /v1.2/estimates/{id}/

Change the metadata of one attachment on an estimate -- a quotation sent to a client before any invoice exists -- sending only the fields to change. The stored file itself is not replaced via PATCH /v1.2/estimates/{parent_pk}/attachments/{id}/

Change the metadata of one attachment on an expense -- a cost recorded against the organization, optionally billable to a project -- sending only the fields to change. The stored file itself is not replaced via PATCH /v1.2/expenses/{parent_pk}/attachments/{id}/

Update one goods receipt in place -- a record of stock received into a warehouse -- sending only the fields to change. This is the safe partner of the PUT tool, which replaces the whole document via PATCH /v1.2/goodsreceipts/{id}/

Update one invoice in place -- a sales invoice issued to a client -- sending only the fields to change. This is the safe partner of the PUT tool, which replaces the whole document via PATCH /v1.2/invoices/{id}/

Change the metadata of one attachment on an invoice -- a sales invoice issued to a client -- sending only the fields to change. The stored file itself is not replaced via PATCH /v1.2/invoices/{parent_pk}/attachments/{id}/

Update one organization branch in place -- a branch or establishment of the organization -- sending only the fields to change. This is the safe partner of the PUT tool, which replaces the whole document via PATCH /v1.2/organizationbranch/{id}/

Change the metadata of one attachment on a project -- a billable engagement that time entries and expenses hang off -- sending only the fields to change. The stored file itself is not replaced via PATCH /v1.2/projects/{parent_pk}/attachments/{id}/

Update one extra fee on a project -- a billable engagement that time entries and expenses hang off -- sending only the fields to change. The safe partner of the PUT tool on the same path via PATCH /v1.2/projects/{parent_pk}/projectextrafees/{id}/

Update one supplier credit in place -- credit received FROM a supplier, which can then be applied against bills -- sending only the fields to change. This is the safe partner of the PUT tool, which replaces the whole document via PATCH /v1.2/suppliercredits/{id}/

Change the metadata of one attachment on a supplier credit -- credit received FROM a supplier, which can then be applied against bills -- sending only the fields to change. The stored file itself is not replaced via PATCH /v1.2/suppliercredits/{parent_pk}/attachments/{id}/

Update one unit of measurement in place -- the unit a product quantity is expressed in -- sending only the fields to change. This is the safe partner of the PUT tool, which replaces the whole document via PATCH /v1.2/unitofmeasurement/{id}/

Update one warehouse in place -- a stock location goods receipts and adjustments move stock through -- sending only the fields to change. This is the safe partner of the PUT tool, which replaces the whole document via PATCH /v1.2/warehouse/{id}/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. Create a bill -- a purchase invoice a supplier issued to this organization -- from a JSON body. Elorus validates the whole document and answers 400 with a per-field error map when it refuses, so read the body of a 400 rather than retrying via POST /v1.1/bills/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. SENDS AN EMAIL TO A REAL RECIPIENT, which cannot be recalled: email one bill -- a purchase invoice a supplier issued to this organization -- to its contact. Preview it first with the GET tool on the same path to see exactly who would receive it. A demo organization cannot send email to customers, so this tool cannot be exercised end-to-end under the demo guard via POST /v1.1/bills/{id}/email/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. Create a cash payment -- money paid OUT, against a bill or a supplier -- from a JSON body. Elorus validates the whole document and answers 400 with a per-field error map when it refuses, so read the body of a 400 rather than retrying via POST /v1.1/cashpayments/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. Create a cash receipt -- money taken IN, against an invoice or a client -- from a JSON body. Elorus validates the whole document and answers 400 with a per-field error map when it refuses, so read the body of a 400 rather than retrying via POST /v1.1/cashreceipts/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. Create a contact -- a client or supplier, with its billing and shipping addresses -- from a JSON body. Elorus validates the whole document and answers 400 with a per-field error map when it refuses, so read the body of a 400 rather than retrying via POST /v1.1/contacts/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. Create a credit note -- credit issued TO a client, which can then be applied against invoices -- from a JSON body. Elorus validates the whole document and answers 400 with a per-field error map when it refuses, so read the body of a 400 rather than retrying via POST /v1.1/creditnotes/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. SENDS AN EMAIL TO A REAL RECIPIENT, which cannot be recalled: email one credit note -- credit issued TO a client, which can then be applied against invoices -- to its contact. Preview it first with the GET tool on the same path to see exactly who would receive it. A demo organization cannot send email to customers, so this tool cannot be exercised end-to-end under the demo guard via POST /v1.1/creditnotes/{id}/email/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. Apply credit against one credit note -- credit issued TO a client, which can then be applied against invoices -- which CHANGES WHAT IS OWED on both the document and the credit it draws from. Elorus refuses an amount larger than the remaining credit with a 400 via POST /v1.1/creditnotes/{parent_pk}/applied-credit/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. Create an email template -- the subject and body Elorus uses when it emails a document -- from a JSON body. Elorus validates the whole document and answers 400 with a per-field error map when it refuses, so read the body of a 400 rather than retrying via POST /v1.1/emailtemplates/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. Create an estimate -- a quotation sent to a client before any invoice exists -- from a JSON body. Elorus validates the whole document and answers 400 with a per-field error map when it refuses, so read the body of a 400 rather than retrying via POST /v1.1/estimates/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. SENDS AN EMAIL TO A REAL RECIPIENT, which cannot be recalled: email one estimate -- a quotation sent to a client before any invoice exists -- to its contact. Preview it first with the GET tool on the same path to see exactly who would receive it. A demo organization cannot send email to customers, so this tool cannot be exercised end-to-end under the demo guard via POST /v1.1/estimates/{id}/email/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. Create an expense -- a cost recorded against the organization, optionally billable to a project -- from a JSON body. Elorus validates the whole document and answers 400 with a per-field error map when it refuses, so read the body of a 400 rather than retrying via POST /v1.1/expenses/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. Create an invoice -- a sales invoice issued to a client -- from a JSON body. Elorus validates the whole document and answers 400 with a per-field error map when it refuses, so read the body of a 400 rather than retrying via POST /v1.1/invoices/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. SENDS AN EMAIL TO A REAL RECIPIENT, which cannot be recalled: email one invoice -- a sales invoice issued to a client -- to its contact. Preview it first with the GET tool on the same path to see exactly who would receive it. A demo organization cannot send email to customers, so this tool cannot be exercised end-to-end under the demo guard via POST /v1.1/invoices/{id}/email/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. Apply credit against one invoice -- a sales invoice issued to a client -- which CHANGES WHAT IS OWED on both the document and the credit it draws from. Elorus refuses an amount larger than the remaining credit with a 400 via POST /v1.1/invoices/{parent_pk}/applied-credit/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. Create a numbering sequence -- the counter Elorus draws document numbers from -- from a JSON body. Elorus validates the whole document and answers 400 with a per-field error map when it refuses, so read the body of a 400 rather than retrying via POST /v1.1/numberingsequence/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. Create a product -- a product or service line item, with its price and stock -- from a JSON body. Elorus validates the whole document and answers 400 with a per-field error map when it refuses, so read the body of a 400 rather than retrying via POST /v1.1/products/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. Create a recurring invoice -- the schedule Elorus issues repeating invoices from -- from a JSON body. Elorus validates the whole document and answers 400 with a per-field error map when it refuses, so read the body of a 400 rather than retrying via POST /v1.1/recurringinvoices/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. Create a supplier credit -- credit received FROM a supplier, which can then be applied against bills -- from a JSON body. Elorus validates the whole document and answers 400 with a per-field error map when it refuses, so read the body of a 400 rather than retrying via POST /v1.1/suppliercredits/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. SENDS AN EMAIL TO A REAL RECIPIENT, which cannot be recalled: email one supplier credit -- credit received FROM a supplier, which can then be applied against bills -- to its contact. Preview it first with the GET tool on the same path to see exactly who would receive it. A demo organization cannot send email to customers, so this tool cannot be exercised end-to-end under the demo guard via POST /v1.1/suppliercredits/{id}/email/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. Apply credit against one supplier credit -- credit received FROM a supplier, which can then be applied against bills -- which CHANGES WHAT IS OWED on both the document and the credit it draws from. Elorus refuses an amount larger than the remaining credit with a 400 via POST /v1.1/suppliercredits/{parent_pk}/applied-credit/

Create a bill -- a purchase invoice a supplier issued to this organization -- from a JSON body. Elorus validates the whole document and answers 400 with a per-field error map when it refuses, so read the body of a 400 rather than retrying via POST /v1.2/bills/

SENDS AN EMAIL TO A REAL RECIPIENT, which cannot be recalled: email one bill -- a purchase invoice a supplier issued to this organization -- to its contact. Preview it first with the GET tool on the same path to see exactly who would receive it. A demo organization cannot send email to customers, so this tool cannot be exercised end-to-end under the demo guard via POST /v1.2/bills/{id}/email/

Attach an internal note to one bill -- a purchase invoice a supplier issued to this organization. Private to the organization, so it never reaches the contact via POST /v1.2/bills/{parent_pk}/notes/

Create a cash payment -- money paid OUT, against a bill or a supplier -- from a JSON body. Elorus validates the whole document and answers 400 with a per-field error map when it refuses, so read the body of a 400 rather than retrying via POST /v1.2/cashpayments/

Attach an internal note to one cash payment -- money paid OUT, against a bill or a supplier. Private to the organization, so it never reaches the contact via POST /v1.2/cashpayments/{parent_pk}/notes/

Create a cash receipt -- money taken IN, against an invoice or a client -- from a JSON body. Elorus validates the whole document and answers 400 with a per-field error map when it refuses, so read the body of a 400 rather than retrying via POST /v1.2/cashreceipts/

Attach an internal note to one cash receipt -- money taken IN, against an invoice or a client. Private to the organization, so it never reaches the contact via POST /v1.2/cashreceipts/{parent_pk}/notes/

Create a contact -- a client or supplier, with its billing and shipping addresses -- from a JSON body. Elorus validates the whole document and answers 400 with a per-field error map when it refuses, so read the body of a 400 rather than retrying via POST /v1.2/contacts/

Attach an internal note to one contact -- a client or supplier, with its billing and shipping addresses. Private to the organization, so it never reaches the contact via POST /v1.2/contacts/{parent_pk}/notes/

Create a credit note -- credit issued TO a client, which can then be applied against invoices -- from a JSON body. Elorus validates the whole document and answers 400 with a per-field error map when it refuses, so read the body of a 400 rather than retrying via POST /v1.2/creditnotes/

SENDS AN EMAIL TO A REAL RECIPIENT, which cannot be recalled: email one credit note -- credit issued TO a client, which can then be applied against invoices -- to its contact. Preview it first with the GET tool on the same path to see exactly who would receive it. A demo organization cannot send email to customers, so this tool cannot be exercised end-to-end under the demo guard via POST /v1.2/creditnotes/{id}/email/

Apply credit against one credit note -- credit issued TO a client, which can then be applied against invoices -- which CHANGES WHAT IS OWED on both the document and the credit it draws from. Elorus refuses an amount larger than the remaining credit with a 400 via POST /v1.2/creditnotes/{parent_pk}/applied-credit/

Add a message to the client-facing discussion thread on one credit note -- credit issued TO a client, which can then be applied against invoices. VISIBLE TO THE CONTACT on the document's public page, which is the whole difference between this and adding a note via POST /v1.2/creditnotes/{parent_pk}/discussions/

Attach an internal note to one credit note -- credit issued TO a client, which can then be applied against invoices. Private to the organization, so it never reaches the contact via POST /v1.2/creditnotes/{parent_pk}/notes/

Create a delivery note -- a despatch document for goods sent to a client -- from a JSON body. Elorus validates the whole document and answers 400 with a per-field error map when it refuses, so read the body of a 400 rather than retrying via POST /v1.2/deliverynotes/

SENDS AN EMAIL TO A REAL RECIPIENT, which cannot be recalled: email one delivery note -- a despatch document for goods sent to a client -- to its contact. Preview it first with the GET tool on the same path to see exactly who would receive it. A demo organization cannot send email to customers, so this tool cannot be exercised end-to-end under the demo guard via POST /v1.2/deliverynotes/{id}/email/

Attach an internal note to one delivery note -- a despatch document for goods sent to a client. Private to the organization, so it never reaches the contact via POST /v1.2/deliverynotes/{parent_pk}/notes/

Add a numbering sequence to one document type -- one of the organization's document kinds, which owns its own numbering sequences. New documents of that type can then draw their numbers from it via POST /v1.2/documenttypes/{parent_pk}/sequences/

Create an email template -- the subject and body Elorus uses when it emails a document -- from a JSON body. Elorus validates the whole document and answers 400 with a per-field error map when it refuses, so read the body of a 400 rather than retrying via POST /v1.2/emailtemplates/

Create an estimate -- a quotation sent to a client before any invoice exists -- from a JSON body. Elorus validates the whole document and answers 400 with a per-field error map when it refuses, so read the body of a 400 rather than retrying via POST /v1.2/estimates/

SENDS AN EMAIL TO A REAL RECIPIENT, which cannot be recalled: email one estimate -- a quotation sent to a client before any invoice exists -- to its contact. Preview it first with the GET tool on the same path to see exactly who would receive it. A demo organization cannot send email to customers, so this tool cannot be exercised end-to-end under the demo guard via POST /v1.2/estimates/{id}/email/

Add a message to the client-facing discussion thread on one estimate -- a quotation sent to a client before any invoice exists. VISIBLE TO THE CONTACT on the document's public page, which is the whole difference between this and adding a note via POST /v1.2/estimates/{parent_pk}/discussions/

Attach an internal note to one estimate -- a quotation sent to a client before any invoice exists. Private to the organization, so it never reaches the contact via POST /v1.2/estimates/{parent_pk}/notes/

Create an expense -- a cost recorded against the organization, optionally billable to a project -- from a JSON body. Elorus validates the whole document and answers 400 with a per-field error map when it refuses, so read the body of a 400 rather than retrying via POST /v1.2/expenses/

Attach an internal note to one expense -- a cost recorded against the organization, optionally billable to a project. Private to the organization, so it never reaches the contact via POST /v1.2/expenses/{parent_pk}/notes/

Create a goods receipt -- a record of stock received into a warehouse -- from a JSON body. Elorus validates the whole document and answers 400 with a per-field error map when it refuses, so read the body of a 400 rather than retrying via POST /v1.2/goodsreceipts/

SENDS AN EMAIL TO A REAL RECIPIENT, which cannot be recalled: email one goods receipt -- a record of stock received into a warehouse -- to its contact. Preview it first with the GET tool on the same path to see exactly who would receive it. A demo organization cannot send email to customers, so this tool cannot be exercised end-to-end under the demo guard via POST /v1.2/goodsreceipts/{id}/email/

Attach an internal note to one goods receipt -- a record of stock received into a warehouse. Private to the organization, so it never reaches the contact via POST /v1.2/goodsreceipts/{parent_pk}/notes/

Create a goods-receipt numbering sequence -- the counter Elorus draws goods-receipt numbers from -- from a JSON body. Elorus validates the whole document and answers 400 with a per-field error map when it refuses, so read the body of a 400 rather than retrying via POST /v1.2/goodsreceiptsequences/

Create an invoice -- a sales invoice issued to a client -- from a JSON body. Elorus validates the whole document and answers 400 with a per-field error map when it refuses, so read the body of a 400 rather than retrying via POST /v1.2/invoices/

SENDS AN EMAIL TO A REAL RECIPIENT, which cannot be recalled: email one invoice -- a sales invoice issued to a client -- to its contact. Preview it first with the GET tool on the same path to see exactly who would receive it. A demo organization cannot send email to customers, so this tool cannot be exercised end-to-end under the demo guard via POST /v1.2/invoices/{id}/email/

Apply credit against one invoice -- a sales invoice issued to a client -- which CHANGES WHAT IS OWED on both the document and the credit it draws from. Elorus refuses an amount larger than the remaining credit with a 400 via POST /v1.2/invoices/{parent_pk}/applied-credit/

Add a message to the client-facing discussion thread on one invoice -- a sales invoice issued to a client. VISIBLE TO THE CONTACT on the document's public page, which is the whole difference between this and adding a note via POST /v1.2/invoices/{parent_pk}/discussions/

Attach an internal note to one invoice -- a sales invoice issued to a client. Private to the organization, so it never reaches the contact via POST /v1.2/invoices/{parent_pk}/notes/

Create an organization branch -- a branch or establishment of the organization -- from a JSON body. Elorus validates the whole document and answers 400 with a per-field error map when it refuses, so read the body of a 400 rather than retrying via POST /v1.2/organizationbranch/

Create a product -- a product or service line item, with its price and stock -- from a JSON body. Elorus validates the whole document and answers 400 with a per-field error map when it refuses, so read the body of a 400 rather than retrying via POST /v1.2/products/

Attach an internal note to one product -- a product or service line item, with its price and stock. Private to the organization, so it never reaches the contact via POST /v1.2/products/{parent_pk}/notes/

Record a stock adjustment against one product -- a product or service line item, with its price and stock. This MOVES THE STOCK LEVEL in the named warehouse rather than describing it via POST /v1.2/products/{parent_pk}/stockadjustments/

Create a project -- a billable engagement that time entries and expenses hang off -- from a JSON body. Elorus validates the whole document and answers 400 with a per-field error map when it refuses, so read the body of a 400 rather than retrying via POST /v1.2/projects/

Add a message to the client-facing discussion thread on one project -- a billable engagement that time entries and expenses hang off. VISIBLE TO THE CONTACT on the document's public page, which is the whole difference between this and adding a note via POST /v1.2/projects/{parent_pk}/discussions/

Attach an internal note to one project -- a billable engagement that time entries and expenses hang off. Private to the organization, so it never reaches the contact via POST /v1.2/projects/{parent_pk}/notes/

Attach an extra fee to one project -- a billable engagement that time entries and expenses hang off. It is invoiced alongside the project's tracked time, so this CHANGES WHAT THE CLIENT WILL BE BILLED via POST /v1.2/projects/{parent_pk}/projectextrafees/

Create a recurring invoice -- the schedule Elorus issues repeating invoices from -- from a JSON body. Elorus validates the whole document and answers 400 with a per-field error map when it refuses, so read the body of a 400 rather than retrying via POST /v1.2/recurringinvoices/

Attach an internal note to one recurring invoice -- the schedule Elorus issues repeating invoices from. Private to the organization, so it never reaches the contact via POST /v1.2/recurringinvoices/{parent_pk}/notes/

Create a supplier credit -- credit received FROM a supplier, which can then be applied against bills -- from a JSON body. Elorus validates the whole document and answers 400 with a per-field error map when it refuses, so read the body of a 400 rather than retrying via POST /v1.2/suppliercredits/

SENDS AN EMAIL TO A REAL RECIPIENT, which cannot be recalled: email one supplier credit -- credit received FROM a supplier, which can then be applied against bills -- to its contact. Preview it first with the GET tool on the same path to see exactly who would receive it. A demo organization cannot send email to customers, so this tool cannot be exercised end-to-end under the demo guard via POST /v1.2/suppliercredits/{id}/email/

Apply credit against one supplier credit -- credit received FROM a supplier, which can then be applied against bills -- which CHANGES WHAT IS OWED on both the document and the credit it draws from. Elorus refuses an amount larger than the remaining credit with a 400 via POST /v1.2/suppliercredits/{parent_pk}/applied-credit/

Attach an internal note to one supplier credit -- credit received FROM a supplier, which can then be applied against bills. Private to the organization, so it never reaches the contact via POST /v1.2/suppliercredits/{parent_pk}/notes/

Create a task -- a billable activity type time entries are recorded against -- from a JSON body. Elorus validates the whole document and answers 400 with a per-field error map when it refuses, so read the body of a 400 rather than retrying via POST /v1.2/tasks/

Create a time entry -- tracked time on a project, billable or not -- from a JSON body. Elorus validates the whole document and answers 400 with a per-field error map when it refuses, so read the body of a 400 rather than retrying via POST /v1.2/timeentries/

Create a unit of measurement -- the unit a product quantity is expressed in -- from a JSON body. Elorus validates the whole document and answers 400 with a per-field error map when it refuses, so read the body of a 400 rather than retrying via POST /v1.2/unitofmeasurement/

Create a warehouse -- a stock location goods receipts and adjustments move stock through -- from a JSON body. Elorus validates the whole document and answers 400 with a per-field error map when it refuses, so read the body of a 400 rather than retrying via POST /v1.2/warehouse/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. REPLACE one bill -- a purchase invoice a supplier issued to this organization. A PUT sends the whole document: a field you omit is not left alone, it is reset, and nested line arrays replace the existing lines wholesale. Use the PATCH tool to change one field via PUT /v1.1/bills/{id}/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. Mark one bill VOID -- a purchase invoice a supplier issued to this organization. Voiding is the state change Elorus offers instead of deleting a document that has already been issued: the document and its number survive, it stops counting towards balances, and nothing in this integration un-voids it via PUT /v1.1/bills/{id}/void/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. REPLACE one cash payment -- money paid OUT, against a bill or a supplier. A PUT sends the whole document: a field you omit is not left alone, it is reset, and nested line arrays replace the existing lines wholesale. Use the PATCH tool to change one field via PUT /v1.1/cashpayments/{id}/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. REPLACE one cash receipt -- money taken IN, against an invoice or a client. A PUT sends the whole document: a field you omit is not left alone, it is reset, and nested line arrays replace the existing lines wholesale. Use the PATCH tool to change one field via PUT /v1.1/cashreceipts/{id}/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. REPLACE one contact -- a client or supplier, with its billing and shipping addresses. A PUT sends the whole document: a field you omit is not left alone, it is reset, and nested line arrays replace the existing lines wholesale. Use the PATCH tool to change one field via PUT /v1.1/contacts/{id}/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. REPLACE one credit note -- credit issued TO a client, which can then be applied against invoices. A PUT sends the whole document: a field you omit is not left alone, it is reset, and nested line arrays replace the existing lines wholesale. Use the PATCH tool to change one field via PUT /v1.1/creditnotes/{id}/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. Mark one credit note VOID -- credit issued TO a client, which can then be applied against invoices. Voiding is the state change Elorus offers instead of deleting a document that has already been issued: the document and its number survive, it stops counting towards balances, and nothing in this integration un-voids it via PUT /v1.1/creditnotes/{id}/void/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. REPLACE one email template -- the subject and body Elorus uses when it emails a document. A PUT sends the whole document: a field you omit is not left alone, it is reset, and nested line arrays replace the existing lines wholesale. Use the PATCH tool to change one field via PUT /v1.1/emailtemplates/{id}/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. REPLACE one estimate -- a quotation sent to a client before any invoice exists. A PUT sends the whole document: a field you omit is not left alone, it is reset, and nested line arrays replace the existing lines wholesale. Use the PATCH tool to change one field via PUT /v1.1/estimates/{id}/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. REPLACE one expense -- a cost recorded against the organization, optionally billable to a project. A PUT sends the whole document: a field you omit is not left alone, it is reset, and nested line arrays replace the existing lines wholesale. Use the PATCH tool to change one field via PUT /v1.1/expenses/{id}/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. REPLACE one invoice -- a sales invoice issued to a client. A PUT sends the whole document: a field you omit is not left alone, it is reset, and nested line arrays replace the existing lines wholesale. Use the PATCH tool to change one field via PUT /v1.1/invoices/{id}/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. Mark one invoice VOID -- a sales invoice issued to a client. Voiding is the state change Elorus offers instead of deleting a document that has already been issued: the document and its number survive, it stops counting towards balances, and nothing in this integration un-voids it via PUT /v1.1/invoices/{id}/void/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. REPLACE one numbering sequence -- the counter Elorus draws document numbers from. A PUT sends the whole document: a field you omit is not left alone, it is reset, and nested line arrays replace the existing lines wholesale. Use the PATCH tool to change one field via PUT /v1.1/numberingsequence/{id}/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. REPLACE one product -- a product or service line item, with its price and stock. A PUT sends the whole document: a field you omit is not left alone, it is reset, and nested line arrays replace the existing lines wholesale. Use the PATCH tool to change one field via PUT /v1.1/products/{id}/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. REPLACE one recurring invoice -- the schedule Elorus issues repeating invoices from. A PUT sends the whole document: a field you omit is not left alone, it is reset, and nested line arrays replace the existing lines wholesale. Use the PATCH tool to change one field via PUT /v1.1/recurringinvoices/{id}/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. REPLACE one supplier credit -- credit received FROM a supplier, which can then be applied against bills. A PUT sends the whole document: a field you omit is not left alone, it is reset, and nested line arrays replace the existing lines wholesale. Use the PATCH tool to change one field via PUT /v1.1/suppliercredits/{id}/

ON THE DEPRECATED v1.1 API: Elorus' v1.2 announcement put v1.1 in maintenance mode until removal on 2026-04-30 while the live v1.1 reference banner says 2026-12-31 -- the two sealed sources disagree and the later date looks like an extension -- so prefer the v1.2 tool for the same resource where one exists. Mark one supplier credit VOID -- credit received FROM a supplier, which can then be applied against bills. Voiding is the state change Elorus offers instead of deleting a document that has already been issued: the document and its number survive, it stops counting towards balances, and nothing in this integration un-voids it via PUT /v1.1/suppliercredits/{id}/void/

REPLACE one bill -- a purchase invoice a supplier issued to this organization. A PUT sends the whole document: a field you omit is not left alone, it is reset, and nested line arrays replace the existing lines wholesale. Use the PATCH tool to change one field via PUT /v1.2/bills/{id}/

Mark one bill VOID -- a purchase invoice a supplier issued to this organization. Voiding is the state change Elorus offers instead of deleting a document that has already been issued: the document and its number survive, it stops counting towards balances, and nothing in this integration un-voids it via PUT /v1.2/bills/{id}/void/

REPLACE one internal note on a bill -- a purchase invoice a supplier issued to this organization. A PUT sends the whole note, so the previous text is gone rather than amended via PUT /v1.2/bills/{parent_pk}/notes/{id}/

REPLACE one cash payment -- money paid OUT, against a bill or a supplier. A PUT sends the whole document: a field you omit is not left alone, it is reset, and nested line arrays replace the existing lines wholesale. Use the PATCH tool to change one field via PUT /v1.2/cashpayments/{id}/

REPLACE one internal note on a cash payment -- money paid OUT, against a bill or a supplier. A PUT sends the whole note, so the previous text is gone rather than amended via PUT /v1.2/cashpayments/{parent_pk}/notes/{id}/

REPLACE one cash receipt -- money taken IN, against an invoice or a client. A PUT sends the whole document: a field you omit is not left alone, it is reset, and nested line arrays replace the existing lines wholesale. Use the PATCH tool to change one field via PUT /v1.2/cashreceipts/{id}/

REPLACE one internal note on a cash receipt -- money taken IN, against an invoice or a client. A PUT sends the whole note, so the previous text is gone rather than amended via PUT /v1.2/cashreceipts/{parent_pk}/notes/{id}/

REPLACE one contact -- a client or supplier, with its billing and shipping addresses. A PUT sends the whole document: a field you omit is not left alone, it is reset, and nested line arrays replace the existing lines wholesale. Use the PATCH tool to change one field via PUT /v1.2/contacts/{id}/

REPLACE one internal note on a contact -- a client or supplier, with its billing and shipping addresses. A PUT sends the whole note, so the previous text is gone rather than amended via PUT /v1.2/contacts/{parent_pk}/notes/{id}/

REPLACE one credit note -- credit issued TO a client, which can then be applied against invoices. A PUT sends the whole document: a field you omit is not left alone, it is reset, and nested line arrays replace the existing lines wholesale. Use the PATCH tool to change one field via PUT /v1.2/creditnotes/{id}/

Mark one credit note VOID -- credit issued TO a client, which can then be applied against invoices. Voiding is the state change Elorus offers instead of deleting a document that has already been issued: the document and its number survive, it stops counting towards balances, and nothing in this integration un-voids it via PUT /v1.2/creditnotes/{id}/void/

REPLACE one client-facing discussion message on a credit note -- credit issued TO a client, which can then be applied against invoices. A PUT sends the whole message, and the contact sees the new text via PUT /v1.2/creditnotes/{parent_pk}/discussions/{id}/

REPLACE one internal note on a credit note -- credit issued TO a client, which can then be applied against invoices. A PUT sends the whole note, so the previous text is gone rather than amended via PUT /v1.2/creditnotes/{parent_pk}/notes/{id}/

REPLACE one delivery note -- a despatch document for goods sent to a client. A PUT sends the whole document: a field you omit is not left alone, it is reset, and nested line arrays replace the existing lines wholesale. Use the PATCH tool to change one field via PUT /v1.2/deliverynotes/{id}/

Mark one delivery note VOID -- a despatch document for goods sent to a client. Voiding is the state change Elorus offers instead of deleting a document that has already been issued: the document and its number survive, it stops counting towards balances, and nothing in this integration un-voids it via PUT /v1.2/deliverynotes/{id}/void/

REPLACE one internal note on a delivery note -- a despatch document for goods sent to a client. A PUT sends the whole note, so the previous text is gone rather than amended via PUT /v1.2/deliverynotes/{parent_pk}/notes/{id}/

Rename one numbering sequence on a document type -- one of the organization's document kinds, which owns its own numbering sequences. The sequence and its new name are both named in the request body; the counter is untouched via PUT /v1.2/documenttypes/{parent_pk}/sequences/rename/

REPLACE one email template -- the subject and body Elorus uses when it emails a document. A PUT sends the whole document: a field you omit is not left alone, it is reset, and nested line arrays replace the existing lines wholesale. Use the PATCH tool to change one field via PUT /v1.2/emailtemplates/{id}/

REPLACE one estimate -- a quotation sent to a client before any invoice exists. A PUT sends the whole document: a field you omit is not left alone, it is reset, and nested line arrays replace the existing lines wholesale. Use the PATCH tool to change one field via PUT /v1.2/estimates/{id}/

REPLACE one client-facing discussion message on an estimate -- a quotation sent to a client before any invoice exists. A PUT sends the whole message, and the contact sees the new text via PUT /v1.2/estimates/{parent_pk}/discussions/{id}/

REPLACE one internal note on an estimate -- a quotation sent to a client before any invoice exists. A PUT sends the whole note, so the previous text is gone rather than amended via PUT /v1.2/estimates/{parent_pk}/notes/{id}/

REPLACE one expense -- a cost recorded against the organization, optionally billable to a project. A PUT sends the whole document: a field you omit is not left alone, it is reset, and nested line arrays replace the existing lines wholesale. Use the PATCH tool to change one field via PUT /v1.2/expenses/{id}/

REPLACE one internal note on an expense -- a cost recorded against the organization, optionally billable to a project. A PUT sends the whole note, so the previous text is gone rather than amended via PUT /v1.2/expenses/{parent_pk}/notes/{id}/

REPLACE one goods receipt -- a record of stock received into a warehouse. A PUT sends the whole document: a field you omit is not left alone, it is reset, and nested line arrays replace the existing lines wholesale. Use the PATCH tool to change one field via PUT /v1.2/goodsreceipts/{id}/

Mark one goods receipt VOID -- a record of stock received into a warehouse. Voiding is the state change Elorus offers instead of deleting a document that has already been issued: the document and its number survive, it stops counting towards balances, and nothing in this integration un-voids it via PUT /v1.2/goodsreceipts/{id}/void/

REPLACE one internal note on a goods receipt -- a record of stock received into a warehouse. A PUT sends the whole note, so the previous text is gone rather than amended via PUT /v1.2/goodsreceipts/{parent_pk}/notes/{id}/

Rename one goods-receipt numbering sequence -- the counter Elorus draws goods-receipt numbers from. The sequence and its new name are both named in the request body; the counter is untouched via PUT /v1.2/goodsreceiptsequences/rename/

REPLACE one invoice -- a sales invoice issued to a client. A PUT sends the whole document: a field you omit is not left alone, it is reset, and nested line arrays replace the existing lines wholesale. Use the PATCH tool to change one field via PUT /v1.2/invoices/{id}/

Mark one invoice VOID -- a sales invoice issued to a client. Voiding is the state change Elorus offers instead of deleting a document that has already been issued: the document and its number survive, it stops counting towards balances, and nothing in this integration un-voids it via PUT /v1.2/invoices/{id}/void/

REPLACE one client-facing discussion message on an invoice -- a sales invoice issued to a client. A PUT sends the whole message, and the contact sees the new text via PUT /v1.2/invoices/{parent_pk}/discussions/{id}/

REPLACE one internal note on an invoice -- a sales invoice issued to a client. A PUT sends the whole note, so the previous text is gone rather than amended via PUT /v1.2/invoices/{parent_pk}/notes/{id}/

REPLACE one organization branch -- a branch or establishment of the organization. A PUT sends the whole document: a field you omit is not left alone, it is reset, and nested line arrays replace the existing lines wholesale. Use the PATCH tool to change one field via PUT /v1.2/organizationbranch/{id}/

REPLACE one product -- a product or service line item, with its price and stock. A PUT sends the whole document: a field you omit is not left alone, it is reset, and nested line arrays replace the existing lines wholesale. Use the PATCH tool to change one field via PUT /v1.2/products/{id}/

REPLACE one internal note on a product -- a product or service line item, with its price and stock. A PUT sends the whole note, so the previous text is gone rather than amended via PUT /v1.2/products/{parent_pk}/notes/{id}/

REPLACE one project -- a billable engagement that time entries and expenses hang off. A PUT sends the whole document: a field you omit is not left alone, it is reset, and nested line arrays replace the existing lines wholesale. Use the PATCH tool to change one field via PUT /v1.2/projects/{id}/

REPLACE one client-facing discussion message on a project -- a billable engagement that time entries and expenses hang off. A PUT sends the whole message, and the contact sees the new text via PUT /v1.2/projects/{parent_pk}/discussions/{id}/

REPLACE one internal note on a project -- a billable engagement that time entries and expenses hang off. A PUT sends the whole note, so the previous text is gone rather than amended via PUT /v1.2/projects/{parent_pk}/notes/{id}/

REPLACE one extra fee on a project -- a billable engagement that time entries and expenses hang off. A PUT sends the whole fee, so an omitted field is reset rather than left alone via PUT /v1.2/projects/{parent_pk}/projectextrafees/{id}/

REPLACE one recurring invoice -- the schedule Elorus issues repeating invoices from. A PUT sends the whole document: a field you omit is not left alone, it is reset, and nested line arrays replace the existing lines wholesale. Use the PATCH tool to change one field via PUT /v1.2/recurringinvoices/{id}/

REPLACE one internal note on a recurring invoice -- the schedule Elorus issues repeating invoices from. A PUT sends the whole note, so the previous text is gone rather than amended via PUT /v1.2/recurringinvoices/{parent_pk}/notes/{id}/

REPLACE one supplier credit -- credit received FROM a supplier, which can then be applied against bills. A PUT sends the whole document: a field you omit is not left alone, it is reset, and nested line arrays replace the existing lines wholesale. Use the PATCH tool to change one field via PUT /v1.2/suppliercredits/{id}/

Mark one supplier credit VOID -- credit received FROM a supplier, which can then be applied against bills. Voiding is the state change Elorus offers instead of deleting a document that has already been issued: the document and its number survive, it stops counting towards balances, and nothing in this integration un-voids it via PUT /v1.2/suppliercredits/{id}/void/

REPLACE one internal note on a supplier credit -- credit received FROM a supplier, which can then be applied against bills. A PUT sends the whole note, so the previous text is gone rather than amended via PUT /v1.2/suppliercredits/{parent_pk}/notes/{id}/

REPLACE one task -- a billable activity type time entries are recorded against. A PUT sends the whole document: a field you omit is not left alone, it is reset, and nested line arrays replace the existing lines wholesale. Use the PATCH tool to change one field via PUT /v1.2/tasks/{id}/

REPLACE one time entry -- tracked time on a project, billable or not. A PUT sends the whole document: a field you omit is not left alone, it is reset, and nested line arrays replace the existing lines wholesale. Use the PATCH tool to change one field via PUT /v1.2/timeentries/{id}/

Flag one time entry -- tracked time on a project, billable or not -- as billed, which takes it out of the pool the next project invoice draws from via PUT /v1.2/timeentries/{id}/mark-billed/

Clear the billed flag on one time entry -- tracked time on a project, billable or not -- returning it to the pool the next project invoice draws from. The reverse of the mark-billed tool via PUT /v1.2/timeentries/{id}/mark-unbilled/

REPLACE one unit of measurement -- the unit a product quantity is expressed in. A PUT sends the whole document: a field you omit is not left alone, it is reset, and nested line arrays replace the existing lines wholesale. Use the PATCH tool to change one field via PUT /v1.2/unitofmeasurement/{id}/

REPLACE one warehouse -- a stock location goods receipts and adjustments move stock through. A PUT sends the whole document: a field you omit is not left alone, it is reset, and nested line arrays replace the existing lines wholesale. Use the PATCH tool to change one field via PUT /v1.2/warehouse/{id}/