n8n published [email protected] on August 3, 2026. The release corrects the Onfleet Trigger Node setup response by sending its validation token as text/plain, a narrow fix for operators whose Onfleet trigger registration depends on the expected content type.
The full release notes and downloads are on the GitHub release page.
Validation now uses plain text ¶
The runtime change is in packages/nodes-base/nodes/Onfleet/OnfleetTrigger.node.ts. During the setup webhook request, the node still reads req.query.check, returns status 200, and sends that value as the response body. It now calls .type('text/plain') before .send(req.query.check).
That explicit MIME type is the entire production code change. The response value, status code, and noWebhookResponse behavior remain in place. The node therefore continues to own the validation response instead of passing response handling back to the general webhook path.
For platform operators, the important boundary is webhook registration. This patch does not alter the data emitted by later Onfleet events. It changes the HTTP contract used while Onfleet checks the endpoint. The release records the work under issue 24878, with the implementation in commit a71b153.
Regression coverage checks both webhook paths ¶
The commit also adds packages/nodes-base/nodes/Onfleet/test/OnfleetTrigger.node.test.ts. Its setup case supplies validation-token-123 through the check query parameter. The assertions require status(200), type('text/plain'), and the same token in send().
The test also checks that the setup path returns { noWebhookResponse: true }. That assertion matters because setting the correct header would not be sufficient if the framework later attempted to produce a second response.
A separate case covers normal webhook delivery. It passes sample taskId, workerId, and actionContext fields through getBodyData() and checks that the node returns them as workflow data through helpers.returnJsonArray. This provides a useful scope check: validation response handling changed, while the normal event payload path stayed intact.
The runtime diff is one line, while the new test file adds 75 lines. That ratio fits the failure mode: the implementation is small, but the response contract now has an exact assertion. It also keeps review and rollback scope limited to this connector.
If registration still fails, inspect the public webhook endpoint, not only the direct n8n listener. A reverse proxy or ingress can alter response headers after n8n emits them. Compare the public response with the internal service response before attributing a mismatch to the node. The commit defines the application response call, not every network hop in front of it.
Release scope and operator checks ¶
This is a stable release, not a release candidate, beta, or alpha. The notes list one bug fix and identify it as a backport to the 1.x line. They do not list breaking changes, schema migrations, new configuration keys, credential changes, or workflow edits.
Operators using the Onfleet Trigger Node should retest node activation after the update. A focused check should confirm that setup returns status 200, the response carries Content-Type: text/plain, and the body contains the check query value. A normal Onfleet event should still enter the workflow as JSON data.
Operators who do not use the Onfleet integration have no operator visible change identified in these notes. There are no listed changes to the n8n scheduler, execution engine, database layer, or other nodes. Treat this as a connector boundary fix rather than a general platform maintenance release.