QuickBooks Desktop API
Welcome to Conductor's new QuickBooks Desktop API (alpha)
Conductor’s new QuickBooks Desktop API is a massive leap forward and sets the foundation for future integrations.
This new API is neither stable nor ready for use. We are iterating rapidly. Expect changes to the API and documentation every single day.
Welcome to Conductor’s new QuickBooks Desktop API. It brings the following improvements over the current generation:
- Proper HTTP methods:
GET
for reading,POST
for creating or updating. No morePOST
for everything. - Cleaner URL endpoints:
/quickbooks_desktop/invoices
instead of/end-users/{id}/request/quickbooks_desktop
withInvoiceQueryRq
in the body. - An OpenAPI spec for the entire API.
- Full online documentation of all fields and their types.
- API playground in the documentation to test requests and see responses.
- Always returns all response fields. Uses
null
for undefined fields instead of omitting them. - Consistently returns arrays for any nested fields that previously returned a single object for one item and an array for multiple items.
- Returns an empty array instead of
null
for empty lists.
- Returns an empty array instead of
- Clean response bodies: No more unwrapping outer objects; e.g., no more
InvoiceQueryRs.InvoiceRet
. - Proper object wrapper for all list responses: Previously, we returned an array of objects. Now, we return an object with a
data
field that contains the array of objects. - Pagination for all list endpoints.
- Better parameter names instead of QuickBooks Desktop’s unconventional naming. For example:
MaxReturned
→limit
TimeModified
→updatedAt
DataExtRet
→customFields
- Uses
camelCase
for input and output field names instead ofPascalCase
. - Simplified request structure. For example:
refNumberStartsWith: "REF"
instead ofRefNumberFilter: { MatchCriterion: "StartsWith", RefNumber: "REF" }
accountId: "123"
instead ofAccountRef: { ListID: "123" }
- Correct types for obscure fields: Previously, we inferred types from XML. Now, we define the type of every field to ensure it is always correct.
- Better field descriptions: we are using our own descriptions instead of QuickBooks’ descriptions.
- Field-specific coercions: better handling of dates and money amounts.
- Enforced upper bound on
limit
of 1000 items to prevent overloading QuickBooks Desktop instances. - Better defaults. For example:
includeLineItems
istrue
by default because who wants an empty invoice?ownerId
is 0 by default to always include your end-users’ custom fields.
Feedback
We value your input! If you have suggestions or requests for improvements, changes, field names, documentation, or anything else, please let us know.