REST integration: trigger matching from your systems

Stylised view: request to the session run API, immediate response or queued run depending on configuration.

This guide is for technical teams that automate close workflows. It explains how to launch a matching run for a session already created in Ninon, without going through the dashboard flow.

Authentication

Two modes: a signed-in user whose role may act on the session (group admin or member; the viewer role is denied for this endpoint), or a machine call with Authorization: Bearer followed by the server-side run secret supplied to your IT team in Ninon’s deployment documentation. The session id in the URL must belong to your organisation.

Trigger a run

Method POST. Path /api/reconciliation/[sessionId]/run — replace [sessionId] with the session UUID from the dashboard. The request body may be empty.

HTTP responses

When a background job queue is configured on the hosting and you do not force synchronous mode, the response is HTTP 202 with queued: true and queue identifiers. Otherwise the work runs in-process: HTTP 200 with queued: false and statistics. To force a synchronous run even when a queue is configured, use the sync=1 query parameter or the x-sync-matching: true header. Without a queue key, behaviour stays synchronous (200).

Inngest workers

Hosted deployments that process background jobs expose a worker endpoint at a fixed path under this site (see hosting runbook). That endpoint is separate from the business call that starts a reconciliation run for a session.