Integration Nodes
This page covers the configuration of workflow nodes that connect to external systems — the API Node, GitHub nodes, and Forge Function nodes. For the full list of available nodes, see Workflow Nodes.
API Node — Auto Retry
The API Node includes an Auto Retry section. When enabled, a failed request is retried automatically instead of failing straight away, spreading retries out over time with a randomised, decaying delay. When retries are exhausted, any configured Failure Routes take over.
API Node — Auto Retry settings
| Setting | Description |
|---|---|
| Enable auto retry | Turns on automatic retry behaviour for this node. |
| Retry on | Which failure types trigger a retry: Timeout, HTTP error status, Null / empty response, Other errors. |
| Max retries | The maximum number of retry attempts. |
| First retry delay | How long to wait before the first retry. Retries are checked on a 5-minute schedule, so delays are chosen in 5-minute steps; the first retry happens at the next check after the chosen delay has elapsed. |
| Delay decay factor | Multiplier applied to the delay between successive retries. |
| Max delay | The upper limit on the delay between retries. |
| Jitter (0–1) | How much the delay is randomised. 1 spreads retries fully across the window so items that failed together do not all retry at the same instant; 0 uses a fixed delay. |
API Node — Concurrency & burst control
The API Node also includes a Concurrency & burst control section, for limiting how many requests this node sends to a slow or rate-limited endpoint. When the limit is reached, the run is queued and retried automatically instead of failing.
API Node — Concurrency & burst control settings
| Setting | Description |
|---|---|
| Limit concurrent requests | Turns on concurrency/burst limiting for this node. Off by default. |
| Group requests by | What counts as "the same endpoint" for the limits below. Defaults to URL (host and path) — each endpoint gets its own allowance. Other options include sharing one allowance across a whole host (Server) or across the whole node regardless of destination (This node). |
| Requests at the same time | How many requests may be in progress simultaneously. A further request waits until one of these gets a reply. |
| Requests per time window | Total requests allowed in each window, whether or not they overlap. Left at 0, this time-based limit is off and only the simultaneous limit applies. |
| Wait for a free slot (seconds) | How long a held-up request waits for a slot before it is queued for the next sweep. Most congestion clears within seconds, so a short wait usually sends the request straight away. Set to 0 to queue immediately instead of waiting. |
A live summary above these fields restates the configured limits in plain language (e.g. "At most 2 requests at a time to each URL (host and path). A held-up request waits up to 30s, then queues for the next sweep."). A queued run is retried on the next sweep, roughly every 5 minutes, and is shown as Queued in the Inbox rather than as a failure. A queue that never clears can be routed using the Queue limit reached option in the node's Failure Routes settings.
GitHub Commit Node
The GitHub Commit Node commits one or more documents to a connected GitHub repository. It requires the connector's contents_write feature to be enabled (and workflow_files if committing under .github/workflows) — otherwise the run is refused.
GitHub Commit Node — Repository and branch settings
| Setting | Description |
|---|---|
| Repository | The connected GitHub repository to commit to. |
| Branch | The branch to commit onto. Supports Jinja templating against the source document. |
| Base branch (optional) | When the branch does not exist yet, it is forked from this branch. Defaults to the repository's default branch if left blank. |
| Create branch if missing | Creates the branch when it does not exist. If off and the branch is missing, the node fails. |
| Delete branch on completion | Deletes the branch once the downstream GitHub Action run finishes — useful for cleaning up throwaway branches. Requires a GitHub Action Node in poll or webhook mode after this node. |
| What to commit | Selects which document(s) this node commits (see below). |
| Repository path (optional) | Subfolder in the repository to place the file(s) under. Left blank, files commit at the repository root using each document's original filename. |
| Commit message (optional) | Overrides the default commit message. Supports Jinja templating. |
What to commit offers three options:
What to commit — selector options
| Option | Description |
|---|---|
| Workflow document | The item this workflow started from. |
| Node input | Documents produced by previous nodes. |
| Specific document IDs | A comma-separated list of document IDs to commit. |
GitHub Action Node — Run Tracking
The GitHub Action Node dispatches a GitHub Actions workflow run and, depending on the selected Run Tracking Mode, can wait for that run to finish before proceeding. It requires the connector's actions feature to be enabled, otherwise the run is refused.
| Setting | Description |
|---|---|
| Repository | The connected GitHub repository. |
| Workflow File | The workflow filename in .github/workflows on the chosen ref. It must declare a workflow_dispatch trigger and a docwize_run_id input, and echo it via run-name so Docwize can identify the run. |
| Ref (branch or tag) | The branch or tag to dispatch against. Supports Jinja templating. |
| Workflow Inputs | Extra workflow_dispatch inputs passed to the run. Values support Jinja templating and are rendered at dispatch time. A docwize_run_id correlation token is added automatically. |
| Run Tracking Mode | Fire and forget (dispatch and continue immediately), Poll for completion (pause and poll the Actions API until the run finishes), or Await webhook (pause and resume when GitHub delivers the workflow_run completion webhook; a watchdog poll recovers missed deliveries). |
If the target workflow file is unlikely to support run correlation, a pre-flight warning appears in the dialog:
Pre-flight warning: run tracking may not work for this workflow
To poll or await a run, the workflow file must declare a workflow_dispatch trigger, declare a docwize_run_id input, and echo it into its top-level run-name (e.g. run-name: "${{ inputs.docwize_run_id }}"). Without the run-name echo, Docwize cannot correlate the run and the node hangs until it times out. Fire and forget mode is unaffected.
The node routes to one of three outputs: On success (the run completed successfully), On failure (the run completed but failed), or On infrastructure error (Docwize couldn't dispatch or track the run at all — for example a connector or API problem, distinct from the GitHub Actions run itself failing).
Forge Function Node
A Forge Function node runs the corresponding uploaded function against the workflow document and its files. Its output side has one port per output route declared in the function's manifest, instead of a fixed set of ports — for example, a function might expose Appended, No PDF, and Error routes, each connecting to a different next step.
Related configuration
- Workflow Nodes — full reference of all available canvas nodes
- Advanced Node Configuration — conditional logic, Run Oliver, and distribution set nodes
- Docwize Forge — uploading the custom functions that appear as Forge Function nodes
- GitHub Connectors — connecting a repository for the GitHub nodes to use
- Building Workflow Templates — the canvas where nodes are assembled into templates