Integration Nodes
This page covers the configuration of workflow nodes that connect to external systems — the OCR Task Node, API Node, GitHub nodes, and Forge Function nodes. For the full list of available nodes, see Workflow Nodes.
OCR Task Node
The OCR Task Node runs optical character recognition on document pages, converting images of text into machine-readable text.
OCR Task Node settings
| Setting | Description |
|---|---|
| OCR engine | The OCR engine to use. Currently offers a single option: Google Cloud Vision. |
| Pages that already have text | How the node treats pages that already contain machine-readable text: Skip pages with existing text, Remove all text and OCR every page, or OCR only the parts of the page without text. |
| Show image processing options | Expands a set of additional image pre-processing controls, described below. |
Image processing options
| Setting | Description |
|---|---|
| AI assisted rotation - billed additionally | OCRs all 4 orientations with a low-cost model to determine orientation. Off by default; enabling it adds to OCR billing. |
| AI enrichment (Beta) - billed additionally | Uses AI to improve OCR accuracy on scanned or handwritten documents. Off by default; enabling it adds to OCR billing. |
| Auto-rotate pages | Rotates pages upright before OCR. On by default. |
| Deskew | Straightens skewed pages before OCR. Unavailable when Pages that already have text is set to OCR only the parts of the page without text — pick a different option to use deskew. |
| Clean before OCR | Attempts to clean whitespace from the page before OCR. |
| Output optimisation | Trade-off between output file size and quality: None, Lossless, Lossy images, or Maximum (default). |
API Node — Basic Settings & Authentication
The API Node sends an HTTP request to an external API. Settings are grouped into collapsible sections; Basic Settings, Headers, Body, and Test Request are expanded by default.
API Node — Basic Settings, Authentication Settings, Headers, Body, and Test Request
| Setting | Description |
|---|---|
| URL | The endpoint to call. Supports Jinja templating, e.g. {{ document.ref_number }} or {{ keystore('my_key') }}. |
| Request Method | GET, POST, PUT, or DELETE. |
| Save Raw Data | Saves the raw response alongside the node's output. |
| Headers | Request headers, entered as a Jinja-templated editor. |
| Body | Request body, entered as a Jinja-templated editor. |
Authentication Settings — the Authentication Method dropdown selects how the request authenticates; each method reveals its own fields.
| Method | Fields |
|---|---|
| None | — |
| Basic | Username, Key (password, selected from a saved Keystore entry) |
| API Token | API Token, API Secret |
| Token Fetch | Request Method, Auth Request URL, Auth Request Headers, Auth Request Body, Token Path (dotted path to the token in the response), Expiry Path, Inject As (Bearer Token or Named Header), plus an optional Username + Key if the token-fetch request itself needs Basic auth |
| OAuth2 Client Credentials | Token URL, Client ID, Client Secret (Key), Scope (optional), Audience (optional) |
| Custom Header | Header Name, Value Template, optional Secret (Key) |
Key fields are selected from previously-saved Keystore entries, or created inline via Add New Entry.
Response Validation — enabling Validate response signature (HMAC) verifies the response was genuinely sent by the configured endpoint.
| Field | Description |
|---|---|
| Algorithm | e.g. SHA512. |
| Signature Key | Key — the shared secret, selected from a saved Keystore entry. |
| Timestamp Header | The response header containing the request timestamp. |
| Signature Header | The response header containing the signature (default X-Signature). |
| Freshness (seconds) | How old a timestamp can be before the response is rejected as stale. |
API Node — Failure Routes & Failure Message Parsing
Failure Routes route the workflow down different paths when the request fails, evaluated top to bottom — the first match wins. Each rule adds a new output on the canvas node (labelled by Path name) that can be wired to a different branch. With no failure routes configured, a failed request stops the workflow at this node by default — the same failure that surfaces via the Workflow step failed pop-up and the Failed inbox status (see Inbox).
API Node — Failure Routes and Failure Message Parsing
| Field | Description |
|---|---|
| Path name | Label for the output this rule follows; wire it to a branch on the canvas. |
| Failure type | Timeout, HTTP error status, Null / empty response, Regex match on response, Queue limit reached, or Catch all failures. |
Failure Message Parsing controls how the readable failure reason (shown in the inbox, the initiator pop-up, and the failure email) is pulled out of a failure response. Steps run in order; the first step that extracts anything wins. Left empty, built-in heuristics are used.
| Extractor | Fields |
|---|---|
| Regex over response body | Pattern (group 1 is used when present), Max matches |
| XML / HTML elements | Element names (comma-separated, priority order), Max matches |
| JSON keys | JSON keys (dotted paths, comma-separated) |
Email the initiator on terminal failure — when the request fails for good (no retry left, or a non-retryable failure), the workflow initiator receives an email with the parsed failure reason and a link that opens the failure dialog.
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.
API Node — Pagination & Payload Transformation
Pagination Settings configure paging through a multi-page API response.
| Field | Description |
|---|---|
| Pagination Variable | Free-text field. |
| Pagination Multiplier | Free-text field. |
Payload Transformation Settings reshape the response before it is saved, via a top-to-bottom list of steps — each transforms the output of the one above it.
| Conversion Type | Fields |
|---|---|
| XML To Dict | — |
| Key Extraction | Nested Key |
| String to JSON | — |
| JSON to Dataframe | — |
| Virtual Key Generation | Result Key Name, New Virtual Key Name (add multiple via Add) |
| Merge Dicts | Key Extraction Path (add multiple via Add) |
| Reggex Extraction | Reggex Pattern — this is the live product's own spelling of both the option and its field label, not a docs typo |
| Column Generation | Result Column Name |
API Node — Test Request & Equivalent Code
The Test Request panel previews the live response of the configured request without running a full workflow instance.
| Field | Description |
|---|---|
| Sample Document Number (optional) | A sample document ID to resolve any document-based templating in the URL, Headers, or Body. |
| Send test request | Sends the request now and shows a pass/fail result inline (e.g. Test request failed with the HTTP status). |
Equivalent Code shows a ready-to-run code snippet built from the node's current settings — secrets are shown as environment variables, and templates render server-side at run time. Language defaults to cURL; a Copy button copies the snippet.
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