> ## 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. # A workflow run's event log > Everything that happened in a run you started, oldest first: states entered and left, requests queued and the responses that came back, every transition with the guards it considered, what was saved, questions and answers, webhooks, and how it ended. A workflow the run calls runs as part of it, so its events are in this one stream, right after the `call_started` event that began it: each entry's `seq` is its position (`7`, then `7.1`, `7.2`... for the called workflow, `7.3.1` a level deeper), `state` its path from your run and `workflow` whose chart it belongs to. A page never goes past the end of a called workflow that is still running, so the next page -- `after` the last `seq` you have -- always picks up its new events in order. ## OpenAPI ````yaml /api-reference/v2/openapi.json get /connections/{connection_id}/workflow-runs/{run_id}/events 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}/events: get: tags: - Workflows summary: A workflow run's event log description: >- Everything that happened in a run you started, oldest first: states entered and left, requests queued and the responses that came back, every transition with the guards it considered, what was saved, questions and answers, webhooks, and how it ended. A workflow the run calls runs as part of it, so its events are in this one stream, right after the `call_started` event that began it: each entry's `seq` is its position (`7`, then `7.1`, `7.2`... for the called workflow, `7.3.1` a level deeper), `state` its path from your run and `workflow` whose chart it belongs to. A page never goes past the end of a called workflow that is still running, so the next page -- `after` the last `seq` you have -- always picks up its new events in order. 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 - description: >- Return the entries after this `seq` (the previous page's `next_after`, or the last `seq` you have when polling for more), including those inside a called workflow when it points inside one. in: query name: after required: false schema: example: '7.3' type: string - description: >- How many entries per page (default 100), a called workflow's included. in: query name: limit required: false schema: maximum: 500 type: integer responses: '200': content: application/json: schema: properties: data: items: $ref: '#/components/schemas/WorkflowRunEvent' type: array next_after: description: >- Pass as `after` for the next page; null when there is nothing more to read yet. nullable: true type: string type: object description: A page of the log '404': description: No run you started with that id on that connection security: - apiKey: [] components: schemas: WorkflowRunEvent: description: >- One thing that happened in a run you started, or in a workflow it calls -- which runs as part of it, so its events are in the same stream, right after the `call_started` event that began it. Append-only. 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 kind: description: >- `call_started` and `call_finished` begin and end a workflow this one calls; `run_started` and `run_completed`/`run_failed`/`run_cancelled` with a `state` are that workflow's own start and end, at the calling state. `notification_queued`, `notification_delivered` and `notification_failed` are a notify state's `workflow_run.notification`: sent, answered with a 2xx, or never delivered. `match_waiting` and `match_answered` are a match state's: waiting for the connection's name index to be built or refreshed, and what it found (its tier and counts, never a name). enum: - run_started - state_entered - state_exited - request_queued - response_received - page_delivered - settling - settled - unsettled - event_raised - transition_taken - assigns_applied - prompt_shown - decision_received - call_started - call_finished - notification_queued - notification_delivered - notification_failed - match_waiting - match_answered - webhook_sent - run_completed - run_failed - run_cancelled type: string payload: description: >- What the kind carries: `response` (the whole response) on response_received -- except a paginated query's last one, which has `count` and `pages` in place of `data`, the records being on each page_delivered, `owner`/`event`/`index`/`description`/`target`/`to`/`considered` on transition_taken, `assigned` on assigns_applied, `option`/`data`/`by` on decision_received, `page`/`count`/`queued_request_id`/`response` on page_delivered (a paginated query's page, raised as `page`; `response` is that page's, as on response_received), `workflow` (and `item_index`/`item_count`) on call_started and call_finished, with `stops: true` on the call_finished of the element whose ending (one of the state's `stop_on`) ended the loop, `delivery_id`/`name`/`seq`/`bytes` on notification_queued, notification_delivered (with `attempts`) and notification_failed (with `attempts` and `error`, whose `type` is `not_delivered` or `too_large`; one too large was never sent and has no `seq`) -- never what was sent, `for` (`build` or `refresh`) on match_waiting, `match` (the tier), `candidates`, `candidates_total`, `candidates_total_complete` and `index` (`ready`, or `unavailable` when it asked QuickBooks' own filters) on match_answered -- never a name, and so on. A `response` that succeeded but that QuickBooks warned about has `warning` with its `code` and `message` (530, for one: a field it does not support, which it saved the record without). A `response` that is an error has `error` with `code`, `type` and `message`; when `type` is `no_response` (QuickBooks never answered) it also has `reason`, why: `timed_out` or `connector_error` (sent, so QuickBooks may have applied it), `rejected` (QuickBooks could not read it), `withdrawn` (withdrawn before it was sent), `page_expired` (a later page never fetched) or `too_large` (QuickBooks ran it, but its answer was over QuBe Sync's size limit; a query is not re-sent), and, for an add, `external_guid`, the GUID it was sent with. Response bodies are removed 7 days after the run ends. type: object seq: description: >- Its position in the stream, which is the order entries come in and what `after` takes: `7` is the run's own 7th event, `7.2` the 2nd event of the workflow the 7th started, `7.3.1` a level deeper. example: 7.3.1 type: string state: description: >- Where it happened, as a path from the run you started: `create_customer / try_create` is a state of the workflow `create_customer` calls. Null for what happened to the run as a whole. example: create_customer / try_create nullable: true type: string vars_after: description: >- `vars` of the workflow it belongs to once this event had happened. Null 7 days after the run ends. nullable: true type: object workflow: description: The key of the workflow whose chart the event belongs to. type: string required: - seq - at - kind - state - workflow - payload - vars_after 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.