> ## 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. # Get a workflow run ## OpenAPI ````yaml /api-reference/v2/openapi.json get /connections/{connection_id}/workflow-runs/{run_id} 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}/workflow-runs/{run_id}: get: tags: - Workflows summary: Get a workflow run parameters: - description: ID of the connection in: path name: connection_id required: true schema: format: uuid type: string - description: ID of the workflow run in: path name: run_id required: true schema: format: uuid type: string responses: '200': content: application/json: schema: properties: data: $ref: '#/components/schemas/WorkflowRun' type: object description: The run '404': description: No run you started with that id on that connection security: - apiKey: [] components: schemas: WorkflowRun: properties: cancel_reason: description: Why the run was cancelled, when a reason was given. nullable: true type: string connection_id: format: uuid type: string current_state: description: >- Where the run is: the leaf state path, and while a workflow it calls is running, on into that workflow -- ` / `, such as `create_customer / resolve_conflict.find_holder`. Null once it has ended. example: create_customer / resolve_conflict.find_holder nullable: true type: string error: allOf: - $ref: '#/components/schemas/WorkflowRunError' description: What failed it, once it has; null otherwise. nullable: true headline: description: >- What happened, in one plain sentence for a person: how it ended once it has (the workflow's own sentence for its outcome), the question's message while it asks. Never parse it. example: Created Riverbend Electric in QuickBooks. type: string id: format: uuid type: string input: type: object links: description: >- `self` (this run), `decisions` (answer a question), `search` (find the record a question's `record` field means), `cancel` (stop the run) and `ui` (the run in QuBeSync). properties: cancel: format: uri type: string decisions: description: >- Where to answer. While the run is `awaiting_input`, it carries the current prompt's `token` as `?prompt_token=`, so an answer POSTed to it can only answer that question: once the run has asked again it is refused with `409 prompt_changed`. format: uri type: string search: description: >- Where a `record` field of the question is searched: set only while the run is `awaiting_input` with a choice that has one, which only a realtime or simulated connection (with a name index) offers, and null otherwise. It carries the prompt's `token` as `?prompt_token=`, like `decisions`; add `field` and `q`. format: uri nullable: true type: string self: format: uri type: string ui: format: uri type: string type: object outcome: description: >- How the run ended, once it has. With state completed: completed, or a success the workflow declares (such as cancelled) -- it worked as designed and this is how it ended. With state failed: failed, or a failure the workflow declares (such as customer_over_limit) -- something needs attention, and this names what. Null while the run is still going. nullable: true type: string output: nullable: true type: object prompt: description: >- Present while awaiting_input: `id` (the question's id, as the workflow's contract lists it -- its path from this run, ` / `, when a workflow this one calls asked), `token` (new each time the run asks; send it back as the decision's `prompt_token`), `kind`, message, data, details, the options and the choices to pick from. `details` (label and value rows: what it is about) and `choices` (everything the person can pick, in order, each with its `fields`) are what to render: every question is shown and answered the same way, by `choice`, and `options` stays for a chart's own code. `from` is set when a workflow this one calls asked the question: `workflow` (its key) and `state` (its own wait state) -- that workflow runs as part of this run, so answer it here either way. When the asking workflow runs once per item of a list, `from` also carries `item_index` (0-based) and `item_count`. `kind` says who asked: `decision` for a `wait` state's own question, `conflict` when the engine asks about an update that met a stale edit sequence (someone changed the record in QuickBooks after the run read it, error 3200) and the state's `on_conflict` is `ask`, its default. A conflict prompt's `id` is `conflict:` (prefixed like any question when a workflow this one calls asked), `state` is the request state that sent the update, and `data` carries `operation` (the update, e.g. `customer.update`), `sent` (the fields it carries, without its id and edit sequence), `current` (the record QuickBooks has now, with its edit sequence), `as_read` (the record as the run last read it, or null when it never read it), `conflicts` (one `{field, sent, current, as_read}` row per field being updated that someone else changed too) and `theirs` (one `{field, as_read, current}` row per field they changed that the update does not touch; empty when `as_read` is null). Its options are fixed: `overwrite` re-sends with the current edit sequence -- the original fields, or `data.params` (an object, optional) in their place -- and `keep` carries on with the record as QuickBooks has it. nullable: true properties: choices: description: >- Everything the person can pick, in order, at most 26: render one button (and its fields) per choice, and POST the picked one's `id` as `choice`. Built when the run asks, from `options`: a plain option is one choice with its id; an option whose field picks from a list is one choice per item (`use:1`, `use:2`, ..., at most 25), its value filled in by QuBe Sync; a field searched from the name index adds a search choice (`links.search`). Show these rather than `options`: every question is rendered and answered the same way. items: $ref: '#/components/schemas/WorkflowPromptChoice' maxItems: 26 type: array details: description: >- What the question is about, as label and value rows to show under `message`, at most 20: the name and kind, a transaction's number, the operation; for a conflict, one row per field that differs (`yours … · theirs …`). Built when the run asks. items: $ref: '#/components/schemas/WorkflowPromptDetail' maxItems: 20 type: array kind: description: >- decision: a wait state's own question. conflict: the engine asks about an update that met a stale edit sequence; see the prompt's description. enum: - decision - conflict type: string token: description: >- This asking of the question: new every time the run asks, the same question asked again included (a `wait` in a loop, a workflow called once per item, another conflict). Send it as the decision's `prompt_token`, and an answer that arrives after the run has asked again is refused instead of taken for the new question. Opaque: compare it only for equality. type: string type: object reference: description: >- Your own label for the run, exactly as you sent it when you started it; null if you sent none. nullable: true type: string revision: description: >- 1 when the run starts, and higher with every change to it: its state, its question, where it is, its result. Every body of the run carries it -- this one, the start and decision responses, every webhook -- so of two you hold, the higher revision is the newer: keep the highest you have applied and skip a body whose revision isn't higher. While a workflow the run calls is running, `current_state` can move on into it without a new revision. minimum: 1 type: integer state: description: >- running means it is working -- a QuickBooks request is in flight, or a workflow it calls is running as part of it; awaiting_input means it needs a decision from you, whichever part of it asked. cancelled means somebody stopped it (`POST .../cancel`); `outcome` stays null and `cancel_reason` says why, when they said. enum: - running - awaiting_input - completed - failed - cancelled type: string summary: allOf: - $ref: '#/components/schemas/WorkflowRunSummary' description: >- Set once the run has ended (completed, failed or cancelled): what it did. Null while it is going. nullable: true trace: items: properties: at: format: date-time type: string event: nullable: true type: string from: nullable: true type: string to: type: string type: object type: array vars: type: object workflow: description: >- The key of the workflow this is a run of. Still set when that workflow has been deleted: the run is kept, readable by its id until retention removes it. type: string type: object WorkflowRunError: description: >- What failed a run, as an object to branch on and show (docs: Workflow webhooks). On `workflow_run.failed`, on the run, and on a failed item of a once-per-item state's output (`push_records`' `items`). properties: code: description: >- QuickBooks' status code, when a QuickBooks answer failed the run (3100: the name is in use); null when the workflow failed on its own terms. example: 3100 nullable: true type: integer hint: description: What usually fixes it, for the code; null when there is no hint. nullable: true type: string message: description: >- One plain sentence saying what went wrong: the workflow's own words, or, for QuickBooks' error as it came, a plainer sentence for the code (QuickBooks' text is in `quickbooks_message`). Safe to show to the person who started the run. type: string quickbooks_message: description: >- QuickBooks' own text, when it answered with the error; null otherwise. nullable: true type: string type: description: >- A stable name for what failed: the code's slug (`name_in_use`, `object_not_found`, ...; the table grows, so a code it doesn't know yet has none), `no_response` for a request QuickBooks never answered, `invalid_input` for an element whose input the called workflow refused, or the failure outcome's key. Branch on it, or on `code`. example: name_in_use nullable: true type: string required: - code - type - message - quickbooks_message - hint type: object WorkflowPromptChoice: description: >- One thing the person can pick, in the order to show them. Answer with `{"choice": id}`, and `data` holding its `fields`. A choice like `use:1` is one item of a list the run offers -- a candidate, a transaction it found -- with its value already filled in by QuBe Sync, so your app never handles the ListID or TxnID. A choice with a `record` field is the search for another one, offered only on a realtime or simulated connection. properties: description: description: What picking it does, for a line under the label. example: Try the add again under a name you choose. nullable: true type: string detail: description: >- A short second line about one item of a list: a candidate's list and why it matched, a transaction's date, customer and amount. example: Customer · similar name nullable: true type: string fields: description: >- What to fill in before picking it, in order; empty for a choice that is a button alone. items: $ref: '#/components/schemas/WorkflowPromptField' type: array id: description: Unique within this prompt. Send it as the decision's `choice`. example: rename type: string label: description: 'What the choice says: a button''s text.' example: Add it under another name type: string required: - id - label - description - detail - fields type: object WorkflowPromptDetail: description: >- One row of what a question is about: a label and its value, both strings, already formatted for a person to read (a list as its parts joined with ' · '). properties: label: example: Customer type: string value: example: Lone Star Supply Co type: string required: - label - value type: object WorkflowRunSummary: description: >- What a finished run did -- a workflow it calls runs as part of it, so what that workflow did is in these lists too, where the call sits in the run's order, under its path (` / `). Cancelling never undoes anything in QuickBooks: `changes` is what the run had already changed, and `unconfirmed` what it may have. This is the whole summary, as the run (`GET links.run`, the run lists) carries it: what a final webhook's summary has (WorkflowRunWebhookSummary, whose `unconfirmed` entries name the record kind rather than the state), plus the state that made each change (`side_effects`), every request it sent, every workflow it called, what its match states found, and what a cancel withdrew. properties: calls: description: >- Every workflow the run called, the ones those called included, in order: the calling state's path, the element when that state runs once per item, the workflow it called and how that ended. What each did is in the lists above. items: properties: item_index: description: >- Which element of the list the call ran for, when the calling state runs once per item; null otherwise. nullable: true type: integer outcome: description: >- How the called workflow ended: completed, failed, or an outcome it declares. Null when it was cancelled. nullable: true type: string state: description: The calling state, as a path from this run. example: create_customer type: string status: enum: - completed - failed - cancelled type: string workflow: description: The key of the workflow it called. type: string type: object type: array changes: description: >- Every record the run changed in QuickBooks, in order, wherever in the run it happened (the workflows it called included): the creates, updates, deletes, voids and merges QuickBooks answered with success, and one whose answer was lost and that was found applied afterwards, with `settled`. items: properties: action: description: >- What was done: `create`, `update`, `delete`, `void`, `merge`, or the operation's own verb. example: create type: string full_name: description: The record's full name, when QuickBooks returned one. type: string item: description: >- Only for a change made for one element of a state that runs a workflow once per item (each record of `push_records`): which element, 0-based, as `items[].index` says. type: integer kind: description: >- What it was done to: the record's kind (`customer`, `invoice`, `receive_payment`), or `transaction` for a void or delete of any transaction. example: customer nullable: true type: string list_id: description: The record's ListID, when QuickBooks returned one. type: string ref_number: description: The transaction's number, when QuickBooks returned one. type: string settled: description: >- Only when QuickBooks' answer was lost and the change was found applied afterwards: how. enum: - found - already_deleted - already_current - kept type: string txn_id: description: The transaction's TxnID, when QuickBooks returned one. type: string required: - action - kind type: object type: array decisions: description: >- Every answer the run was given, in order, as the engine records it: the asking state's path, the workflow whose state it is, `item_index`, the `option` chosen and when. A webhook carries them as `question`, `choice`, `at` and `item`. items: properties: at: format: date-time type: string item_index: description: >- Only inside an element of a state that runs a workflow once per item: which element (0-based). type: integer option: type: string state: description: >- Where it happened, as a path from this run: a state of this workflow, or ` / ` inside a workflow it calls. example: create_customer / try_create type: string workflow: description: The key of the workflow whose state that is. type: string type: object type: array discarded: description: >- Requests that were queued but not yet sent when the run was cancelled, and were withdrawn; and, for a state that runs a workflow once per item, how many items never started. items: properties: item_index: description: >- Only inside an element of a state that runs a workflow once per item: which element (0-based). type: integer items_not_started: description: >- For a state running once per item: the elements after the cancelled one. type: integer message: description: >- For items not started, e.g. "2 items of ensure_items not started". type: string operation: type: string queued_request_id: format: uuid type: string state: description: >- Where it happened, as a path from this run: a state of this workflow, or ` / ` inside a workflow it calls. example: create_customer / try_create type: string workflow: description: The key of the workflow whose state that is. type: string type: object type: array ended_at: format: date-time type: string matches: description: >- Only when the run's match states answered, the workflows it called included, in order: what each one found -- its tier and counts, never a name. items: properties: candidates: description: How many candidates the answer listed (at most 10). type: integer candidates_total: description: How many qualified as candidates. type: integer candidates_total_complete: description: '`false` when `candidates_total` is a lower bound.' type: boolean index: description: >- `ready`: answered from the connection's name index. `unavailable`: the connection has none (it isn't realtime), so QuickBooks' own filters answered. enum: - ready - unavailable type: string item_index: description: >- Inside a state that runs a workflow once per item: which element (0-based). type: integer match: enum: - exact - strong - candidates - none type: string state: description: The match state's path from the run you started. type: string workflow: description: The key of the workflow whose state it is. type: string type: object type: array notifications: description: >- Only when the run's notify states sent the app anything, the workflows it called included: how many `workflow_run.notification` webhooks were delivered (`sent`) and how many never were (`failed`: every attempt failed, or the data was over 4 MB). properties: failed: type: integer sent: type: integer type: object requests: description: >- Every QuickBooks request the run sent, in order. `status` is `success`, `error`, or `in_flight` for one already sent when the run was cancelled (it may still complete). A paginated query is one entry, with `pages`. A request whose answer was lost and that was then found applied reads as `success`, with `settled` and the record found: whether the run's own check found it, or a later query of the chart's own answered with the record the add carried (its `external_guid`, or for a list add sent without one, its full name), which `found_by` names. A change whose answer was lost and that nothing settled keeps `error` and has `unconfirmed`. items: properties: evidence: description: >- With `settled`, when the run settled it itself: on what grounds, in a sentence -- what the check looked at, what came back and what that means, such as `of 2 candidates with reference number "1044", one carries the GUID sent (txn_id 2-1), so the add was applied`. The same sentence is `response.evidence` in the chart and on the run's `settled` event. example: >- of 2 candidates with reference number "1044", one carries the GUID sent (txn_id 2-1), so the add was applied type: string found_by: description: >- Only on an add whose answer was lost and that the chart's own lookup found afterwards (`settle: false`): the state whose answer carried the record the add was sent with. The add reads as `success`, with that record's identifiers, and is a side effect. example: look_for_invoice type: string identifiers: description: >- Whichever of `list_id`, `txn_id`, `full_name` and `ref_number` QuickBooks returned for the record. properties: full_name: type: string list_id: type: string ref_number: type: string txn_id: type: string type: object item_index: description: >- Only inside an element of a state that runs a workflow once per item: which element (0-based). type: integer operation: type: string pages: description: >- Only for a paginated query: how many pages it took. `status` is how the last one went. type: integer role: description: >- Only for a request the run sent on its own to settle a lost answer or a conflict: `settle` a check, `read` the transaction a check found, read whole by its TxnID (the check reads headers only), `resend` the request again, `reapply` or `overwrite` an update sent again with the current edit sequence, `prepare` the read before an update. Absent for the state's own request. enum: - prepare - settle - read - resend - reapply - overwrite type: string settled: description: >- Only on a state's own request whose answer was lost, or that met a conflict: how the run settled it, as `response.settled` says. `found` is also what an add reads when a later query of the chart's own found it (`found_by`). enum: - found - already_deleted - already_current - resent - reapplied - overwritten - kept type: string state: description: >- Where it happened, as a path from this run: a state of this workflow, or ` / ` inside a workflow it calls. example: create_customer / try_create type: string status: enum: - success - error - in_flight type: string unconfirmed: description: >- Only `true`, on a create, update, delete or execute QuickBooks never answered (its computer lost its connection, or QuickBooks or the Web Connector was closed, while it had the request; nothing reports an error) that the run neither found applied nor sent again. It may or may not have changed QuickBooks; it is listed under `unconfirmed`, not `side_effects`. type: boolean workflow: description: The key of the workflow whose state that is. type: string type: object type: array side_effects: description: >- The same changes as `changes`, as the engine records them: the state that made each (a path from this run), the workflow whose state it is, `item_index`, `operation`, the record's `identifiers`, and `settled`/`evidence` for one found applied after a lost answer. For inspecting the run; a webhook carries `changes` only. items: properties: evidence: description: >- With `settled`, when the run settled it itself: on what grounds, in a sentence, as the request's `evidence` says. type: string identifiers: description: >- Whichever of `list_id`, `txn_id`, `full_name` and `ref_number` QuickBooks returned for the record. properties: full_name: type: string list_id: type: string ref_number: type: string txn_id: type: string type: object item_index: description: >- Only inside an element of a state that runs a workflow once per item: which element (0-based). type: integer operation: type: string settled: description: >- Only when QuickBooks' answer was lost and the change was found applied afterwards, by the run's own check or the chart's own lookup: how, as the request's `settled` says. enum: - found - already_deleted - already_current - kept type: string state: description: >- Where it happened, as a path from this run: a state of this workflow, or ` / ` inside a workflow it calls. example: create_customer / try_create type: string workflow: description: The key of the workflow whose state that is. type: string type: object type: array stopped_at: description: >- The state the run was in when it ended -- a path into the workflow it called when it ended while one was running. Null for a run that completed (a webhook leaves it out then). example: create_customer / resolve_conflict.ask_about_customer nullable: true type: string unconfirmed: description: >- Only when there is one: the creates, updates, deletes and executes QuickBooks never answered that the run neither found applied nor sent again -- the chart asked your app and it picked another record, say, or the run failed or was cancelled first. Each may or may not have changed QuickBooks, so it is not in `changes`: check QuickBooks before sending it again. Its entry in the whole summary's `requests` (on the run) is the same, with `unconfirmed`. items: properties: item_index: description: >- Only inside an element of a state that runs a workflow once per item: which element (0-based). type: integer operation: type: string state: description: >- Where it was sent, as a path from this run: a state of this workflow, or ` / ` inside a workflow it calls. example: add_invoice type: string workflow: description: The key of the workflow whose state that is. type: string type: object type: array type: object WorkflowPromptField: description: >- What to fill in before picking a choice: one input per field, sent back in the decision's `data` under `name`. A `record` field is filled from a search (`GET links.search?field=&q=...`), with the `value` the search returned: never a ListID typed or picked by your app. A `rows` field is a table (docs: the question about missing records): one row per entry of `rows`, a column per entry of `columns` the row asks (`rows[].columns`) and that applies to it as answered so far (the column's `when`), answered as an object keyed by each row's `key`, each an object of its columns' values. properties: columns: description: >- Only for `rows`: what each row is asked, in order. Every row shares them, so your screen can set one column on many rows at once. items: $ref: '#/components/schemas/WorkflowPromptColumn' type: array enum: description: >- Only when the field takes one of a fixed list: the values, each with what a person reads for it. A value outside it is refused (`422 invalid_data`). items: $ref: '#/components/schemas/WorkflowPromptEnumValue' type: array kind: description: >- Only for `record`: the list the search looks in, such as `customer`, `entity`, `item` or `account`. example: customer type: string label: description: What the input says. example: New name type: string name: description: The key in the decision's `data`. example: name type: string required: description: Whether the choice is refused (`422 missing_fields`) without it. type: boolean rows: description: 'Only for `rows`: the rows, at most 100. Answer every one.' items: $ref: '#/components/schemas/WorkflowPromptRow' type: array type: description: >- `string`, `number` and `boolean` are what a person types or ticks (a drop-down of `enum`, when there is one); `record` is a record of `kind` found with the run's search; `rows` is a table of `rows` and `columns`. enum: - string - number - boolean - record - rows type: string required: - name - type - label - required type: object WorkflowPromptColumn: description: 'One column of a `rows` field: a field asked of each row that lists it.' properties: enum: description: The values it takes, when it takes one of a fixed list. items: $ref: '#/components/schemas/WorkflowPromptEnumValue' nullable: true type: array kind: description: >- For a `record` column whose list is the same for every row (`account`); null when it depends on the row: each row's `kinds` says it. example: account nullable: true type: string label: example: Income account type: string name: description: The key in each row's answer. example: income_account type: string required: description: >- Whether a row it applies to is refused (`422 missing_fields`, named `..`) without it. type: boolean type: description: >- As a field's; a `record` column is filled from the run's search with `field=.&row=`. enum: - string - number - boolean - record type: string when: additionalProperties: items: {} type: array description: >- The values of the row's other columns this one applies under: `{"action": ["create"], "item_type": ["item_inventory"]}` asks it only of a row being created as an inventory item. Read them over the row's `values` and what the person has chosen so far, and show or hide the column as they change. An answer to a column that doesn't apply is dropped. example: action: - create nullable: true type: object required: - name - type - label - required - kind - enum - when type: object WorkflowPromptEnumValue: properties: label: description: What a person reads. example: Service type: string value: description: What to send. example: item_service oneOf: - type: string - type: number required: - value - label type: object WorkflowPromptRow: description: >- One row of a `rows` field: one thing the question asks about, such as a record QuickBooks doesn't have. properties: columns: description: >- The columns this row asks, by name, in the field's order; send no others for it. example: - action - list_id - income_account items: type: string type: array detail: example: Item nullable: true type: string key: description: >- Unique among the rows: the key of its answer in the field's object, and `row` in a search. add_transaction's is the reference's first path in the params your app sent. example: invoice_line_add.0.item_ref type: string kinds: additionalProperties: type: string description: For each `record` column the row asks, the list its search looks in. example: income_account: account list_id: item type: object label: example: Vinyl Banner type: string values: additionalProperties: {} description: >- What the row already says for columns it doesn't ask (an item add your app sent fixes its type): show them, read `when` over them, and don't send them. example: item_type: item_non_inventory type: object required: - key - label - detail - columns - values - kinds type: object 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.