> ## Documentation Index > Fetch the complete documentation index at: https://docs.qubesync.com/llms.txt > Use this file to discover all available pages before exploring further. # Queue a qbXML request > Usually, you'll want to use the pre-built operation endpoints, but if you really need qbXML we have you covered. Rules for raw qbXML 1. It has no DOCTYPE: qbXML doesn't use one. 2. It declares its qbXML version, such as ``, and the version is 13.0, 14.0, 15.0 or 16.0. 3. It is valid against that version's qbXML schema. 4. `` holds only ``, with at least one request inside it. 5. In a batch (two or more requests), no request has an `iterator` attribute: queue an iterator query on its own. 6. `onError` is `stopOnError` or `continueOnError`. QuickBooks Desktop refuses `rollbackOnError` for the whole envelope. A single request request answers exactly as an operation does: `response_json` is the same `{status, data}` summary, and a request QuickBooks refuses ends `error`. An iterator query (`iterator="Start"` with `MaxReturned`), alone in its envelope, is paged as usual, one webhook per page. Unlike the operation endpoints, this one doesn't page a list query for you: one sent with neither answers every match at once, and the `201`'s `warnings` says so. A batch's (multiple requests inside one QBXMLMsgsRq envelope) `response_json` is `{status, responses}`: one entry per request, in the order they were sent, with `request` (the request's name), `request_id` (its `requestID`, or `null`) and `status`. An answered entry is `success` or `error`, with the `data`, `message`, `warning` or `error` one request's summary has. `not_processed` is a request QuickBooks skipped: with `onError="stopOnError"` QuickBooks stops at the first request that fails and answers every request after it "The request has not been processed." (status 3231), so each of those is `not_processed`, while `continueOnError` carries on and runs each one. A 3231 that isn't after an earlier failure is QuickBooks declining that request itself (its edition or preferences don't allow it), so it's an `error`. The top-level `status` is `success` only when every entry is. A batch QuickBooks answered is `response_received`, whatever its entries say: some of its requests may have been carried out. Read the entries to see which, and don't resend the whole batch. ## OpenAPI ````yaml /api-reference/v2/openapi.json post /connections/{connection_id}/queued-requests openapi: 3.1.0 info: contact: email: support@qubesync.com description: > A single generic operation surface for every curated qbXML request QuBe Sync supports, driven directly off the qbXML schema -- see the [MCP server](/mcp-server) to explore available operations interactively. **Every endpoint queues a request and returns it immediately (`201`, a `QueuedRequest`).** QuickBooks Desktop is reached through the customer's Web Connector, which polls QuBe Sync, so the answer arrives seconds to minutes later. **Pass a `webhook_url` with every request**: when QuickBooks has answered, QuBe Sync POSTs the same document to it -- `state` set, `response_json` filled in -- signed with `X-QUBE-Signature` (see the Webhooks guide). `response_json` is the `{status, data}` envelope documented on each operation: `status: "success"` with `data` derived from the qbXML `*Ret` (and `warning`, QuickBooks' code and message, when it carried the request out but warned about it), or `status: "error"` with QuickBooks' own status code and message -- a QuickBooks business error is a *successful* HTTP round trip. `links.self` returns the request on demand (for a dashboard, a retry, a script); it is not the integration path. Send an `Idempotency-Key` header with each request so a call whose answer you never got can be sent again without queueing it twice. Authentication is HTTP Basic with your app's API key as the username and a blank password. Connections themselves (creating one, onboarding, its QWC file and password) are the `/connections` endpoints; every QuickBooks operation is scoped to one of them. title: QuBe Sync API (v2) version: 2.0.0 servers: - description: v2 API url: https://qubesync.com/api/v2 - description: Local development server url: https://dev.qubesync.com/api/v2 security: - apiKey: [] tags: - description: >- Creating and managing the connection (a customer's QuickBooks company file) that every request below is queued against. See the Onboarding guide. name: Connections - description: >- Queueing qbXML you wrote yourself, listing the requests queued on a connection, and discarding one the app no longer wants. A `webhook_url` on each request is the integration path (see the Webhooks guide): the listing is for a dashboard, a script, or catching up after downtime. name: Queued Requests - description: >- Finding the record in a customer's company file that a name means, even written differently: ranked matches from QuBe Sync's index of the file's names, on realtime and simulated connections. See the Matching guide. name: Matching - description: >- Endpoints for publishing workflow definitions, starting runs, and answering a run that is waiting on a decision from your app. A workflow is one JSON statechart document; see the schema at /api/v2/workflows/schema.json. name: Workflows - name: Account Tax Line Infos - name: Accounts - name: Aging Reports - name: Alerts - name: Ar Refund Credit Cards - name: Bar Codes - name: Bill Payment Checks - name: Bill Payment Credit Cards - name: Bill To Pays - name: Billing Rates - name: Bills - name: Budget Summary Reports - name: Build Assemblies - name: Charges - name: Checks - name: Classes - name: Cleared Statuses - name: Companies - name: Company Activities - name: Credit Card Charges - name: Credit Card Credits - name: Credit Memos - name: Currencies - name: Custom Detail Reports - name: Custom Summary Reports - name: Customer Msgs - name: Customer Types - name: Customers - name: Data Event Recovery Infos - name: Data Ext Defs - name: Data Exts - name: Date Driven Terms - name: Deposits - name: Employee Defaults - name: Employees - name: Entities - name: Estimates - name: Form1099 Category Account Mappings - name: General Detail Reports - name: General Summary Reports - name: Hosts - name: Inventory Adjustments - name: Inventory Sites - name: Invoices - name: Item Assemblies Can Builds - name: Item Discounts - name: Item Fixed Assets - name: Item Groups - name: Item Inventories - name: Item Inventory Assemblies - name: Item Non Inventories - name: Item Other Charges - name: Item Payments - name: Item Receipts - name: Item Sales Tax Groups - name: Item Sales Taxes - name: Item Services - name: Item Sites - name: Item Subtotals - name: Items - name: Job Reports - name: Job Types - name: Journal Entries - name: Leads - name: List Deleteds - name: List Displays - name: List Merge - name: Lists - name: Other Names - name: Paychecks - name: Payment Methods - name: Payments - name: Payroll Detail Reports - name: Payroll Item Additions - name: Payroll Item Company Contributions - name: Payroll Item Deductions - name: Payroll Item Direct Deposits - name: Payroll Item Non Wages - name: Payroll Item Taxes - name: Payroll Item Wages - name: Payroll Item Workers Compensations - name: Payroll Items - name: Payroll Last Periods - name: Payroll Liability Adjustments - name: Payroll Liability Checks - name: Payroll Prior Payments - name: Payroll Summary Reports - name: Payroll Year To Date Adjustments - name: Preferences - name: Price Levels - name: Purchase Orders - name: Qb Command Exec - name: Receive Payment To Deposits - name: Receive Payments - name: Sales Orders - name: Sales Receipts - name: Sales Reps - name: Sales Tax Codes - name: Sales Tax Payables - name: Sales Tax Payment Checks - name: Sales Tax Return Lines - name: Sales Tax Returns - name: Ship Methods - name: Special Accounts - name: Special Items - name: Standard Terms - name: Templates - name: Terms - name: Time Reports - name: Time Trackings - name: To Dos - name: Transactions - name: Transfer Inventories - name: Transfers - name: Txn Deleteds - name: Txn Displays - name: Txn Void - name: Txns - name: Unit Of Measure Sets - name: Vehicle Mileages - name: Vehicles - name: Vendor Credits - name: Vendor Types - name: Vendors - name: Workers Comp Codes paths: /connections/{connection_id}/queued-requests: post: tags: - Queued Requests summary: Queue a qbXML request description: >- Usually, you'll want to use the pre-built operation endpoints, but if you really need qbXML we have you covered. Rules for raw qbXML 1. It has no DOCTYPE: qbXML doesn't use one. 2. It declares its qbXML version, such as ``, and the version is 13.0, 14.0, 15.0 or 16.0. 3. It is valid against that version's qbXML schema. 4. `` holds only ``, with at least one request inside it. 5. In a batch (two or more requests), no request has an `iterator` attribute: queue an iterator query on its own. 6. `onError` is `stopOnError` or `continueOnError`. QuickBooks Desktop refuses `rollbackOnError` for the whole envelope. A single request request answers exactly as an operation does: `response_json` is the same `{status, data}` summary, and a request QuickBooks refuses ends `error`. An iterator query (`iterator="Start"` with `MaxReturned`), alone in its envelope, is paged as usual, one webhook per page. Unlike the operation endpoints, this one doesn't page a list query for you: one sent with neither answers every match at once, and the `201`'s `warnings` says so. A batch's (multiple requests inside one QBXMLMsgsRq envelope) `response_json` is `{status, responses}`: one entry per request, in the order they were sent, with `request` (the request's name), `request_id` (its `requestID`, or `null`) and `status`. An answered entry is `success` or `error`, with the `data`, `message`, `warning` or `error` one request's summary has. `not_processed` is a request QuickBooks skipped: with `onError="stopOnError"` QuickBooks stops at the first request that fails and answers every request after it "The request has not been processed." (status 3231), so each of those is `not_processed`, while `continueOnError` carries on and runs each one. A 3231 that isn't after an earlier failure is QuickBooks declining that request itself (its edition or preferences don't allow it), so it's an `error`. The top-level `status` is `success` only when every entry is. A batch QuickBooks answered is `response_received`, whatever its entries say: some of its requests may have been carried out. Read the entries to see which, and don't resend the whole batch. operationId: createQueuedRequest parameters: - description: >- The connection (a customer's QuickBooks company file) this request is queued for. in: path name: connection_id required: true schema: format: uuid type: string - description: >- Where QuBe Sync POSTs the answered request (this same document with `response_json` filled in), signed with `X-QUBE-Signature`. Send one with every request: it is how answers are delivered. Optional only so a script can queue and look up `links.self` by hand. It must be an absolute http or https URL. It may not contain a username or password, and in production it may not point at localhost or a private, loopback or link-local address. A `qube listen` URL must be one of this app's. in: query name: webhook_url required: false schema: format: uri maxLength: 2048 type: string - $ref: '#/components/parameters/IdempotencyKey' requestBody: content: application/json: example: request_xml: |- 10 schema: additionalProperties: false properties: request_xml: description: >- The whole qbXML document: the `` declaration, then ``, then `` holding one request, or several to run as a batch. Sent to QuickBooks as it is, except that a character above ASCII goes as a character reference (`é` as `é`): QuickBooks fails the whole document on `é`, `–` or `’` written as itself. type: string required: - request_xml type: object required: true responses: '201': content: application/json: schema: properties: data: allOf: - $ref: '#/components/schemas/QueuedRequest' - properties: response_json: anyOf: - $ref: '#/components/schemas/RawQBXMLResponseJSON' - type: 'null' description: '`null` until answered.' type: object warnings: description: >- What QuBe Sync noticed about the qbXML as written, which it queued anyway; empty when there's nothing to say. These are in this response only: they aren't stored, and `links.self` doesn't return them. `unpaged_query` is a list query QuickBooks pages (customers, invoices and the other lists and transactions) sent with neither an `iterator` attribute nor `MaxReturned`, and not looking records up by id or name: QuickBooks answers it with every match at once. The operation endpoints page such a query by default; qbXML queued here is sent as written. items: properties: code: enum: - unpaged_query type: string message: description: >- What it found and how to page it, naming the request. type: string required: - code - message type: object type: array required: - data - warnings type: object description: >- Queued for the connection's Web Connector. Pass `webhook_url` and QuBe Sync POSTs the answer to it once QuickBooks has answered (see the `answered` callback: its own payload, not this document). `links.self` returns this document on demand, with `response_json` filled in. headers: Idempotent-Replayed: $ref: '#/components/headers/IdempotentReplayed' location: description: >- The queued request's path. `links.self` is the same request as a full URL. schema: type: string '400': content: application/json: example: errors: 'unknown parameter: "request_json"' schema: $ref: '#/components/schemas/Error' description: >- A parameter this endpoint does not take: anything but `request_xml` and `webhook_url`. Nothing was queued. '401': $ref: '#/components/responses/Unauthorized' '403': $ref: '#/components/responses/SandboxPaused' '404': $ref: '#/components/responses/NotFound' '422': content: application/json: example: errors: request_xml: - >- CustomerQueryRq has an iterator: queue an iterator query on its own, not in a batch schema: $ref: '#/components/schemas/Error' description: >- `request_xml` or `webhook_url` failed validation, field by field, and nothing was queued: a `request_xml` that is missing or breaks one of the rules above, or a `webhook_url` that is not an absolute http or https URL, carries a username or password, is longer than 2048 characters, or (in production) points at localhost or a private address. An `Idempotency-Key` that isn't 1 to 255 printable ASCII characters, or that was already used for a different request, is refused in a sentence naming the header. callbacks: answered: '{$request.query.webhook_url}': post: description: > Verify `X-QUBE-Signature`, answer 2xx within 5 seconds, then branch on `state`: * `response_received` -- QuickBooks accepted it: `response_json` is `status: "success"` with `data`, or, when there is nothing to show, QuickBooks' `message` (a query that matched nothing is a success, not an error). When QuickBooks carried it out but warned about something, `response_json.warning` has its `code` and `message`: `530`, for one, means a field you sent is not supported by the customer's QuickBooks and was not saved. * `error` -- it is over, and QuBe Sync won't try again. With `error.error_type` `quickbooks_business_error`, QuickBooks refused the request: `response_json` is `status: "error"`, and `response_json.error.code` is the status code to branch on. A `3200` (`stale_edit_sequence`: the record changed after you read it) usually comes with the record as it stands in `response_json.error.current`, its current `edit_sequence` included. Compare it with what you read first: when nobody else changed a field your update sets, re-apply your change and send it again with that `edit_sequence`; when someone did, ask your user which value wins rather than overwriting theirs (without `current`, query the record first). Otherwise QuickBooks never answered it: `xml_error` (the request itself was rejected, and will be again as sent), `outcome_unknown` (a write the Web Connector answered with an error in place of QuickBooks' answer: it may have been applied, so look in QuickBooks before sending it again) or `unexpected_error` (the Web Connector's log says more; a query can be sent again). A connection problem never ends here; it is `retryable`, below. * `retryable` -- the Web Connector could not get it into QuickBooks (QuickBooks was not running, the company file was not open or not this connection's, or a window in QuickBooks was in the way), so nothing was applied. QuBe Sync keeps trying on the Web Connector's runs, so don't resend: show the customer `error.user_message` so they can fix it. This webhook comes when the error first appears or changes, not on every try. If you no longer want the request, discard it (`POST /connections/{connection_id}/queued-requests/{id}/discard`). * `timed_out` -- no answer came back: the customer's computer lost its connection, or QuickBooks or the Web Connector was closed, while QuickBooks had the request. QuickBooks may still have applied it, so look before sending it again. `error.error_type` is `timed_out`. * `discarded` -- your app discarded it before the Web Connector picked it up. QuickBooks never got it, so nothing was applied. `error.error_type` is `discarded`, unless it was `retryable` when you discarded it: then `error` is still the connection error that held it up. An iterated query sends one webhook per page, all with the same `id` and each with its own `page_request_id` and `page`; `iteration_state` is `done` on the last page, which can arrive before earlier ones, so the import is complete once every page from 1 to the `done` page's `page` has been handled. Deliveries can arrive out of order and, after a retry, more than once: key on `page_request_id` plus `state`. A `retryable` webhook is not final: the answer that follows carries the same `id` and `page_request_id` with a different `state`, and only a repeat of the same `state` is a duplicate. A body that would be over 1 MB comes without `response_xml`: `response_xml_omitted` is true, and `links.self` is where to GET it; `response_json` is always there. If webhooks stop arriving altogether, the Web Connector on the customer's PC has most likely stopped calling in; requests wait until it does. Intuit's guide to its errors: https://quickbooks.intuit.com/learn-support/en-us/help-article/open-programs/fix-common-web-connector-errors-quickbooks-desktop/L9slolvg0_US_en_US requestBody: content: application/json: schema: description: >- POSTed to `webhook_url` as JSON, signed with `X-QUBE-Signature` (`t=,v1=." with your app's webhook secret>`). properties: app_id: description: Your app's id. format: uuid type: string app_name: type: string error: description: >- Set when `state` is `error`, `retryable`, `timed_out` or `discarded`. `error_type` says where it failed: for a `timed_out` request it is `timed_out`, and for a `discarded` one `discarded`, unless the request was `retryable` when your app discarded it, which keeps the connection error that held it up. `user_message` is safe to show an end user; `error_code` is QuickBooks' own status code for a business error, `hresult` the Web Connector's for a connection/XML error; `debug_message` is for you. properties: debug_message: description: >- Which element of the request the value came from, when known. type: - string - 'null' error_code: description: QuickBooks' statusCode, for a business error. type: - integer - 'null' error_type: description: >- `quickbooks_business_error`: QuickBooks refused the request -- `response_json.error` has its code. `quickbooks_connection_error`: the Web Connector ran on the customer's PC but could not get the request into QuickBooks, so nothing was applied -- QuickBooks was not running, the company file was not open or not the one this connection belongs to, or a window or message box open in QuickBooks was in the way. Only the customer can fix that, and `user_message` tells them how. `xml_error`: QuickBooks could not parse the qbXML; sent again as-is, it fails again. `outcome_unknown`: a write the Web Connector answered with an error in place of QuickBooks' answer, so whether QuickBooks applied it is not known: look in QuickBooks before sending it again. `unexpected_error`: anything else; for a query, which changes nothing, sending it again is safe. `timed_out`: no answer came back -- the customer's computer lost its connection, or QuickBooks or the Web Connector was closed, while QuickBooks had the request. QuickBooks may still have applied it, so look before sending it again. `discarded`: your app discarded it before the Web Connector picked it up, so QuickBooks never got it. `response_too_large`: QuickBooks answered, but with more than QuBe Sync accepts for one answer (4 MB as the Web Connector sends it, about 3 MB of qbXML), so the answer wasn't kept and `response_json` is null. QuickBooks ran the request. Page the query (`iterator` and a smaller `max_returned`), or narrow it when QuickBooks doesn't page it; for a write, look before sending it again. Web Connector problems on the customer's PC (its password, log file, the .QWC file) never reach QuBe Sync as an error: the Web Connector just stops calling in, and requests wait. Intuit's guide for those: https://quickbooks.intuit.com/learn-support/en-us/help-article/open-programs/fix-common-web-connector-errors-quickbooks-desktop/L9slolvg0_US_en_US enum: - xml_error - quickbooks_connection_error - quickbooks_business_error - unexpected_error - response_too_large - outcome_unknown - timed_out - discarded type: string hresult: description: >- The Web Connector's HRESULT (e.g. `0x80040400`), for a connection or XML error. Informational: branch on `error_type`, not on this. type: - string - 'null' message: description: >- The raw message from QuickBooks or the Web Connector; for `timed_out` and `discarded`, which neither sent, QuBe Sync's own. type: string user_message: description: A friendly message for the end user. type: string type: - object - 'null' id: description: >- The request's id, as the 201 returned it. For an iterated query, every page carries the first page's id here. format: uuid type: string iteration_state: description: >- `continue`: more pages will follow, each its own webhook. `done`: this was the last page. `max_sandbox_iterations_reached`: a sandbox app's page limit stopped the iteration. enum: - not_applicable - continue - done - max_sandbox_iterations_reached type: string links: description: Present only with `response_xml_omitted`. properties: self: description: >- This page's request in the API, `response_xml` included. format: uri type: string type: object page: description: The page number, when iterated. type: - integer - 'null' page_request_id: description: >- This page's own id. Equal to `id` except on later pages of an iterated query. format: uuid type: string response_json: $ref: '#/components/schemas/RawQBXMLResponseJSON' response_xml: description: >- QuickBooks' raw qbXML answer. `response_json` is the same, summarized. One answer can be at most 4 MB as the Web Connector sends it, about 3 MB of qbXML; QuickBooks' answer over that isn't kept: this is null and `error.error_type` is `response_too_large`. A webhook whose body would be over 1 MB is sent without it: null, with `response_xml_omitted` true; fetch it from `links.self`. type: - string - 'null' response_xml_omitted: description: >- Present, and true, only when `response_xml` was left out to keep the body under 1 MB. `response_json` is still here; GET `links.self` for `response_xml`. type: boolean sandbox: description: Whether the app is a sandbox app. type: boolean state: description: >- `response_received`: QuickBooks accepted it; read `response_json`. `error`: it is over and QuBe Sync won't try again -- see `error`, and `response_json.error` for a QuickBooks business error; with `error_type` `outcome_unknown` a write may still have been applied, so look before sending it again. `retryable`: QuickBooks could not be reached and QuBe Sync keeps trying; show the customer `error.user_message` so they can fix it. `timed_out`: no answer came back -- the customer's computer lost its connection, or QuickBooks or the Web Connector was closed, mid-request. QuickBooks may still have applied it, so look before sending it again. `discarded`: your app discarded it before the Web Connector picked it up, so QuickBooks never got it. Both carry an `error`. enum: - response_received - error - retryable - timed_out - discarded type: string timestamp: description: Unix seconds; the same `t` the signature covers. type: integer required: - app_id - app_name - sandbox - timestamp - id - page_request_id - state - response_json - error type: object required: true responses: 2XX: description: >- Received. Anything else is retried with backoff for about 8 hours. summary: QuickBooks answered (or the request failed) method: post type: path path: '{$request.query.webhook_url}' components: parameters: IdempotencyKey: description: >- Makes a retry safe when you never got the answer to a call: a timeout, a dropped connection, a worker that crashed. Send a new key (a UUID, say) with each request you mean to make once, and the same key when you send that request again. A repeat with the key and the same method, path, query and body answers `201` with what the first call created, as it is now, marked `Idempotent-Replayed: true`, and queues nothing. The same key with a different request is a `422`. A key belongs to your app (sandbox and production apps never share one), lasts as long as what it created, and is 1 to 255 printable ASCII characters. example: 9b2f6c1e-0d4a-4f7e-8a7b-2a1c3d4e5f60 in: header name: Idempotency-Key required: false schema: maxLength: 255 minLength: 1 pattern: ^[\x20-\x7E]+$ type: string schemas: QueuedRequest: properties: error: description: >- Set when `state` is `error`, `retryable`, `timed_out` or `discarded`. `error_type` says where it failed: for a `timed_out` request it is `timed_out`, and for a `discarded` one `discarded`, unless the request was `retryable` when your app discarded it, which keeps the connection error that held it up. `user_message` is safe to show an end user; `error_code` is QuickBooks' own status code for a business error, `hresult` the Web Connector's for a connection/XML error; `debug_message` is for you. properties: debug_message: description: Which element of the request the value came from, when known. type: - string - 'null' error_code: description: QuickBooks' statusCode, for a business error. type: - integer - 'null' error_type: description: >- `quickbooks_business_error`: QuickBooks refused the request -- `response_json.error` has its code. `quickbooks_connection_error`: the Web Connector ran on the customer's PC but could not get the request into QuickBooks, so nothing was applied -- QuickBooks was not running, the company file was not open or not the one this connection belongs to, or a window or message box open in QuickBooks was in the way. Only the customer can fix that, and `user_message` tells them how. `xml_error`: QuickBooks could not parse the qbXML; sent again as-is, it fails again. `outcome_unknown`: a write the Web Connector answered with an error in place of QuickBooks' answer, so whether QuickBooks applied it is not known: look in QuickBooks before sending it again. `unexpected_error`: anything else; for a query, which changes nothing, sending it again is safe. `timed_out`: no answer came back -- the customer's computer lost its connection, or QuickBooks or the Web Connector was closed, while QuickBooks had the request. QuickBooks may still have applied it, so look before sending it again. `discarded`: your app discarded it before the Web Connector picked it up, so QuickBooks never got it. `response_too_large`: QuickBooks answered, but with more than QuBe Sync accepts for one answer (4 MB as the Web Connector sends it, about 3 MB of qbXML), so the answer wasn't kept and `response_json` is null. QuickBooks ran the request. Page the query (`iterator` and a smaller `max_returned`), or narrow it when QuickBooks doesn't page it; for a write, look before sending it again. Web Connector problems on the customer's PC (its password, log file, the .QWC file) never reach QuBe Sync as an error: the Web Connector just stops calling in, and requests wait. Intuit's guide for those: https://quickbooks.intuit.com/learn-support/en-us/help-article/open-programs/fix-common-web-connector-errors-quickbooks-desktop/L9slolvg0_US_en_US enum: - xml_error - quickbooks_connection_error - quickbooks_business_error - unexpected_error - response_too_large - outcome_unknown - timed_out - discarded type: string hresult: description: >- The Web Connector's HRESULT (e.g. `0x80040400`), for a connection or XML error. Informational: branch on `error_type`, not on this. type: - string - 'null' message: description: >- The raw message from QuickBooks or the Web Connector; for `timed_out` and `discarded`, which neither sent, QuBe Sync's own. type: string user_message: description: A friendly message for the end user. type: string type: - object - 'null' id: description: Unique identifier for the queued request format: uuid type: string inserted_at: description: When the request was queued format: date-time type: string iteration_state: description: >- Whether this response is part of an ongoing iteration, and if so, whether more pages remain. Use this (not `state`) to tell whether a multi-page response is complete. enum: - not_applicable - continue - done - max_sandbox_iterations_reached type: string links: properties: connection_ui: format: uri type: string pages: description: >- The pages of a multi-page (iterated) response answered so far, oldest first, a page of them at a time (`page`, `page_size`), each with its own `iteration_state`. Each page is also delivered to `webhook_url` as it is answered. format: uri type: string self: description: >- This request, on demand (a dashboard link, a retry). The answer itself arrives at `webhook_url`. format: uri type: string ui: description: The request in the QuBe Sync dashboard. format: uri type: string required: - self - ui - connection_ui - pages type: object original_request_id: description: >- The id of the first page of this request's iteration. Equal to `id` on the first page itself. format: uuid type: string page: description: The page number, for a multi-page (iterated) response nullable: true type: integer request_types: description: The qbXML request type(s) compiled into this request items: type: string type: array request_xml: description: >- The qbXML sent to QuickBooks: compiled from the operation and its parameters, or as written for `POST /connections/{connection_id}/queued-requests`. A character above ASCII reaches QuickBooks as a character reference (`é`). type: string response_json: description: QuBe Sync's summary of the answer, once the request is completed nullable: true type: object response_xml: description: >- The qbXML response from QuickBooks. One answer can be at most 4 MB as the Web Connector sends it, about 3 MB of qbXML; QuickBooks' answer over that isn't kept: this is null and `error.error_type` is `response_too_large`. nullable: true type: string state: description: >- `waiting`/`retryable`/`ticketed`/`sent` while the Web Connector is on its way; `response_received` once QuickBooks answered successfully (read `response_json.data`, and `response_json.warning` when QuickBooks warned about something it did); `error` when it did not -- the Web Connector could not reach QuickBooks, the qbXML was rejected, or QuickBooks answered with a business error such as 3100 (then `error.error_type` is `quickbooks_business_error` and `response_json` still carries QuickBooks' own `{status: "error", error: {code, type, message}}`); `timed_out` when no answer came back (QuickBooks may still have applied it, so look before sending it again) and `discarded` when your app discarded it before the Web Connector picked it up. Both carry an `error`. enum: - waiting - retryable - ticketed - sent - response_received - error - timed_out - discarded type: string webhook_attempts: items: type: object type: array webhook_error: nullable: true type: string webhook_state: enum: - not_applicable - pending - succeeded - failed type: string webhook_url: format: uri nullable: true type: string required: - id - state - request_xml - links type: object RawQBXMLResponseJSON: anyOf: - properties: data: description: >- What QuickBooks returned, snake_cased, as an operation's `data` is: a list for a query, the record for an add or update. error: properties: code: description: QuickBooks' own statusCode. The stable thing to branch on. type: - integer - 'null' current: description: >- The record as it stands in QuickBooks, shaped as a success's `data`, when QuickBooks sent it with the refusal, as it does with `stale_edit_sequence` (3200). Nothing was changed, and `current.edit_sequence` is the record's current one: re-apply your change and send it again with that `edit_sequence`. Absent when QuickBooks sent no record; then query the record first. type: object message: description: QuickBooks' own statusMessage. type: string type: description: >- A stable name for `code`, when QuBeSync recognises it. Absent otherwise: coverage widens over time, so treat this as a hint and branch on `code` if you need certainty. type: string type: object message: description: >- QuickBooks' own status message, carried through when there is no data to show for an otherwise successful request (a query that matched nothing, say). type: string status: enum: - success - error type: string warning: description: >- Present only when QuickBooks answered with a `Warn` severity: it carried the request out, and `data` is what it saved or found, but it has something to say about it. For example code `530` with the message `The field "Memo" is not supported by this implementation.` means the record was saved without that field, so an add or update that comes back with a `warning` may not have saved everything it sent. Absent on a plain success and on an error. properties: code: description: QuickBooks' own statusCode. The stable thing to branch on. type: integer message: description: >- QuickBooks' own statusMessage, such as which field it did not support. type: string required: - code type: object required: - status title: One request type: object - properties: responses: description: One entry per request, in the order they were sent. items: properties: data: description: >- What QuickBooks returned, snake_cased, as an operation's `data` is: a list for a query, the record for an add or update. error: properties: code: description: >- QuickBooks' own statusCode. The stable thing to branch on. type: - integer - 'null' current: description: >- The record as it stands in QuickBooks, shaped as a success's `data`, when QuickBooks sent it with the refusal, as it does with `stale_edit_sequence` (3200). Nothing was changed, and `current.edit_sequence` is the record's current one: re-apply your change and send it again with that `edit_sequence`. Absent when QuickBooks sent no record; then query the record first. type: object message: description: QuickBooks' own statusMessage. type: string type: description: >- A stable name for `code`, when QuBeSync recognises it. Absent otherwise: coverage widens over time, so treat this as a hint and branch on `code` if you need certainty. type: string type: object message: description: >- QuickBooks' own status message, carried through when there is no data to show for an otherwise successful request (a query that matched nothing, say). type: string request: description: The request's element name, such as `CustomerQueryRq`. type: string request_id: description: The request's `requestID`, or `null` when it had none. type: - string - 'null' status: description: >- `success` or `error` for a request QuickBooks ran or refused; `not_processed` for one it skipped: with `stopOnError`, every request after the first that failed, which QuickBooks answers with 3231. enum: - success - error - not_processed type: string warning: description: >- Present only when QuickBooks answered with a `Warn` severity: it carried the request out, and `data` is what it saved or found, but it has something to say about it. For example code `530` with the message `The field "Memo" is not supported by this implementation.` means the record was saved without that field, so an add or update that comes back with a `warning` may not have saved everything it sent. Absent on a plain success and on an error. properties: code: description: >- QuickBooks' own statusCode. The stable thing to branch on. type: integer message: description: >- QuickBooks' own statusMessage, such as which field it did not support. type: string required: - code type: object required: - request - request_id - status type: object type: array status: description: '`success` only when every entry is `success`.' enum: - success - error type: string required: - status - responses title: A batch type: object description: >- QuBe Sync's summary of QuickBooks' answer. One request: the `{status, data}` summary an operation's `response_json` is. A batch: `{status, responses}`, one entry per request. What each QuickBooks status code means and how to handle it: [Error handling](https://docs.qubesync.com/error_handling#quickbooks-said-no). Error: description: >- What a refused request answers with. The one key is errors, and its shape says what went wrong: a sentence when the endpoint explains the refusal in words (a parameter the operation does not take, a key already taken, a run that has already ended); an object with detail, and a code when there is one, when the request named nothing that exists or may not do what it asked (402, 403, 404, and a CLI session's 401), or an answer to a run's question was refused (the decisions endpoint's 400, 409 and 422, which always carry a code to branch on); an object of fields, each a list of messages, when a record failed validation and nothing was saved; a list of {path, message} problems when a submitted document or input fails validation. A request without a usable API key gets a 401 Basic challenge with the plain-text body Unauthorized, not JSON. properties: errors: oneOf: - example: 'unknown parameter: "emial"' title: A sentence type: string - properties: code: example: read_only_session type: string detail: example: Not Found type: string required: - detail title: Detail and code type: object - additionalProperties: items: type: string type: array example: webhook_url: - may not contain a username or password title: Field by field type: object - items: properties: message: example: is required type: string path: example: input.customer type: string required: - path - message type: object title: Located problems type: array required: - errors type: object headers: IdempotentReplayed: description: >- `true` when the call repeated an earlier call's `Idempotency-Key`: this is what that call created, as it is now, and nothing new was queued. Absent otherwise. schema: enum: - 'true' type: string responses: Unauthorized: content: text/plain: example: Unauthorized schema: type: string description: >- No usable API key. The key is Basic auth, so the answer is the challenge, with the plain-text body Unauthorized rather than JSON. headers: WWW-Authenticate: schema: example: Basic realm="Application" type: string SandboxPaused: content: application/json: example: errors: detail: >- Sandbox access is paused for this organization because the sandbox period expired and the organization does not currently have both active billing and a recent production connection. Please request an extension if you're still working on your integration or contact support if you have questions. schema: $ref: '#/components/schemas/Error' description: >- A sandbox app whose organization's sandbox access is paused. Nothing was queued. NotFound: content: application/json: example: errors: detail: Not Found schema: $ref: '#/components/schemas/Error' description: Nothing by that id, or it belongs to another app. securitySchemes: apiKey: description: Use your app's API key as the username, and leave the password blank scheme: basic type: http ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.