Skip to main content

Put a human decision on the record from n8n

The n8n-nodes-ujex package supplies three nodes: Ujex Inbox, Ujex Approvals, and Ujex Provenance. This walkthrough uses the first two to demonstrate the trust loop: prepare an exact action, wait for a person to decide, and keep the resulting approval and send in the agent's evidence record.

1. Install the community package​

Install n8n-nodes-ujex from Settings → Community Nodes in n8n. For a self-hosted custom-node installation, run npm install n8n-nodes-ujex inside ~/.n8n/nodes, then restart n8n.

2. Add one Ujex credential​

Create a Ujex API credential with:

  • Cloud Functions URL: https://us-central1-axy-ujex.cloudfunctions.net
  • Agent device key: the ap_live_… key shown once when the device is enrolled
  • Agent ID: the agent that will own the action and evidence
  • Firebase Web API key: use the default for the hosted Ujex project

Keep the device key in n8n credentials. Do not put it in a Set node, workflow JSON, expression, or execution log.

3. Build the bounded approval path​

Create this sequence:

Manual Trigger
    ↓
Set — proposed recipient, subject, body, and stable sessionId
    ↓
Ujex Approvals — exact action summary and detail
    ↓
IF — continue only when {{$json.status}} equals approved
    ↓ true
Ujex Inbox — Send

Configure Ujex Approvals like this:

FieldExample
PromptSend the prepared renewal notice?
DetailTo: {{$json.to}} · Subject: {{$json.subject}}
TTL1800 seconds
Poll interval5 seconds

The node creates one approval, polls the same approval ID, and returns only approved, denied, or expired. The IF node is important: a denied or expired response must not fall through to the side effect.

Configure Ujex Inbox with the fields from the Set node and keep Require Human Approval off in this particular example. The preceding Ujex Approvals node already owns the decision. Turning on both controls creates two independent approvals rather than making one approval stronger.

4. Verify the evidence​

After an approved run:

  1. Copy the approvalId from the Ujex Approvals node output.
  2. Open Evidence in the Ujex owner app.
  3. Filter for the same agent and execution time.
  4. Confirm the approval decision precedes the send and that the send carries the same stable session ID.
  5. Export the evidence pack and run the offline verifier if the demo is for an auditor.

A denied or expired run should show the decision and no downstream send. That negative case is the useful demo: it proves the workflow respects the human boundary instead of merely displaying an approval screen.

Failure behavior​

  • Missing or revoked device keys fail authentication; the node does not silently retry with another identity.
  • An approval that reaches its TTL returns expired and must follow the false branch.
  • A send that requires another approval remains pending; it does not reuse the earlier approval implicitly.
  • Ujex records calls it observes. It cannot attest to n8n nodes that bypass the Ujex nodes or API.

For the underlying callable shapes, see the API overview and countersignature lifecycle.