QuickBooks
The QuickBooks Online connector exposes the largest tool family on the platform — 96 tool types covering the full accounting surface (customers, invoices, bills, items, accounts, reports), the QuickBooks Payments API for real card and eCheck processing, and a set of composite workflow tools that collapse common multi-step sequences into a single agent call.
Connector setup
Every QuickBooks tool takes a connectorId — the ID of a QuickBooks connector your company has authorized. Connectors are created from the connectors page via Intuit's OAuth flow: you pick the QuickBooks company (realm) to link, grant access, and Autessa stores and refreshes the tokens for you. Tool executions never see credentials; they reference the connector by ID and the platform signs each API call.
One connector maps to one QuickBooks company. If your organization runs several QuickBooks companies, create one connector per company and point each tool config at the right connectorId.
See Connectors for the general connector lifecycle.
Sandbox vs production
A QuickBooks connector is flagged as sandbox or production when it is authorized, based on the Intuit company you connect. The flag switches every call the connector makes:
- Accounting API —
https://quickbooks.api.intuit.comin production,https://sandbox-quickbooks.api.intuit.comfor sandbox companies. - Payments API —
https://api.intuit.com/quickbooks/v4/paymentsin production,https://sandbox.api.intuit.com/quickbooks/v4/paymentsfor sandbox.
Tool configs are identical in both modes — swap the connectorId to move an agent from a sandbox company to the live one. Build and test agents against an Intuit sandbox company first; sandbox Payments calls accept Intuit's test card and bank numbers without moving real money.
The tool families
| Subpage | What's on it | Types |
|---|---|---|
| Sales & AR | Customers, invoices, accounting-side payments, estimates | 19 |
| Purchasing & AP | Vendors, bills, bill payments, purchase orders | 15 |
| Items, Accounts & Company | Products/services, chart of accounts, company info, preferences | 9 |
| Reports | P&L, balance sheet, cash flow, aging, balances, transaction list | 8 |
| Payments | Payments API: tokenize, charge, refund cards and eChecks, plus payment-method composites | 16 |
| Workflows | Composite tools: create-and-send, search, get-or-create, summaries, PDF and attachment operations | 29 |
Composite workflow tools
Most tool types map one-to-one onto a QuickBooks API operation. The composite types on the Workflows and Payments pages instead chain several operations behind a single tool call — QUICKBOOKS_CREATE_AND_SEND_INVOICE creates the invoice and emails it, QUICKBOOKS_GET_OR_CREATE_CUSTOMER searches by email and only creates on a miss, QUICKBOOKS_CHARGE_AND_RECORD_PAYMENT charges a card and books the accounting entry.
Composites exist because each step an agent has to plan itself is a chance to mis-sequence it. Prefer a composite when one matches the task; reach for the granular types when the agent needs control between steps.
Accounting records vs the Payments API
Two very different things both get called "payments":
- Accounting-side payment records (
QUICKBOOKS_CREATE_PAYMENT,QUICKBOOKS_CREATE_BILL_PAYMENT, on the Sales & AR and Purchasing & AP pages) record that money moved — they update ledgers and invoice balances but move no funds. - The Payments family drives the QuickBooks Payments API, which actually processes card charges and ACH eChecks. It requires a QuickBooks Payments merchant account on the connected company, and its operations move real money in production.
The *_AND_RECORD_* composites bridge the two: process the money movement, then write the matching accounting record in one call.