Send traces from n8n

n8n workflows can send traces to Mibo three ways. Pick the one that fits your setup:

Option	Works on	Best when
OTLP (env vars)	Self-hosted ≥ 2.19.0	You want all workflows traced automatically at the host level
Testing Node	Cloud + self-hosted (any version)	You want per-workflow control without touching host config
HTTP Request node	Cloud + self-hosted (any version)	You prefer not to install a community package

---

Option 1 — OTLP (self-hosted ≥ 2.19.0)

n8n self-hosted ships with built-in OTel workflow tracing since version 2.19.0. Add five environment variables to the n8n process and all workflow traces flow to Mibo automatically — no extra nodes, no per-workflow changes.

Caution

Set up the agent first. On the OTLP path Mibo routes traces by service.name: the value you set below (e.g. n8n-support-agent) must match the OTLP service name field on the target agent in the dashboard. Each value can belong to at most one agent per project. Without a configured match the endpoint returns 404 OTLP_PLATFORM_NOT_FOUND.

.env

OTEL_EXPORTER_OTLP_TRACES_PROTOCOL=http/json
OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=https://api.mibo-ai.com/public/traces
OTEL_EXPORTER_OTLP_TRACES_HEADERS=x-api-key=<your_api_key>
OTEL_RESOURCE_ATTRIBUTES=service.name=<otlp_service_name>
N8N_OTEL_TRACING_ENABLED=true

docker-compose.yml

services:
  n8n:
    environment:
      OTEL_EXPORTER_OTLP_TRACES_PROTOCOL: http/json
      OTEL_EXPORTER_OTLP_TRACES_ENDPOINT: https://api.mibo-ai.com/public/traces
      OTEL_EXPORTER_OTLP_TRACES_HEADERS: "x-api-key=<your_api_key>"
      OTEL_RESOURCE_ATTRIBUTES: "service.name=<otlp_service_name>"
      N8N_OTEL_TRACING_ENABLED: "true"

What each variable does:

Variable	Purpose
OTEL_EXPORTER_OTLP_TRACES_PROTOCOL	Forces HTTP+JSON transport. n8n defaults to gRPC — Mibo does not accept gRPC.
OTEL_EXPORTER_OTLP_TRACES_ENDPOINT	The URL where traces are exported.
OTEL_EXPORTER_OTLP_TRACES_HEADERS	HTTP headers attached to every export request. Carries your Mibo API key.
OTEL_RESOURCE_ATTRIBUTES	Key-value pairs stamped on every span. service.name is required and routes traces to the agent whose OTLP service name field matches it.
N8N_OTEL_TRACING_ENABLED	n8n-specific flag that activates the built-in OTel tracer. Without it, the OTEL_* variables have no effect.

Tip

Already sending traces to another backend? OTEL_EXPORTER_OTLP_TRACES_ENDPOINT accepts only one destination. To fan out to both your existing backend and Mibo, put an OTel Collector in front and add Mibo as a second pipeline there. Alternatively, use Option 2 or 3 — both send to Mibo independently, without touching your OTel config.

---

Option 2 — Testing Node (Cloud + self-hosted)

The Mibo Testing Node is an open-source community node (npm) that captures execution data from your workflow and sends it to Mibo as a canonical Your API trace (reference). It walks the connection graph, emits one span per executed node, and POSTs to /public/traces. If the payload exceeds 5 MB, it gzip-compresses it automatically.

The node is a passthrough — data flows through it unchanged.

Installation

1. Open your n8n instance

   Go to the n8n instance where your AI workflow runs.

2. Go to Community Nodes

   Navigate to Settings → Community Nodes.

3. Install the node

   Search for Mibo Testing and click Install.

4. Verify the installation

   The “Mibo Testing” node should now appear in your node palette.

Adding the node to your workflow

Add the Mibo Testing node after the nodes whose data you want to capture, typically at the very end of your workflow, right before the response is returned.

The node walks back through the workflow’s connection graph and captures every executed upstream node it can resolve. Captured node display labels become span.name in the trace, which is what your node_call assertions match against (case-insensitive substring).

Tip

Place the node at the very end. It captures upstream executed nodes — anything downstream won’t be in the trace.

Credentials

1. Double-click the Mibo Testing node to open its configuration panel.

2. Click Credentials and create a new Mibo Testing credential:

   • API Key — your Mibo API key from the dashboard. Scope it to a single agent to skip the Agent ID field below.
   • n8n API Key (recommended) — lets the node enumerate workflow nodes and resolve input parameters (e.g. the URL on an HTTP Request node) for expected_arguments assertions. Create one in n8n under Settings → API with workflow:read scope.
   • n8n Base URL (optional) — defaults to http://localhost:5678. Change for n8n Cloud or non-standard deployments.

Note

Workflow node enumeration. The node resolves the workflow’s node list by trying, in order: (1) the n8n REST API when an API Key credential is set, (2) an upstream Get Workflow node. If neither is available, the node throws. There is no third source — n8n’s IExecuteFunctions interface doesn’t expose workflow structure at runtime.

Node settings

Agent ID

Links this node to an agent in Mibo. Enter the agent UUID from your dashboard. Optional if your API key is already scoped to a single agent.

Request ID

Optional override for the x-request-id header. If left blank, resolution order is:

1. x-request-id on the workflow’s input items.
2. x-request-id on executed output items.
3. The n8n execution id.

Same x-request-id → Mibo replaces the previous trace. Different ID → new trace.

Include Metadata

Attaches extra context (environment, version, custom key-value pairs) to the trace’s metadata object.

Options → Timeout

How long the node waits for the POST before giving up. Fire-and-forget — your workflow’s response to the end user is not affected if Mibo is unreachable.

What the node emits

For each captured workflow node, the trace includes one span:

• name — n8n display label (e.g. “AI Agent”, “HTTP Request”, “Send Confirmation Email”).
• parent_span_id — derived from the n8n connection graph. Filtered ancestors are skipped to the nearest captured one.
• attributes:
  • n8n.node.type — internal type (e.g. n8n-nodes-base.httpRequest).
  • n8n.node.status — success / error.
  • n8n.node.output — JSON-stringified output.
  • n8n.node.parameters — resolved parameters (requires n8n API key).
  • For the response-producing node: gen_ai.response.text and gen_ai.output.messages.

Internal utility node types are auto-excluded.

Verifying it works

1. Save your workflow with the node configured.
2. Run the workflow once manually or via a test trigger.
3. Check Mibo — open your project’s Traces page. You should see a new trace with source: custom_api and one span per captured node.

If the trace doesn’t appear:

• API key — verify it matches what’s in your Mibo project.
• Agent ID / scoping — a multi-agent key with no Agent ID returns 400.
• Node enumeration — if neither the n8n API Key nor a Get Workflow node is wired in, the node throws; check the execution log.
• Workflow ran — the node only fires when it’s actually reached.

Note

The node only sends data when the workflow executes. Saving or editing without running doesn’t send anything.

---

Option 3 — HTTP Request node (any version)

Send traces from any n8n workflow using the built-in HTTP Request node — no community package, no host config. Works on n8n Cloud and self-hosted, any version.

You add one HTTP Request node at the end of your workflow. It sends Mibo a small JSON describing what your workflow just did, and Mibo runs your test cases against it. You don’t need to know OpenTelemetry or anything about tracing — copy the body below, change one field, you’re done.

Step-by-step

1. Add the node. At the end of your workflow, add an HTTP Request node (any name).

2. Set Method to POST and URL to:

   https://api.mibo-ai.com/public/traces

3. Add these three headers:

   Name	Value
   x-api-key	your Mibo API key
   content-type	application/json
   x-request-id	{{ $execution.id }}

4. Set Body Content Type to JSON, turn on JSON body with expressions, and paste the minimal body below.

5. Turn on Continue On Fail. If Mibo is ever down, your workflow won’t fail.

That’s it. Save the workflow, run it, and the trace shows up in your project’s Traces page within seconds.

Minimal body

Copy this. Replace 'Final Reply' with the display name of the node whose response you want Mibo to evaluate, and .json.output with the field that holds the reply text.

{
  "platformId": "<your_platform_uuid>",
  "spans": [{
    "span_id": "{{ $execution.id }}-root",
    "name": "My Support Workflow",
    "attributes": {
      "gen_ai.response.text": "{{ $('Final Reply').item.json.output }}"
    },
    "status": { "code": 1 }
  }]
}

What you need to know:

• platformId — your agent’s UUID, from the dashboard. If your API key is already scoped to a single agent, you can drop this field.
• name — what you’ll see in the dashboard. Use a label your team will recognise.
• gen_ai.response.text — the reply text. Mibo’s semantic and regex checks read from here.
• x-request-id header — n8n’s execution id. Retries with the same id update the same trace (no duplicates).

You’ll get back {} and a 2xx status. The trace is accepted; evaluation runs automatically.

If you want to also track…

Add the matching attribute to the same attributes object. None of these are required — only add what you care about.

…token usage

"gen_ai.usage.input_tokens": 120,
"gen_ai.usage.output_tokens": 80

Powers the token limit check. Pull the real numbers from your AI node’s output (e.g. {{ $('AI Agent').item.json.usage.input_tokens }}).

…response time

Add start_time_unix_nano and end_time_unix_nano to the span (nanoseconds, as strings):

"start_time_unix_nano": "{{ String(Date.parse($execution.startedAt) * 1000000) }}",
"end_time_unix_nano":   "{{ String($now.toMillis() * 1000000) }}"

Powers the response time check.

…HTTP status

"http.response.status_code": 200

Powers the HTTP status check. Useful when your workflow ends with an API call.

…tools the AI agent called

Add one extra span per tool, pointing at the AI span with parent_span_id:

{
  "span_id": "{{ $execution.id }}-tool-1",
  "parent_span_id": "{{ $execution.id }}-root",
  "name": "create_booking",
  "attributes": {
    "gen_ai.tool.name": "create_booking",
    "gen_ai.tool.call.arguments": "{\"date\":\"2026-06-12\",\"party\":4}"
  },
  "status": { "code": 1 }
}

Powers tool call checks — the AI used the right tool with the right arguments.

…other workflow nodes (so test cases can assert on them)

Add one span per node you care about, all with parent_span_id pointing at your root span. name should match the node’s display label in n8n — your node_call checks search by name.

…whether the workflow failed

Set "status": { "code": 2 } on any span that errored. Mibo marks the whole trace as failed.

For everything else — custom attributes, deep nesting, JSON-schema checks on payloads — see Your API reference and the Canonical Trace Reference.

When things go wrong

You see	What it means	Fix
400 VALIDATION_ERROR	Body is missing spans, or a span is missing span_id / name.	Re-check the body shape.
400 CUSTOM_API_PLATFORM_NOT_FOUND	Mibo can’t decide which agent this trace belongs to.	Add platformId (UUID from the dashboard), or use an API key scoped to one agent.
401 UNAUTHORIZED	Wrong, missing or expired API key.	Re-check the x-api-key header.
413 PAYLOAD_TOO_LARGE	Body is bigger than 30 MB.	Trim or skip large fields (full node outputs are the usual culprit).
5xx	Temporary server issue.	Mibo is fine with retries — same x-request-id won’t create duplicates.
Trace doesn’t show up	Workflow didn’t reach the HTTP node, or the API key belongs to a different project.	Run the workflow once manually and watch the HTTP node’s output.

Note

Prefer raw OpenTelemetry? The same Mibo endpoint also accepts the standard OTLP/HTTP JSON envelope used by all OpenTelemetry SDKs. That path routes by the service.name resource attribute, not platformId. If you already have an OTel exporter, see the OTLP guide instead.

---

Once traces are arriving, Mibo evaluates each one against your active test cases automatically. See Passive Testing for details.

Your API reference The canonical {spans:[...]} shape the Testing Node emits.

OTLP deep-dive Full OTLP exporter config, batching, and payload details.

Source Code The Testing Node is open source. View the code, report issues, or contribute.