QuickBooks Online

Create a chart-of-accounts account on the connected company. A name-list record does not post to the general ledger, and QuickBooks deactivates rather than deletes it, so the record persists in the company file once created. Only the fields listed below can be set — the body is assembled by Agentic Fabriq from named arguments, so no caller can post a free-form QuickBooks object. Nothing is emailed: QuickBooks sends a document only when the send endpoint is called, and that endpoint is not exposed.

DESTRUCTIVE — Create a supplier bill (accounts payable) on the connected company. This posts a real accounting document to the company's books; quickbooks_delete_bill is the only way back. Only the fields listed below can be set — the body is assembled by Agentic Fabriq from named arguments, so no caller can post a free-form QuickBooks object. Nothing is emailed: QuickBooks sends a document only when the send endpoint is called, and that endpoint is not exposed.

DESTRUCTIVE — Create a payment made to a supplier on the connected company. This posts a real accounting document to the company's books; quickbooks_void_bill_payment is the correction path. Only the fields listed below can be set — the body is assembled by Agentic Fabriq from named arguments, so no caller can post a free-form QuickBooks object. Nothing is emailed: QuickBooks sends a document only when the send endpoint is called, and that endpoint is not exposed.

Create a class (a reporting dimension) on the connected company. A name-list record does not post to the general ledger, and QuickBooks deactivates rather than deletes it, so the record persists in the company file once created. Only the fields listed below can be set — the body is assembled by Agentic Fabriq from named arguments, so no caller can post a free-form QuickBooks object. Nothing is emailed: QuickBooks sends a document only when the send endpoint is called, and that endpoint is not exposed.

Create a currency the company transacts in on the connected company. A name-list record does not post to the general ledger, and QuickBooks deactivates rather than deletes it, so the record persists in the company file once created. Only the fields listed below can be set — the body is assembled by Agentic Fabriq from named arguments, so no caller can post a free-form QuickBooks object. Nothing is emailed: QuickBooks sends a document only when the send endpoint is called, and that endpoint is not exposed.

DESTRUCTIVE — Create a credit note issued to a customer on the connected company. This posts a real accounting document to the company's books; quickbooks_delete_credit_memo is the only way back. Only the fields listed below can be set — the body is assembled by Agentic Fabriq from named arguments, so no caller can post a free-form QuickBooks object. Nothing is emailed: QuickBooks sends a document only when the send endpoint is called, and that endpoint is not exposed.

Create a customer on the connected company. A name-list record does not post to the general ledger, and QuickBooks deactivates rather than deletes it, so the record persists in the company file once created. Only the fields listed below can be set — the body is assembled by Agentic Fabriq from named arguments, so no caller can post a free-form QuickBooks object. Nothing is emailed: QuickBooks sends a document only when the send endpoint is called, and that endpoint is not exposed.

Create a department or location on the connected company. A name-list record does not post to the general ledger, and QuickBooks deactivates rather than deletes it, so the record persists in the company file once created. Only the fields listed below can be set — the body is assembled by Agentic Fabriq from named arguments, so no caller can post a free-form QuickBooks object. Nothing is emailed: QuickBooks sends a document only when the send endpoint is called, and that endpoint is not exposed.

DESTRUCTIVE — Create a bank deposit on the connected company. This posts a real accounting document to the company's books; quickbooks_delete_deposit is the only way back. Only the fields listed below can be set — the body is assembled by Agentic Fabriq from named arguments, so no caller can post a free-form QuickBooks object. Nothing is emailed: QuickBooks sends a document only when the send endpoint is called, and that endpoint is not exposed.

Create an employee on the connected company. A name-list record does not post to the general ledger, and QuickBooks deactivates rather than deletes it, so the record persists in the company file once created. Only the fields listed below can be set — the body is assembled by Agentic Fabriq from named arguments, so no caller can post a free-form QuickBooks object. Nothing is emailed: QuickBooks sends a document only when the send endpoint is called, and that endpoint is not exposed.

Create a quote or estimate (NON-POSTING) on the connected company. A estimate is NON-POSTING: it does not touch the general ledger and it can be deleted outright, which is what makes it the least consequential write in this integration. Only the fields listed below can be set — the body is assembled by Agentic Fabriq from named arguments, so no caller can post a free-form QuickBooks object. Nothing is emailed: QuickBooks sends a document only when the send endpoint is called, and that endpoint is not exposed.

DESTRUCTIVE — Create an inventory quantity/value adjustment on the connected company. This posts a real accounting document to the company's books; quickbooks_delete_inventory_adjustment is the only way back. Only the fields listed below can be set — the body is assembled by Agentic Fabriq from named arguments, so no caller can post a free-form QuickBooks object. Nothing is emailed: QuickBooks sends a document only when the send endpoint is called, and that endpoint is not exposed.

DESTRUCTIVE — Create an invoice on the connected company. This posts a real accounting document to the company's books; quickbooks_void_invoice is the correction path. Only the fields listed below can be set — the body is assembled by Agentic Fabriq from named arguments, so no caller can post a free-form QuickBooks object. Nothing is emailed: QuickBooks sends a document only when the send endpoint is called, and that endpoint is not exposed.

Create a product or service on the connected company. A name-list record does not post to the general ledger, and QuickBooks deactivates rather than deletes it, so the record persists in the company file once created. Only the fields listed below can be set — the body is assembled by Agentic Fabriq from named arguments, so no caller can post a free-form QuickBooks object. Nothing is emailed: QuickBooks sends a document only when the send endpoint is called, and that endpoint is not exposed.

Create a journal code (France locale only) on the connected company. A name-list record does not post to the general ledger, and QuickBooks deactivates rather than deletes it, so the record persists in the company file once created. Only the fields listed below can be set — the body is assembled by Agentic Fabriq from named arguments, so no caller can post a free-form QuickBooks object. Nothing is emailed: QuickBooks sends a document only when the send endpoint is called, and that endpoint is not exposed.

DESTRUCTIVE — Create a general-ledger journal entry on the connected company. This posts a real accounting document to the company's books; quickbooks_delete_journal_entry is the only way back. Only the fields listed below can be set — the body is assembled by Agentic Fabriq from named arguments, so no caller can post a free-form QuickBooks object. Nothing is emailed: QuickBooks sends a document only when the send endpoint is called, and that endpoint is not exposed.

DESTRUCTIVE — record a payment received from a customer. This posts money to the books: it reduces the customer's outstanding balance and, when `invoice_id` is given, marks that invoice paid by the amount recorded. quickbooks_void_payment is the correction path and the one to reach for — it leaves the payment in the register at zero. quickbooks_delete_payment also exists and removes it entirely, which is the form that leaves a gap in the register; one recorded against the wrong customer still has to be unpicked by hand. It records that a payment HAPPENED; it does not move money — no card is charged and no transfer is initiated. Omitting `invoice_id` leaves the payment unapplied, which is a deliberate choice a bookkeeper then has to resolve.

Create a payment method on the connected company. A name-list record does not post to the general ledger, and QuickBooks deactivates rather than deletes it, so the record persists in the company file once created. Only the fields listed below can be set — the body is assembled by Agentic Fabriq from named arguments, so no caller can post a free-form QuickBooks object. Nothing is emailed: QuickBooks sends a document only when the send endpoint is called, and that endpoint is not exposed.

DESTRUCTIVE — Create an expense or cheque on the connected company. This posts a real accounting document to the company's books; quickbooks_delete_purchase is the only way back. Only the fields listed below can be set — the body is assembled by Agentic Fabriq from named arguments, so no caller can post a free-form QuickBooks object. Nothing is emailed: QuickBooks sends a document only when the send endpoint is called, and that endpoint is not exposed.

Create a purchase order (NON-POSTING) on the connected company. A purchase order is NON-POSTING: it does not touch the general ledger and it can be deleted outright, which is what makes it the least consequential write in this integration. Only the fields listed below can be set — the body is assembled by Agentic Fabriq from named arguments, so no caller can post a free-form QuickBooks object. Nothing is emailed: QuickBooks sends a document only when the send endpoint is called, and that endpoint is not exposed.

DESTRUCTIVE — Create a refund issued to a customer on the connected company. This posts a real accounting document to the company's books; quickbooks_delete_refund_receipt is the only way back. Only the fields listed below can be set — the body is assembled by Agentic Fabriq from named arguments, so no caller can post a free-form QuickBooks object. Nothing is emailed: QuickBooks sends a document only when the send endpoint is called, and that endpoint is not exposed.

DESTRUCTIVE — Create a sales receipt (sale paid at the point of sale) on the connected company. This posts a real accounting document to the company's books; quickbooks_void_sales_receipt is the correction path. Only the fields listed below can be set — the body is assembled by Agentic Fabriq from named arguments, so no caller can post a free-form QuickBooks object. Nothing is emailed: QuickBooks sends a document only when the send endpoint is called, and that endpoint is not exposed.

Create a tax agency on the connected company. A name-list record does not post to the general ledger, and QuickBooks deactivates rather than deletes it, so the record persists in the company file once created. Only the fields listed below can be set — the body is assembled by Agentic Fabriq from named arguments, so no caller can post a free-form QuickBooks object. Nothing is emailed: QuickBooks sends a document only when the send endpoint is called, and that endpoint is not exposed.

Create a payment term on the connected company. A name-list record does not post to the general ledger, and QuickBooks deactivates rather than deletes it, so the record persists in the company file once created. Only the fields listed below can be set — the body is assembled by Agentic Fabriq from named arguments, so no caller can post a free-form QuickBooks object. Nothing is emailed: QuickBooks sends a document only when the send endpoint is called, and that endpoint is not exposed.

Create a timesheet entry (NON-POSTING until billed) on the connected company. A time activity is NON-POSTING: it does not touch the general ledger and it can be deleted outright, which is what makes it the least consequential write in this integration. Only the fields listed below can be set — the body is assembled by Agentic Fabriq from named arguments, so no caller can post a free-form QuickBooks object. Nothing is emailed: QuickBooks sends a document only when the send endpoint is called, and that endpoint is not exposed.

DESTRUCTIVE — Create a transfer between two accounts on the connected company. This posts a real accounting document to the company's books; quickbooks_delete_transfer is the only way back. Only the fields listed below can be set — the body is assembled by Agentic Fabriq from named arguments, so no caller can post a free-form QuickBooks object. Nothing is emailed: QuickBooks sends a document only when the send endpoint is called, and that endpoint is not exposed.

Create a vendor or supplier on the connected company. A name-list record does not post to the general ledger, and QuickBooks deactivates rather than deletes it, so the record persists in the company file once created. Only the fields listed below can be set — the body is assembled by Agentic Fabriq from named arguments, so no caller can post a free-form QuickBooks object. Nothing is emailed: QuickBooks sends a document only when the send endpoint is called, and that endpoint is not exposed.

DESTRUCTIVE — Create a credit from a supplier on the connected company. This posts a real accounting document to the company's books; quickbooks_delete_vendor_credit is the only way back. Only the fields listed below can be set — the body is assembled by Agentic Fabriq from named arguments, so no caller can post a free-form QuickBooks object. Nothing is emailed: QuickBooks sends a document only when the send endpoint is called, and that endpoint is not exposed.

DESTRUCTIVE — delete one attachment outright. There is no undo and no voided remnant: the record leaves the register entirely. QuickBooks publishes no void for a attachment, so this is the only removal there is. The record's current SyncToken is required and is not looked up automatically, so an agent must read it immediately beforehand.

DESTRUCTIVE — delete one bill outright. There is no undo and no voided remnant: the record leaves the register entirely. This exists because Agentic Fabriq can CREATE a bill and QuickBooks publishes no void for one — shipping a posting write with no way back is the asymmetry, not the fix. The record's current SyncToken is required and is not looked up automatically, so an agent must read it immediately beforehand.

DESTRUCTIVE — delete one bill payment outright. There is no undo and no voided remnant: the record leaves the register entirely. USE quickbooks_void_bill_payment INSTEAD unless you have been told specifically to delete. A void leaves the document in the register at zero, keeping its number, visible to anyone reconciling the period; this removes it entirely, so the next reader sees a gap they cannot detect. QuickBooks publishes both and Agentic Fabriq now exposes both — under separate scopes, so an organisation can grant the traceable one and withhold this — because withholding it from the catalog never withheld it from the credential. The record's current SyncToken is required and is not looked up automatically, so an agent must read it immediately beforehand.

DESTRUCTIVE — delete one budget outright. There is no undo and no voided remnant: the record leaves the register entirely. QuickBooks publishes no void for a budget, so this is the only removal there is. The record's current SyncToken is required and is not looked up automatically, so an agent must read it immediately beforehand.

DESTRUCTIVE — delete one credit memo outright. There is no undo and no voided remnant: the record leaves the register entirely. This exists because Agentic Fabriq can CREATE a credit memo and QuickBooks publishes no void for one — shipping a posting write with no way back is the asymmetry, not the fix. The record's current SyncToken is required and is not looked up automatically, so an agent must read it immediately beforehand.

DESTRUCTIVE — delete one deposit outright. There is no undo and no voided remnant: the record leaves the register entirely. This exists because Agentic Fabriq can CREATE a deposit and QuickBooks publishes no void for one — shipping a posting write with no way back is the asymmetry, not the fix. The record's current SyncToken is required and is not looked up automatically, so an agent must read it immediately beforehand.

DESTRUCTIVE — delete one estimate outright. There is no undo and no voided remnant: the record leaves the register entirely. This exists because Agentic Fabriq can CREATE a estimate and QuickBooks publishes no void for one — shipping a posting write with no way back is the asymmetry, not the fix. The record's current SyncToken is required and is not looked up automatically, so an agent must read it immediately beforehand.

DESTRUCTIVE — delete one inventory adjustment outright. There is no undo and no voided remnant: the record leaves the register entirely. This exists because Agentic Fabriq can CREATE a inventory adjustment and QuickBooks publishes no void for one — shipping a posting write with no way back is the asymmetry, not the fix. The record's current SyncToken is required and is not looked up automatically, so an agent must read it immediately beforehand.

DESTRUCTIVE — delete one invoice outright. There is no undo and no voided remnant: the record leaves the register entirely. USE quickbooks_void_invoice INSTEAD unless you have been told specifically to delete. A void leaves the document in the register at zero, keeping its number, visible to anyone reconciling the period; this removes it entirely, so the next reader sees a gap they cannot detect. QuickBooks publishes both and Agentic Fabriq now exposes both — under separate scopes, so an organisation can grant the traceable one and withhold this — because withholding it from the catalog never withheld it from the credential. The record's current SyncToken is required and is not looked up automatically, so an agent must read it immediately beforehand.

DESTRUCTIVE — delete one journal entry outright. There is no undo and no voided remnant: the record leaves the register entirely. This exists because Agentic Fabriq can CREATE a journal entry and QuickBooks publishes no void for one — shipping a posting write with no way back is the asymmetry, not the fix. The record's current SyncToken is required and is not looked up automatically, so an agent must read it immediately beforehand.

DESTRUCTIVE — delete one payment outright. There is no undo and no voided remnant: the record leaves the register entirely. USE quickbooks_void_payment INSTEAD unless you have been told specifically to delete. A void leaves the document in the register at zero, keeping its number, visible to anyone reconciling the period; this removes it entirely, so the next reader sees a gap they cannot detect. QuickBooks publishes both and Agentic Fabriq now exposes both — under separate scopes, so an organisation can grant the traceable one and withhold this — because withholding it from the catalog never withheld it from the credential. The record's current SyncToken is required and is not looked up automatically, so an agent must read it immediately beforehand.

DESTRUCTIVE — delete one expense outright. There is no undo and no voided remnant: the record leaves the register entirely. This exists because Agentic Fabriq can CREATE a expense and QuickBooks publishes no void for one — shipping a posting write with no way back is the asymmetry, not the fix. The record's current SyncToken is required and is not looked up automatically, so an agent must read it immediately beforehand.

DESTRUCTIVE — delete one purchase order outright. There is no undo and no voided remnant: the record leaves the register entirely. This exists because Agentic Fabriq can CREATE a purchase order and QuickBooks publishes no void for one — shipping a posting write with no way back is the asymmetry, not the fix. The record's current SyncToken is required and is not looked up automatically, so an agent must read it immediately beforehand.

DESTRUCTIVE — delete one recurring transaction outright. There is no undo and no voided remnant: the record leaves the register entirely. This is the ONLY action Agentic Fabriq offers on a recurring template, and the asymmetry is deliberate: creating or amending one is a standing rule that posts to the books forever with no agent and no human in the loop, and that is excluded. Deleting one is how a rule that is already firing gets stopped. Note that it removes the TEMPLATE, not the transactions it has already produced. The record's current SyncToken is required and is not looked up automatically, so an agent must read it immediately beforehand.

DESTRUCTIVE — delete one refund receipt outright. There is no undo and no voided remnant: the record leaves the register entirely. This exists because Agentic Fabriq can CREATE a refund receipt and QuickBooks publishes no void for one — shipping a posting write with no way back is the asymmetry, not the fix. The record's current SyncToken is required and is not looked up automatically, so an agent must read it immediately beforehand.

DESTRUCTIVE — delete one sales receipt outright. There is no undo and no voided remnant: the record leaves the register entirely. USE quickbooks_void_sales_receipt INSTEAD unless you have been told specifically to delete. A void leaves the document in the register at zero, keeping its number, visible to anyone reconciling the period; this removes it entirely, so the next reader sees a gap they cannot detect. QuickBooks publishes both and Agentic Fabriq now exposes both — under separate scopes, so an organisation can grant the traceable one and withhold this — because withholding it from the catalog never withheld it from the credential. The record's current SyncToken is required and is not looked up automatically, so an agent must read it immediately beforehand.

DESTRUCTIVE — delete one time activity outright. There is no undo and no voided remnant: the record leaves the register entirely. This exists because Agentic Fabriq can CREATE a time activity and QuickBooks publishes no void for one — shipping a posting write with no way back is the asymmetry, not the fix. The record's current SyncToken is required and is not looked up automatically, so an agent must read it immediately beforehand.

DESTRUCTIVE — delete one transfer outright. There is no undo and no voided remnant: the record leaves the register entirely. This exists because Agentic Fabriq can CREATE a transfer and QuickBooks publishes no void for one — shipping a posting write with no way back is the asymmetry, not the fix. The record's current SyncToken is required and is not looked up automatically, so an agent must read it immediately beforehand.

DESTRUCTIVE — delete one vendor credit outright. There is no undo and no voided remnant: the record leaves the register entirely. This exists because Agentic Fabriq can CREATE a vendor credit and QuickBooks publishes no void for one — shipping a posting write with no way back is the asymmetry, not the fix. The record's current SyncToken is required and is not looked up automatically, so an agent must read it immediately beforehand.

Download one attached file by its Attachable Id — a receipt behind an expense, a signed purchase order — returned base64-encoded with its content type and byte length. One Id per call, never a list-and-sweep. A file above the size ceiling is refused rather than truncated: half a document is not a document, and a truncated blob is a corruption the agent cannot detect.

Get one account by Id — a chart-of-accounts account — including the fields the list projection omits and the record's current SyncToken. The SyncToken is QuickBooks' optimistic lock: every amendment, void and deletion requires the current one, so this action is a precondition of those rather than a convenience.

Get one attachment by Id — an attached file's metadata — including the fields the list projection omits and the record's current SyncToken. The SyncToken is QuickBooks' optimistic lock: every amendment, void and deletion requires the current one, so this action is a precondition of those rather than a convenience.

Get one bill by Id — a supplier bill (accounts payable) — including the fields the list projection omits and the record's current SyncToken. The SyncToken is QuickBooks' optimistic lock: every amendment, void and deletion requires the current one, so this action is a precondition of those rather than a convenience.

Get one bill payment by Id — a payment made to a supplier — including the fields the list projection omits and the record's current SyncToken. The SyncToken is QuickBooks' optimistic lock: every amendment, void and deletion requires the current one, so this action is a precondition of those rather than a convenience.

Get one budget by Id — a budget — including the fields the list projection omits and the record's current SyncToken. The SyncToken is QuickBooks' optimistic lock: every amendment, void and deletion requires the current one, so this action is a precondition of those rather than a convenience.

List records created, updated or deleted since a timestamp, for up to ten named entities — QuickBooks' change-data-capture feed. The right primitive for 'what changed since yesterday' without re-reading the whole company file. Read-only. The window is capped at 30 days (Intuit's own ceiling) and the entity list is required and capped, because an unbounded sweep over every entity is an export of the company file wearing an incremental-sync name.

Get one class by Id — a class (a reporting dimension) — including the fields the list projection omits and the record's current SyncToken. The SyncToken is QuickBooks' optimistic lock: every amendment, void and deletion requires the current one, so this action is a precondition of those rather than a convenience.

Get one company currency by Id — a currency the company transacts in — including the fields the list projection omits and the record's current SyncToken. The SyncToken is QuickBooks' optimistic lock: every amendment, void and deletion requires the current one, so this action is a precondition of those rather than a convenience.

Name the QuickBooks company this connection is bound to, with its legal name, country and fiscal year start. START HERE. This is the only call that says which company — and therefore whether these are a sandbox test company's books or a real business's — you are about to act on. Do it before any write.

Get one credit memo by Id — a credit note issued to a customer — including the fields the list projection omits and the record's current SyncToken. The SyncToken is QuickBooks' optimistic lock: every amendment, void and deletion requires the current one, so this action is a precondition of those rather than a convenience.

Render one credit memo as the PDF QuickBooks itself produces, returned base64-encoded with its byte length. Read-only: this renders a document the agent can already read and sends nothing to anybody. Emailing it is a different operation and is not exposed.

Get one customer by Id — a customer — including the fields the list projection omits and the record's current SyncToken. The SyncToken is QuickBooks' optimistic lock: every amendment, void and deletion requires the current one, so this action is a precondition of those rather than a convenience.

Get one customer type by Id — a customer type — including the fields the list projection omits and the record's current SyncToken. The SyncToken is QuickBooks' optimistic lock: every amendment, void and deletion requires the current one, so this action is a precondition of those rather than a convenience.

Get one department by Id — a department or location — including the fields the list projection omits and the record's current SyncToken. The SyncToken is QuickBooks' optimistic lock: every amendment, void and deletion requires the current one, so this action is a precondition of those rather than a convenience.

Get one deposit by Id — a bank deposit — including the fields the list projection omits and the record's current SyncToken. The SyncToken is QuickBooks' optimistic lock: every amendment, void and deletion requires the current one, so this action is a precondition of those rather than a convenience.

Get one employee by Id — an employee — including the fields the list projection omits and the record's current SyncToken. The SyncToken is QuickBooks' optimistic lock: every amendment, void and deletion requires the current one, so this action is a precondition of those rather than a convenience.

List what the connected QuickBooks subscription is entitled to — which features and limits this company's plan carries. THE DIAGNOSTIC READ FOR A WHOLE CLASS OF FAILURE: a call refused because the company's plan does not include the feature looks identical to a call refused because the feature is switched off, and only this distinguishes them. Read-only. Note that Intuit serves this from /entitlements/v3/{company} rather than from the accounting path.

Get one estimate by Id — a quote or estimate (NON-POSTING) — including the fields the list projection omits and the record's current SyncToken. The SyncToken is QuickBooks' optimistic lock: every amendment, void and deletion requires the current one, so this action is a precondition of those rather than a convenience.

Render one estimate as the PDF QuickBooks itself produces, returned base64-encoded with its byte length. Read-only: this renders a document the agent can already read and sends nothing to anybody. Emailing it is a different operation and is not exposed.

Read the exchange rate between one foreign currency and the company's home currency, optionally as of a date. An exchange rate has no Id — it is keyed by currency pair and date — so this is how one is read, and it is the precondition of quickbooks_update_exchange_rate. Read-only.

Get one inventory adjustment by Id — an inventory quantity/value adjustment — including the fields the list projection omits and the record's current SyncToken. The SyncToken is QuickBooks' optimistic lock: every amendment, void and deletion requires the current one, so this action is a precondition of those rather than a convenience.

Get one invoice by Id — an invoice — including the fields the list projection omits and the record's current SyncToken. The SyncToken is QuickBooks' optimistic lock: every amendment, void and deletion requires the current one, so this action is a precondition of those rather than a convenience.

Render one invoice as the PDF QuickBooks itself produces, returned base64-encoded with its byte length. Read-only: this renders a document the agent can already read and sends nothing to anybody. Emailing it is a different operation and is not exposed.

Get one product or service by Id — a product or service — including the fields the list projection omits and the record's current SyncToken. The SyncToken is QuickBooks' optimistic lock: every amendment, void and deletion requires the current one, so this action is a precondition of those rather than a convenience.

Get one journal code by Id — a journal code (France locale only) — including the fields the list projection omits and the record's current SyncToken. The SyncToken is QuickBooks' optimistic lock: every amendment, void and deletion requires the current one, so this action is a precondition of those rather than a convenience.

Get one journal entry by Id — a general-ledger journal entry — including the fields the list projection omits and the record's current SyncToken. The SyncToken is QuickBooks' optimistic lock: every amendment, void and deletion requires the current one, so this action is a precondition of those rather than a convenience.

Get one payment by Id — a payment received from a customer — including the fields the list projection omits and the record's current SyncToken. The SyncToken is QuickBooks' optimistic lock: every amendment, void and deletion requires the current one, so this action is a precondition of those rather than a convenience.

Get one payment method by Id — a payment method — including the fields the list projection omits and the record's current SyncToken. The SyncToken is QuickBooks' optimistic lock: every amendment, void and deletion requires the current one, so this action is a precondition of those rather than a convenience.

Render one payment as the PDF QuickBooks itself produces, returned base64-encoded with its byte length. Read-only: this renders a document the agent can already read and sends nothing to anybody. Emailing it is a different operation and is not exposed.

Read the company's QuickBooks preferences — which sales-form fields are on, whether custom transaction numbers are permitted, the default terms and payment methods, and which of classes/departments/multicurrency are enabled. This is the diagnostic read behind half of QuickBooks' rejections: a create refused as 'DocNumber not permitted' or 'Class required' is a preference, not a bad argument. Read-only — updating preferences is not exposed, because one write there changes the meaning of every subsequent transaction.

Get one expense by Id — an expense or cheque — including the fields the list projection omits and the record's current SyncToken. The SyncToken is QuickBooks' optimistic lock: every amendment, void and deletion requires the current one, so this action is a precondition of those rather than a convenience.

Get one purchase order by Id — a purchase order (NON-POSTING) — including the fields the list projection omits and the record's current SyncToken. The SyncToken is QuickBooks' optimistic lock: every amendment, void and deletion requires the current one, so this action is a precondition of those rather than a convenience.

Render one purchase order as the PDF QuickBooks itself produces, returned base64-encoded with its byte length. Read-only: this renders a document the agent can already read and sends nothing to anybody. Emailing it is a different operation and is not exposed.

Get one recurring transaction by Id — a recurring transaction template — including the fields the list projection omits and the record's current SyncToken. The SyncToken is QuickBooks' optimistic lock: every amendment, void and deletion requires the current one, so this action is a precondition of those rather than a convenience.

Get one refund receipt by Id — a refund issued to a customer — including the fields the list projection omits and the record's current SyncToken. The SyncToken is QuickBooks' optimistic lock: every amendment, void and deletion requires the current one, so this action is a precondition of those rather than a convenience.

Render one refund receipt as the PDF QuickBooks itself produces, returned base64-encoded with its byte length. Read-only: this renders a document the agent can already read and sends nothing to anybody. Emailing it is a different operation and is not exposed.

Get one reimbursable charge by Id — a reimbursable charge — including the fields the list projection omits and the record's current SyncToken. The SyncToken is QuickBooks' optimistic lock: every amendment, void and deletion requires the current one, so this action is a precondition of those rather than a convenience.

Get one sales receipt by Id — a sales receipt (sale paid at the point of sale) — including the fields the list projection omits and the record's current SyncToken. The SyncToken is QuickBooks' optimistic lock: every amendment, void and deletion requires the current one, so this action is a precondition of those rather than a convenience.

Render one sales receipt as the PDF QuickBooks itself produces, returned base64-encoded with its byte length. Read-only: this renders a document the agent can already read and sends nothing to anybody. Emailing it is a different operation and is not exposed.

Get one tax agency by Id — a tax agency — including the fields the list projection omits and the record's current SyncToken. The SyncToken is QuickBooks' optimistic lock: every amendment, void and deletion requires the current one, so this action is a precondition of those rather than a convenience.

Get one tax classification by Id — a tax classification — including the fields the list projection omits and the record's current SyncToken. The SyncToken is QuickBooks' optimistic lock: every amendment, void and deletion requires the current one, so this action is a precondition of those rather than a convenience.

Get one tax code by Id — a tax code — including the fields the list projection omits and the record's current SyncToken. The SyncToken is QuickBooks' optimistic lock: every amendment, void and deletion requires the current one, so this action is a precondition of those rather than a convenience.

Get one tax rate by Id — a tax rate — including the fields the list projection omits and the record's current SyncToken. The SyncToken is QuickBooks' optimistic lock: every amendment, void and deletion requires the current one, so this action is a precondition of those rather than a convenience.

Get one payment term by Id — a payment term — including the fields the list projection omits and the record's current SyncToken. The SyncToken is QuickBooks' optimistic lock: every amendment, void and deletion requires the current one, so this action is a precondition of those rather than a convenience.

Get one time activity by Id — a timesheet entry (NON-POSTING until billed) — including the fields the list projection omits and the record's current SyncToken. The SyncToken is QuickBooks' optimistic lock: every amendment, void and deletion requires the current one, so this action is a precondition of those rather than a convenience.

Get one transfer by Id — a transfer between two accounts — including the fields the list projection omits and the record's current SyncToken. The SyncToken is QuickBooks' optimistic lock: every amendment, void and deletion requires the current one, so this action is a precondition of those rather than a convenience.

Get one vendor by Id — a vendor or supplier — including the fields the list projection omits and the record's current SyncToken. The SyncToken is QuickBooks' optimistic lock: every amendment, void and deletion requires the current one, so this action is a precondition of those rather than a convenience.

Get one vendor credit by Id — a credit from a supplier — including the fields the list projection omits and the record's current SyncToken. The SyncToken is QuickBooks' optimistic lock: every amendment, void and deletion requires the current one, so this action is a precondition of those rather than a convenience.

List the company's accounts — a chart-of-accounts account. Returns each record's Id, which is what every other account action requires; QuickBooks resolves nothing by name. Inactive records are hidden by default: QuickBooks deactivates rather than deletes, so a company file accumulates them. Paged: 100 per page by default, 1000 at most.

List the company's attachables — an attached file's metadata. Returns each record's Id, which is what every other attachment action requires; QuickBooks resolves nothing by name. Paged: 100 per page by default, 1000 at most.

List the company's bill payments — a payment made to a supplier. Returns each record's Id, which is what every other bill payment action requires; QuickBooks resolves nothing by name. Most recent transaction date first. Paged: 100 per page by default, 1000 at most.

List the company's bills — a supplier bill (accounts payable). Returns each record's Id, which is what every other bill action requires; QuickBooks resolves nothing by name. Most recent transaction date first. Paged: 100 per page by default, 1000 at most.

List the company's budgets — a budget. Returns each record's Id, which is what every other budget action requires; QuickBooks resolves nothing by name. Paged: 100 per page by default, 1000 at most.

List the company's classes — a class (a reporting dimension). Returns each record's Id, which is what every other class action requires; QuickBooks resolves nothing by name. Inactive records are hidden by default: QuickBooks deactivates rather than deletes, so a company file accumulates them. Paged: 100 per page by default, 1000 at most.

List the company's company currencies — a currency the company transacts in. Returns each record's Id, which is what every other company currency action requires; QuickBooks resolves nothing by name. Inactive records are hidden by default: QuickBooks deactivates rather than deletes, so a company file accumulates them. Paged: 100 per page by default, 1000 at most.

List the company's credit memos — a credit note issued to a customer. Returns each record's Id, which is what every other credit memo action requires; QuickBooks resolves nothing by name. Most recent transaction date first. Paged: 100 per page by default, 1000 at most.

List the company's customer types — a customer type. Returns each record's Id, which is what every other customer type action requires; QuickBooks resolves nothing by name. Inactive records are hidden by default: QuickBooks deactivates rather than deletes, so a company file accumulates them. Read-only entity. Paged: 100 per page by default, 1000 at most.

List the company's customers — a customer. Returns each record's Id, which is what every other customer action requires; QuickBooks resolves nothing by name. Inactive records are hidden by default: QuickBooks deactivates rather than deletes, so a company file accumulates them. Paged: 100 per page by default, 1000 at most.

List the company's departments — a department or location. Returns each record's Id, which is what every other department action requires; QuickBooks resolves nothing by name. Inactive records are hidden by default: QuickBooks deactivates rather than deletes, so a company file accumulates them. Paged: 100 per page by default, 1000 at most.

List the company's deposits — a bank deposit. Returns each record's Id, which is what every other deposit action requires; QuickBooks resolves nothing by name. Most recent transaction date first. Paged: 100 per page by default, 1000 at most.

List the company's employees — an employee. Returns each record's Id, which is what every other employee action requires; QuickBooks resolves nothing by name. Inactive records are hidden by default: QuickBooks deactivates rather than deletes, so a company file accumulates them. Paged: 100 per page by default, 1000 at most.

List the company's estimates — a quote or estimate (NON-POSTING). Returns each record's Id, which is what every other estimate action requires; QuickBooks resolves nothing by name. Most recent transaction date first. Paged: 100 per page by default, 1000 at most.

List the company's exchange rates — a currency exchange rate. Returns each record's Id, which is what every other exchange rate action requires; QuickBooks resolves nothing by name. An exchange rate has no Id: it is keyed by source currency, target currency and date. Use quickbooks_get_exchange_rate to read one by currency code. Paged: 100 per page by default, 1000 at most.

List the company's inventory adjustments — an inventory quantity/value adjustment. Returns each record's Id, which is what every other inventory adjustment action requires; QuickBooks resolves nothing by name. Most recent transaction date first. Paged: 100 per page by default, 1000 at most.

List the company's invoices — an invoice. Returns each record's Id, which is what every other invoice action requires; QuickBooks resolves nothing by name. Most recent transaction date first. Paged: 100 per page by default, 1000 at most.

List the company's items — a product or service. Returns each record's Id, which is what every other product or service action requires; QuickBooks resolves nothing by name. Inactive records are hidden by default: QuickBooks deactivates rather than deletes, so a company file accumulates them. Paged: 100 per page by default, 1000 at most.

List the company's journal codes — a journal code (France locale only). Returns each record's Id, which is what every other journal code action requires; QuickBooks resolves nothing by name. Inactive records are hidden by default: QuickBooks deactivates rather than deletes, so a company file accumulates them. Paged: 100 per page by default, 1000 at most.

List the company's journal entries — a general-ledger journal entry. Returns each record's Id, which is what every other journal entry action requires; QuickBooks resolves nothing by name. Most recent transaction date first. Paged: 100 per page by default, 1000 at most.

List the company's payment methods — a payment method. Returns each record's Id, which is what every other payment method action requires; QuickBooks resolves nothing by name. Inactive records are hidden by default: QuickBooks deactivates rather than deletes, so a company file accumulates them. Paged: 100 per page by default, 1000 at most.

List the company's payments — a payment received from a customer. Returns each record's Id, which is what every other payment action requires; QuickBooks resolves nothing by name. Most recent transaction date first. Paged: 100 per page by default, 1000 at most.

List the company's purchase orders — a purchase order (NON-POSTING). Returns each record's Id, which is what every other purchase order action requires; QuickBooks resolves nothing by name. Most recent transaction date first. Paged: 100 per page by default, 1000 at most.

List the company's purchases — an expense or cheque. Returns each record's Id, which is what every other expense action requires; QuickBooks resolves nothing by name. Most recent transaction date first. Paged: 100 per page by default, 1000 at most.

List the company's recurring transactions — a recurring transaction template. Returns each record's Id, which is what every other recurring transaction action requires; QuickBooks resolves nothing by name. Paged: 100 per page by default, 1000 at most.

List the company's refund receipts — a refund issued to a customer. Returns each record's Id, which is what every other refund receipt action requires; QuickBooks resolves nothing by name. Most recent transaction date first. Paged: 100 per page by default, 1000 at most.

List the company's reimburse charges — a reimbursable charge. Returns each record's Id, which is what every other reimbursable charge action requires; QuickBooks resolves nothing by name. Most recent transaction date first. Read-only entity. Paged: 100 per page by default, 1000 at most.

List the company's sales receipts — a sales receipt (sale paid at the point of sale). Returns each record's Id, which is what every other sales receipt action requires; QuickBooks resolves nothing by name. Most recent transaction date first. Paged: 100 per page by default, 1000 at most.

List the company's tax agencies — a tax agency. Returns each record's Id, which is what every other tax agency action requires; QuickBooks resolves nothing by name. Paged: 100 per page by default, 1000 at most.

List the tax classifications directly beneath one parent classification. QuickBooks' tax classifications are a TREE and a plain query returns it flattened, so this is how the hierarchy is walked — which is what you need to pick the right classification for an item rather than guessing from a name. Read-only.

List the company's tax classifications — a tax classification. Returns each record's Id, which is what every other tax classification action requires; QuickBooks resolves nothing by name. Read-only entity. Paged: 100 per page by default, 1000 at most.

List every tax classification at one depth in the tree — level 0 is the top. The companion to quickbooks_list_tax_classification_children for walking the hierarchy from the top down rather than from a known parent. Read-only.

List the company's tax codes — a tax code. Returns each record's Id, which is what every other tax code action requires; QuickBooks resolves nothing by name. Inactive records are hidden by default: QuickBooks deactivates rather than deletes, so a company file accumulates them. Created through TaxService, which AF does not expose. Paged: 100 per page by default, 1000 at most.

List the company's tax rates — a tax rate. Returns each record's Id, which is what every other tax rate action requires; QuickBooks resolves nothing by name. Inactive records are hidden by default: QuickBooks deactivates rather than deletes, so a company file accumulates them. Created through TaxService, which AF does not expose. Paged: 100 per page by default, 1000 at most.

List the company's terms — a payment term. Returns each record's Id, which is what every other payment term action requires; QuickBooks resolves nothing by name. Inactive records are hidden by default: QuickBooks deactivates rather than deletes, so a company file accumulates them. Paged: 100 per page by default, 1000 at most.

List the company's time activities — a timesheet entry (NON-POSTING until billed). Returns each record's Id, which is what every other time activity action requires; QuickBooks resolves nothing by name. Most recent transaction date first. Paged: 100 per page by default, 1000 at most.

List the company's transfers — a transfer between two accounts. Returns each record's Id, which is what every other transfer action requires; QuickBooks resolves nothing by name. Most recent transaction date first. Paged: 100 per page by default, 1000 at most.

List the company's vendor credits — a credit from a supplier. Returns each record's Id, which is what every other vendor credit action requires; QuickBooks resolves nothing by name. Most recent transaction date first. Paged: 100 per page by default, 1000 at most.

List the company's vendors — a vendor or supplier. Returns each record's Id, which is what every other vendor action requires; QuickBooks resolves nothing by name. Inactive records are hidden by default: QuickBooks deactivates rather than deletes, so a company file accumulates them. Paged: 100 per page by default, 1000 at most.

DESTRUCTIVE — replace the whole content of one bill: its lines, its amounts and the party it belongs to. This is QuickBooks' FULL update and it behaves differently from quickbooks_update_bill: Intuit sets every writable field this request omits to NULL, silently, answering 200. So the caller must restate the document, not just the part it wants to change — read it with quickbooks_get_bill first and send back everything that should survive. Only the fields listed below can be set; anything outside that list is cleared by QuickBooks whatever the caller intended, which is why this action is flagged destructive and refuses to run without confirm=true. If all you need is a due date, a memo or a note, use quickbooks_update_bill — it cannot lose anything. The record's current SyncToken is required and is not looked up automatically.

DESTRUCTIVE — replace the whole content of one bill payment: its lines, its amounts and the party it belongs to. This is QuickBooks' FULL update and it behaves differently from quickbooks_update_bill_payment: Intuit sets every writable field this request omits to NULL, silently, answering 200. So the caller must restate the document, not just the part it wants to change — read it with quickbooks_get_bill_payment first and send back everything that should survive. Only the fields listed below can be set; anything outside that list is cleared by QuickBooks whatever the caller intended, which is why this action is flagged destructive and refuses to run without confirm=true. If all you need is a due date, a memo or a note, use quickbooks_update_bill_payment — it cannot lose anything. The record's current SyncToken is required and is not looked up automatically.

DESTRUCTIVE — replace the whole content of one credit memo: its lines, its amounts and the party it belongs to. This is QuickBooks' FULL update and it behaves differently from quickbooks_update_credit_memo: Intuit sets every writable field this request omits to NULL, silently, answering 200. So the caller must restate the document, not just the part it wants to change — read it with quickbooks_get_credit_memo first and send back everything that should survive. Only the fields listed below can be set; anything outside that list is cleared by QuickBooks whatever the caller intended, which is why this action is flagged destructive and refuses to run without confirm=true. If all you need is a due date, a memo or a note, use quickbooks_update_credit_memo — it cannot lose anything. The record's current SyncToken is required and is not looked up automatically.

DESTRUCTIVE — replace the whole content of one deposit: its lines, its amounts and the party it belongs to. This is QuickBooks' FULL update and it behaves differently from quickbooks_update_deposit: Intuit sets every writable field this request omits to NULL, silently, answering 200. So the caller must restate the document, not just the part it wants to change — read it with quickbooks_get_deposit first and send back everything that should survive. Only the fields listed below can be set; anything outside that list is cleared by QuickBooks whatever the caller intended, which is why this action is flagged destructive and refuses to run without confirm=true. If all you need is a due date, a memo or a note, use quickbooks_update_deposit — it cannot lose anything. The record's current SyncToken is required and is not looked up automatically.

DESTRUCTIVE — replace the whole content of one estimate: its lines, its amounts and the party it belongs to. This is QuickBooks' FULL update and it behaves differently from quickbooks_update_estimate: Intuit sets every writable field this request omits to NULL, silently, answering 200. So the caller must restate the document, not just the part it wants to change — read it with quickbooks_get_estimate first and send back everything that should survive. Only the fields listed below can be set; anything outside that list is cleared by QuickBooks whatever the caller intended, which is why this action is flagged destructive and refuses to run without confirm=true. If all you need is a due date, a memo or a note, use quickbooks_update_estimate — it cannot lose anything. The record's current SyncToken is required and is not looked up automatically.

DESTRUCTIVE — replace the whole content of one invoice: its lines, its amounts and the party it belongs to. This is QuickBooks' FULL update and it behaves differently from quickbooks_update_invoice: Intuit sets every writable field this request omits to NULL, silently, answering 200. So the caller must restate the document, not just the part it wants to change — read it with quickbooks_get_invoice first and send back everything that should survive. Only the fields listed below can be set; anything outside that list is cleared by QuickBooks whatever the caller intended, which is why this action is flagged destructive and refuses to run without confirm=true. If all you need is a due date, a memo or a note, use quickbooks_update_invoice — it cannot lose anything. The record's current SyncToken is required and is not looked up automatically.

DESTRUCTIVE — replace the whole content of one journal entry: its lines, its amounts and the party it belongs to. This is QuickBooks' FULL update and it behaves differently from quickbooks_update_journal_entry: Intuit sets every writable field this request omits to NULL, silently, answering 200. So the caller must restate the document, not just the part it wants to change — read it with quickbooks_get_journal_entry first and send back everything that should survive. Only the fields listed below can be set; anything outside that list is cleared by QuickBooks whatever the caller intended, which is why this action is flagged destructive and refuses to run without confirm=true. If all you need is a due date, a memo or a note, use quickbooks_update_journal_entry — it cannot lose anything. The record's current SyncToken is required and is not looked up automatically.

DESTRUCTIVE — replace the whole content of one expense: its lines, its amounts and the party it belongs to. This is QuickBooks' FULL update and it behaves differently from quickbooks_update_purchase: Intuit sets every writable field this request omits to NULL, silently, answering 200. So the caller must restate the document, not just the part it wants to change — read it with quickbooks_get_purchase first and send back everything that should survive. Only the fields listed below can be set; anything outside that list is cleared by QuickBooks whatever the caller intended, which is why this action is flagged destructive and refuses to run without confirm=true. If all you need is a due date, a memo or a note, use quickbooks_update_purchase — it cannot lose anything. The record's current SyncToken is required and is not looked up automatically.

DESTRUCTIVE — replace the whole content of one purchase order: its lines, its amounts and the party it belongs to. This is QuickBooks' FULL update and it behaves differently from quickbooks_update_purchase_order: Intuit sets every writable field this request omits to NULL, silently, answering 200. So the caller must restate the document, not just the part it wants to change — read it with quickbooks_get_purchase_order first and send back everything that should survive. Only the fields listed below can be set; anything outside that list is cleared by QuickBooks whatever the caller intended, which is why this action is flagged destructive and refuses to run without confirm=true. If all you need is a due date, a memo or a note, use quickbooks_update_purchase_order — it cannot lose anything. The record's current SyncToken is required and is not looked up automatically.

DESTRUCTIVE — replace the whole content of one refund receipt: its lines, its amounts and the party it belongs to. This is QuickBooks' FULL update and it behaves differently from quickbooks_update_refund_receipt: Intuit sets every writable field this request omits to NULL, silently, answering 200. So the caller must restate the document, not just the part it wants to change — read it with quickbooks_get_refund_receipt first and send back everything that should survive. Only the fields listed below can be set; anything outside that list is cleared by QuickBooks whatever the caller intended, which is why this action is flagged destructive and refuses to run without confirm=true. If all you need is a due date, a memo or a note, use quickbooks_update_refund_receipt — it cannot lose anything. The record's current SyncToken is required and is not looked up automatically.

DESTRUCTIVE — replace the whole content of one sales receipt: its lines, its amounts and the party it belongs to. This is QuickBooks' FULL update and it behaves differently from quickbooks_update_sales_receipt: Intuit sets every writable field this request omits to NULL, silently, answering 200. So the caller must restate the document, not just the part it wants to change — read it with quickbooks_get_sales_receipt first and send back everything that should survive. Only the fields listed below can be set; anything outside that list is cleared by QuickBooks whatever the caller intended, which is why this action is flagged destructive and refuses to run without confirm=true. If all you need is a due date, a memo or a note, use quickbooks_update_sales_receipt — it cannot lose anything. The record's current SyncToken is required and is not looked up automatically.

DESTRUCTIVE — replace the whole content of one vendor credit: its lines, its amounts and the party it belongs to. This is QuickBooks' FULL update and it behaves differently from quickbooks_update_vendor_credit: Intuit sets every writable field this request omits to NULL, silently, answering 200. So the caller must restate the document, not just the part it wants to change — read it with quickbooks_get_vendor_credit first and send back everything that should survive. Only the fields listed below can be set; anything outside that list is cleared by QuickBooks whatever the caller intended, which is why this action is flagged destructive and refuses to run without confirm=true. If all you need is a due date, a memo or a note, use quickbooks_update_vendor_credit — it cannot lose anything. The record's current SyncToken is required and is not looked up automatically.

Run one read-only SELECT against the company file in QuickBooks' query language. This is the widest read available and it is now the LAST resort rather than the first: every entity has a shaped list action of its own, so an organisation can grant the reads a workflow needs and withhold this. QuickBooks' query language has no INSERT, UPDATE or DELETE form, and Agentic Fabriq additionally refuses anything that is not a single SELECT before the request leaves — so it is read-only and cannot change the books.

Run one of QuickBooks' own financial reports — profit and loss, balance sheet, cash flow, trial balance, AR/AP aging, general ledger, sales and inventory summaries. THIS IS THE ONE READ NO QUERY CAN REPLACE: a report is an aggregation Intuit computes from the ledger, not rows a SELECT can assemble, so without this action a profit-and-loss question is unanswerable. Read-only; the endpoint has no write form. The report name is constrained to the documented list, because the name is a PATH SEGMENT on an authenticated request and because a name outside the list is a 400 the agent cannot diagnose, where a refusal here names the valid set.

Amend a named, fixed set of fields on one account, leaving every other field exactly as it was. This is a SPARSE update: QuickBooks applies only the fields present in the request. The full-object update — which replaces the record and blanks every field the caller omitted — is not exposed, and the field list below is what keeps the two apart. Nothing here can change a document's lines, its amounts or which customer or vendor it belongs to. The record's current SyncToken is required and is not looked up automatically, so an agent must read the record immediately beforehand and cannot amend one that changed underneath it. NOTE, AND IT IS NOT BOILERPLATE: Intuit publishes a sparse update for eleven entities and a account is not one of them — the only update sample Intuit ships for it sets sparse to false. Agentic Fabriq sends the flag anyway and bounds the field list, and third-party SDKs send it for every entity, but nobody has run this against a live company file. If QuickBooks were to ignore the flag, the fields below would be all that survived on the record. Read the record back afterwards the first time you use it.

Amend a named, fixed set of fields on one attachment, leaving every other field exactly as it was. This is a SPARSE update: QuickBooks applies only the fields present in the request. The full-object update — which replaces the record and blanks every field the caller omitted — is not exposed, and the field list below is what keeps the two apart. Nothing here can change a document's lines, its amounts or which customer or vendor it belongs to. The record's current SyncToken is required and is not looked up automatically, so an agent must read the record immediately beforehand and cannot amend one that changed underneath it. NOTE, AND IT IS NOT BOILERPLATE: Intuit publishes a sparse update for eleven entities and a attachment is not one of them — the only update sample Intuit ships for it sets sparse to false. Agentic Fabriq sends the flag anyway and bounds the field list, and third-party SDKs send it for every entity, but nobody has run this against a live company file. If QuickBooks were to ignore the flag, the fields below would be all that survived on the record. Read the record back afterwards the first time you use it.

Amend a named, fixed set of fields on one bill, leaving every other field exactly as it was. This is a SPARSE update: QuickBooks applies only the fields present in the request. The full-object update — which replaces the record and blanks every field the caller omitted — is a SEPARATE action (quickbooks_replace_bill), under a separate scope, flagged destructive, and the field list below is what keeps the two apart. Nothing here can change a document's lines, its amounts or which customer or vendor it belongs to. The record's current SyncToken is required and is not looked up automatically, so an agent must read the record immediately beforehand and cannot amend one that changed underneath it. NOTE, AND IT IS NOT BOILERPLATE: Intuit publishes a sparse update for eleven entities and a bill is not one of them — the only update sample Intuit ships for it sets sparse to false. Agentic Fabriq sends the flag anyway and bounds the field list, and third-party SDKs send it for every entity, but nobody has run this against a live company file. If QuickBooks were to ignore the flag, this record's lines and amounts would be blanked. Read the record back afterwards the first time you use it.

Amend a named, fixed set of fields on one bill payment, leaving every other field exactly as it was. This is a SPARSE update: QuickBooks applies only the fields present in the request. The full-object update — which replaces the record and blanks every field the caller omitted — is a SEPARATE action (quickbooks_replace_bill_payment), under a separate scope, flagged destructive, and the field list below is what keeps the two apart. Nothing here can change a document's lines, its amounts or which customer or vendor it belongs to. The record's current SyncToken is required and is not looked up automatically, so an agent must read the record immediately beforehand and cannot amend one that changed underneath it. NOTE, AND IT IS NOT BOILERPLATE: Intuit publishes a sparse update for eleven entities and a bill payment is not one of them — the only update sample Intuit ships for it sets sparse to false. Agentic Fabriq sends the flag anyway and bounds the field list, and third-party SDKs send it for every entity, but nobody has run this against a live company file. If QuickBooks were to ignore the flag, this record's lines and amounts would be blanked. Read the record back afterwards the first time you use it.

Amend a named, fixed set of fields on one class, leaving every other field exactly as it was. This is a SPARSE update: QuickBooks applies only the fields present in the request. The full-object update — which replaces the record and blanks every field the caller omitted — is not exposed, and the field list below is what keeps the two apart. Nothing here can change a document's lines, its amounts or which customer or vendor it belongs to. The record's current SyncToken is required and is not looked up automatically, so an agent must read the record immediately beforehand and cannot amend one that changed underneath it. NOTE, AND IT IS NOT BOILERPLATE: Intuit publishes a sparse update for eleven entities and a class is not one of them — the only update sample Intuit ships for it sets sparse to false. Agentic Fabriq sends the flag anyway and bounds the field list, and third-party SDKs send it for every entity, but nobody has run this against a live company file. If QuickBooks were to ignore the flag, the fields below would be all that survived on the record. Read the record back afterwards the first time you use it.

Amend a named, fixed set of fields on one company currency, leaving every other field exactly as it was. This is a SPARSE update: QuickBooks applies only the fields present in the request. The full-object update — which replaces the record and blanks every field the caller omitted — is not exposed, and the field list below is what keeps the two apart. Nothing here can change a document's lines, its amounts or which customer or vendor it belongs to. The record's current SyncToken is required and is not looked up automatically, so an agent must read the record immediately beforehand and cannot amend one that changed underneath it. NOTE, AND IT IS NOT BOILERPLATE: Intuit publishes a sparse update for eleven entities and a company currency is not one of them — the only update sample Intuit ships for it sets sparse to false. Agentic Fabriq sends the flag anyway and bounds the field list, and third-party SDKs send it for every entity, but nobody has run this against a live company file. If QuickBooks were to ignore the flag, the fields below would be all that survived on the record. Read the record back afterwards the first time you use it.

DESTRUCTIVE — amend the company's own identity record: its trading name, contact email, phone and web address. These are the fields printed on every document a customer or supplier receives, so a wrong value here is visible outside the company before anybody notices. Sent as a SPARSE update, so fields not named survive. The accounting settings that live on the same record — above all FiscalYearStartMonth, and the company's country and legal name — are NOT settable through Agentic Fabriq: changing the fiscal year start redefines every reporting period the company has ever run, retroactively, and that is a decision with no document to point at afterwards. Requires the record's current SyncToken from quickbooks_get_company_info, and confirm=true.

Amend a named, fixed set of fields on one credit memo, leaving every other field exactly as it was. This is a SPARSE update: QuickBooks applies only the fields present in the request. The full-object update — which replaces the record and blanks every field the caller omitted — is a SEPARATE action (quickbooks_replace_credit_memo), under a separate scope, flagged destructive, and the field list below is what keeps the two apart. Nothing here can change a document's lines, its amounts or which customer or vendor it belongs to. The record's current SyncToken is required and is not looked up automatically, so an agent must read the record immediately beforehand and cannot amend one that changed underneath it. NOTE, AND IT IS NOT BOILERPLATE: Intuit publishes a sparse update for eleven entities and a credit memo is not one of them — the only update sample Intuit ships for it sets sparse to false. Agentic Fabriq sends the flag anyway and bounds the field list, and third-party SDKs send it for every entity, but nobody has run this against a live company file. If QuickBooks were to ignore the flag, this record's lines and amounts would be blanked. Read the record back afterwards the first time you use it.

Amend a named, fixed set of fields on one customer, leaving every other field exactly as it was. This is a SPARSE update: QuickBooks applies only the fields present in the request. The full-object update — which replaces the record and blanks every field the caller omitted — is not exposed, and the field list below is what keeps the two apart. Nothing here can change a document's lines, its amounts or which customer or vendor it belongs to. The record's current SyncToken is required and is not looked up automatically, so an agent must read the record immediately beforehand and cannot amend one that changed underneath it.

Amend a named, fixed set of fields on one department, leaving every other field exactly as it was. This is a SPARSE update: QuickBooks applies only the fields present in the request. The full-object update — which replaces the record and blanks every field the caller omitted — is not exposed, and the field list below is what keeps the two apart. Nothing here can change a document's lines, its amounts or which customer or vendor it belongs to. The record's current SyncToken is required and is not looked up automatically, so an agent must read the record immediately beforehand and cannot amend one that changed underneath it. NOTE, AND IT IS NOT BOILERPLATE: Intuit publishes a sparse update for eleven entities and a department is not one of them — the only update sample Intuit ships for it sets sparse to false. Agentic Fabriq sends the flag anyway and bounds the field list, and third-party SDKs send it for every entity, but nobody has run this against a live company file. If QuickBooks were to ignore the flag, the fields below would be all that survived on the record. Read the record back afterwards the first time you use it.

Amend a named, fixed set of fields on one deposit, leaving every other field exactly as it was. This is a SPARSE update: QuickBooks applies only the fields present in the request. The full-object update — which replaces the record and blanks every field the caller omitted — is a SEPARATE action (quickbooks_replace_deposit), under a separate scope, flagged destructive, and the field list below is what keeps the two apart. Nothing here can change a document's lines, its amounts or which customer or vendor it belongs to. The record's current SyncToken is required and is not looked up automatically, so an agent must read the record immediately beforehand and cannot amend one that changed underneath it.

Amend a named, fixed set of fields on one employee, leaving every other field exactly as it was. This is a SPARSE update: QuickBooks applies only the fields present in the request. The full-object update — which replaces the record and blanks every field the caller omitted — is not exposed, and the field list below is what keeps the two apart. Nothing here can change a document's lines, its amounts or which customer or vendor it belongs to. The record's current SyncToken is required and is not looked up automatically, so an agent must read the record immediately beforehand and cannot amend one that changed underneath it. NOTE, AND IT IS NOT BOILERPLATE: Intuit publishes a sparse update for eleven entities and a employee is not one of them — the only update sample Intuit ships for it sets sparse to false. Agentic Fabriq sends the flag anyway and bounds the field list, and third-party SDKs send it for every entity, but nobody has run this against a live company file. If QuickBooks were to ignore the flag, the fields below would be all that survived on the record. Read the record back afterwards the first time you use it.

Amend a named, fixed set of fields on one estimate, leaving every other field exactly as it was. This is a SPARSE update: QuickBooks applies only the fields present in the request. The full-object update — which replaces the record and blanks every field the caller omitted — is a SEPARATE action (quickbooks_replace_estimate), under a separate scope, flagged destructive, and the field list below is what keeps the two apart. Nothing here can change a document's lines, its amounts or which customer or vendor it belongs to. The record's current SyncToken is required and is not looked up automatically, so an agent must read the record immediately beforehand and cannot amend one that changed underneath it.

DESTRUCTIVE — set the exchange rate between the company's home currency and one foreign currency, for one date. Every open balance in that currency on that date is re-valued by this, retroactively, and there is no document in the register to point at afterwards — which is why it is flagged destructive and requires confirm=true. Read the current rate with quickbooks_list_exchange_rates first: QuickBooks publishes no read-by-id for an exchange rate, so the list filtered to the currency is the only way to see what you are about to change. NOTE: the request shape below is built from Intuit's published sample and has not been run against a live company file.

Amend a named, fixed set of fields on one inventory adjustment, leaving every other field exactly as it was. This is a SPARSE update: QuickBooks applies only the fields present in the request. The full-object update — which replaces the record and blanks every field the caller omitted — is not exposed, and the field list below is what keeps the two apart. Nothing here can change a document's lines, its amounts or which customer or vendor it belongs to. The record's current SyncToken is required and is not looked up automatically, so an agent must read the record immediately beforehand and cannot amend one that changed underneath it.

Amend a named, fixed set of fields on one invoice, leaving every other field exactly as it was. This is a SPARSE update: QuickBooks applies only the fields present in the request. The full-object update — which replaces the record and blanks every field the caller omitted — is a SEPARATE action (quickbooks_replace_invoice), under a separate scope, flagged destructive, and the field list below is what keeps the two apart. Nothing here can change a document's lines, its amounts or which customer or vendor it belongs to. The record's current SyncToken is required and is not looked up automatically, so an agent must read the record immediately beforehand and cannot amend one that changed underneath it.

Amend a named, fixed set of fields on one product or service, leaving every other field exactly as it was. This is a SPARSE update: QuickBooks applies only the fields present in the request. The full-object update — which replaces the record and blanks every field the caller omitted — is not exposed, and the field list below is what keeps the two apart. Nothing here can change a document's lines, its amounts or which customer or vendor it belongs to. The record's current SyncToken is required and is not looked up automatically, so an agent must read the record immediately beforehand and cannot amend one that changed underneath it. NOTE, AND IT IS NOT BOILERPLATE: Intuit publishes a sparse update for eleven entities and a product or service is not one of them — the only update sample Intuit ships for it sets sparse to false. Agentic Fabriq sends the flag anyway and bounds the field list, and third-party SDKs send it for every entity, but nobody has run this against a live company file. If QuickBooks were to ignore the flag, the fields below would be all that survived on the record. Read the record back afterwards the first time you use it.

Amend a named, fixed set of fields on one journal code, leaving every other field exactly as it was. This is a SPARSE update: QuickBooks applies only the fields present in the request. The full-object update — which replaces the record and blanks every field the caller omitted — is not exposed, and the field list below is what keeps the two apart. Nothing here can change a document's lines, its amounts or which customer or vendor it belongs to. The record's current SyncToken is required and is not looked up automatically, so an agent must read the record immediately beforehand and cannot amend one that changed underneath it. NOTE, AND IT IS NOT BOILERPLATE: Intuit publishes a sparse update for eleven entities and a journal code is not one of them — the only update sample Intuit ships for it sets sparse to false. Agentic Fabriq sends the flag anyway and bounds the field list, and third-party SDKs send it for every entity, but nobody has run this against a live company file. If QuickBooks were to ignore the flag, the fields below would be all that survived on the record. Read the record back afterwards the first time you use it.

Amend a named, fixed set of fields on one journal entry, leaving every other field exactly as it was. This is a SPARSE update: QuickBooks applies only the fields present in the request. The full-object update — which replaces the record and blanks every field the caller omitted — is a SEPARATE action (quickbooks_replace_journal_entry), under a separate scope, flagged destructive, and the field list below is what keeps the two apart. Nothing here can change a document's lines, its amounts or which customer or vendor it belongs to. The record's current SyncToken is required and is not looked up automatically, so an agent must read the record immediately beforehand and cannot amend one that changed underneath it.

Amend a named, fixed set of fields on one payment, leaving every other field exactly as it was. This is a SPARSE update: QuickBooks applies only the fields present in the request. The full-object update — which replaces the record and blanks every field the caller omitted — is not exposed, and the field list below is what keeps the two apart. Nothing here can change a document's lines, its amounts or which customer or vendor it belongs to. The record's current SyncToken is required and is not looked up automatically, so an agent must read the record immediately beforehand and cannot amend one that changed underneath it. NOTE, AND IT IS NOT BOILERPLATE: Intuit publishes a sparse update for eleven entities and a payment is not one of them — the only update sample Intuit ships for it sets sparse to false. Agentic Fabriq sends the flag anyway and bounds the field list, and third-party SDKs send it for every entity, but nobody has run this against a live company file. If QuickBooks were to ignore the flag, the fields below would be all that survived on the record. Read the record back afterwards the first time you use it.

Amend a named, fixed set of fields on one payment method, leaving every other field exactly as it was. This is a SPARSE update: QuickBooks applies only the fields present in the request. The full-object update — which replaces the record and blanks every field the caller omitted — is not exposed, and the field list below is what keeps the two apart. Nothing here can change a document's lines, its amounts or which customer or vendor it belongs to. The record's current SyncToken is required and is not looked up automatically, so an agent must read the record immediately beforehand and cannot amend one that changed underneath it. NOTE, AND IT IS NOT BOILERPLATE: Intuit publishes a sparse update for eleven entities and a payment method is not one of them — the only update sample Intuit ships for it sets sparse to false. Agentic Fabriq sends the flag anyway and bounds the field list, and third-party SDKs send it for every entity, but nobody has run this against a live company file. If QuickBooks were to ignore the flag, the fields below would be all that survived on the record. Read the record back afterwards the first time you use it.

Amend a named, fixed set of fields on one expense, leaving every other field exactly as it was. This is a SPARSE update: QuickBooks applies only the fields present in the request. The full-object update — which replaces the record and blanks every field the caller omitted — is a SEPARATE action (quickbooks_replace_purchase), under a separate scope, flagged destructive, and the field list below is what keeps the two apart. Nothing here can change a document's lines, its amounts or which customer or vendor it belongs to. The record's current SyncToken is required and is not looked up automatically, so an agent must read the record immediately beforehand and cannot amend one that changed underneath it. NOTE, AND IT IS NOT BOILERPLATE: Intuit publishes a sparse update for eleven entities and a expense is not one of them — the only update sample Intuit ships for it sets sparse to false. Agentic Fabriq sends the flag anyway and bounds the field list, and third-party SDKs send it for every entity, but nobody has run this against a live company file. If QuickBooks were to ignore the flag, this record's lines and amounts would be blanked. Read the record back afterwards the first time you use it.

Amend a named, fixed set of fields on one purchase order, leaving every other field exactly as it was. This is a SPARSE update: QuickBooks applies only the fields present in the request. The full-object update — which replaces the record and blanks every field the caller omitted — is a SEPARATE action (quickbooks_replace_purchase_order), under a separate scope, flagged destructive, and the field list below is what keeps the two apart. Nothing here can change a document's lines, its amounts or which customer or vendor it belongs to. The record's current SyncToken is required and is not looked up automatically, so an agent must read the record immediately beforehand and cannot amend one that changed underneath it. NOTE, AND IT IS NOT BOILERPLATE: Intuit publishes a sparse update for eleven entities and a purchase order is not one of them — the only update sample Intuit ships for it sets sparse to false. Agentic Fabriq sends the flag anyway and bounds the field list, and third-party SDKs send it for every entity, but nobody has run this against a live company file. If QuickBooks were to ignore the flag, this record's lines and amounts would be blanked. Read the record back afterwards the first time you use it.

Amend a named, fixed set of fields on one refund receipt, leaving every other field exactly as it was. This is a SPARSE update: QuickBooks applies only the fields present in the request. The full-object update — which replaces the record and blanks every field the caller omitted — is a SEPARATE action (quickbooks_replace_refund_receipt), under a separate scope, flagged destructive, and the field list below is what keeps the two apart. Nothing here can change a document's lines, its amounts or which customer or vendor it belongs to. The record's current SyncToken is required and is not looked up automatically, so an agent must read the record immediately beforehand and cannot amend one that changed underneath it.

Amend a named, fixed set of fields on one sales receipt, leaving every other field exactly as it was. This is a SPARSE update: QuickBooks applies only the fields present in the request. The full-object update — which replaces the record and blanks every field the caller omitted — is a SEPARATE action (quickbooks_replace_sales_receipt), under a separate scope, flagged destructive, and the field list below is what keeps the two apart. Nothing here can change a document's lines, its amounts or which customer or vendor it belongs to. The record's current SyncToken is required and is not looked up automatically, so an agent must read the record immediately beforehand and cannot amend one that changed underneath it.

Amend a named, fixed set of fields on one payment term, leaving every other field exactly as it was. This is a SPARSE update: QuickBooks applies only the fields present in the request. The full-object update — which replaces the record and blanks every field the caller omitted — is not exposed, and the field list below is what keeps the two apart. Nothing here can change a document's lines, its amounts or which customer or vendor it belongs to. The record's current SyncToken is required and is not looked up automatically, so an agent must read the record immediately beforehand and cannot amend one that changed underneath it. NOTE, AND IT IS NOT BOILERPLATE: Intuit publishes a sparse update for eleven entities and a payment term is not one of them — the only update sample Intuit ships for it sets sparse to false. Agentic Fabriq sends the flag anyway and bounds the field list, and third-party SDKs send it for every entity, but nobody has run this against a live company file. If QuickBooks were to ignore the flag, the fields below would be all that survived on the record. Read the record back afterwards the first time you use it.

Amend a named, fixed set of fields on one time activity, leaving every other field exactly as it was. This is a SPARSE update: QuickBooks applies only the fields present in the request. The full-object update — which replaces the record and blanks every field the caller omitted — is not exposed, and the field list below is what keeps the two apart. Nothing here can change a document's lines, its amounts or which customer or vendor it belongs to. The record's current SyncToken is required and is not looked up automatically, so an agent must read the record immediately beforehand and cannot amend one that changed underneath it. NOTE, AND IT IS NOT BOILERPLATE: Intuit publishes a sparse update for eleven entities and a time activity is not one of them — the only update sample Intuit ships for it sets sparse to false. Agentic Fabriq sends the flag anyway and bounds the field list, and third-party SDKs send it for every entity, but nobody has run this against a live company file. If QuickBooks were to ignore the flag, the fields below would be all that survived on the record. Read the record back afterwards the first time you use it.

Amend a named, fixed set of fields on one transfer, leaving every other field exactly as it was. This is a SPARSE update: QuickBooks applies only the fields present in the request. The full-object update — which replaces the record and blanks every field the caller omitted — is not exposed, and the field list below is what keeps the two apart. Nothing here can change a document's lines, its amounts or which customer or vendor it belongs to. The record's current SyncToken is required and is not looked up automatically, so an agent must read the record immediately beforehand and cannot amend one that changed underneath it.

Amend a named, fixed set of fields on one vendor, leaving every other field exactly as it was. This is a SPARSE update: QuickBooks applies only the fields present in the request. The full-object update — which replaces the record and blanks every field the caller omitted — is not exposed, and the field list below is what keeps the two apart. Nothing here can change a document's lines, its amounts or which customer or vendor it belongs to. The record's current SyncToken is required and is not looked up automatically, so an agent must read the record immediately beforehand and cannot amend one that changed underneath it. NOTE, AND IT IS NOT BOILERPLATE: Intuit publishes a sparse update for eleven entities and a vendor is not one of them — the only update sample Intuit ships for it sets sparse to false. Agentic Fabriq sends the flag anyway and bounds the field list, and third-party SDKs send it for every entity, but nobody has run this against a live company file. If QuickBooks were to ignore the flag, the fields below would be all that survived on the record. Read the record back afterwards the first time you use it.

Amend a named, fixed set of fields on one vendor credit, leaving every other field exactly as it was. This is a SPARSE update: QuickBooks applies only the fields present in the request. The full-object update — which replaces the record and blanks every field the caller omitted — is a SEPARATE action (quickbooks_replace_vendor_credit), under a separate scope, flagged destructive, and the field list below is what keeps the two apart. Nothing here can change a document's lines, its amounts or which customer or vendor it belongs to. The record's current SyncToken is required and is not looked up automatically, so an agent must read the record immediately beforehand and cannot amend one that changed underneath it. NOTE, AND IT IS NOT BOILERPLATE: Intuit publishes a sparse update for eleven entities and a vendor credit is not one of them — the only update sample Intuit ships for it sets sparse to false. Agentic Fabriq sends the flag anyway and bounds the field list, and third-party SDKs send it for every entity, but nobody has run this against a live company file. If QuickBooks were to ignore the flag, this record's lines and amounts would be blanked. Read the record back afterwards the first time you use it.

Attach one base64-encoded file to a QuickBooks record — a receipt behind an expense, a signed purchase order. Creates an Attachable, which quickbooks_delete_attachable can remove, so the loss is bounded. Size and MIME type are both capped; a file outside either is refused before anything leaves Agentic Fabriq.

DESTRUCTIVE — void one bill payment. There is no undo. A voided record keeps its number and stays in the books forever at zero, and its original amounts and lines are gone; restoring it means re-entering it by hand. Voiding is the AUDITABLE alternative to deleting: the document survives in the register where a deletion would leave a gap nobody can detect. The record's current SyncToken is required and is not looked up automatically, so an agent must read it immediately beforehand and cannot void a record that changed underneath it. Sent as `operation=update&include=void`.

DESTRUCTIVE — void one invoice. There is no undo. A voided record keeps its number and stays in the books forever at zero, and its original amounts and lines are gone; restoring it means re-entering it by hand. Voiding is the AUDITABLE alternative to deleting: the document survives in the register where a deletion would leave a gap nobody can detect. The record's current SyncToken is required and is not looked up automatically, so an agent must read it immediately beforehand and cannot void a record that changed underneath it. Sent as `operation=void`.

DESTRUCTIVE — void one payment. There is no undo. A voided record keeps its number and stays in the books forever at zero, and its original amounts and lines are gone; restoring it means re-entering it by hand. Voiding is the AUDITABLE alternative to deleting: the document survives in the register where a deletion would leave a gap nobody can detect. The record's current SyncToken is required and is not looked up automatically, so an agent must read it immediately beforehand and cannot void a record that changed underneath it. Sent as `operation=update&include=void`.

DESTRUCTIVE — void one sales receipt. There is no undo. A voided record keeps its number and stays in the books forever at zero, and its original amounts and lines are gone; restoring it means re-entering it by hand. Voiding is the AUDITABLE alternative to deleting: the document survives in the register where a deletion would leave a gap nobody can detect. The record's current SyncToken is required and is not looked up automatically, so an agent must read it immediately beforehand and cannot void a record that changed underneath it. Sent as `operation=void`.