@riga-solutions/n8n-nodes-riga

An n8n community node for RIGA — send tracked documents, append
records to a verifiable chain, and connect the lifecycle of your datarooms to any of
n8n's integrations.

RIGA records are entries in a verifiable authorization chain; every webhook delivery is
HMAC-signed and this node verifies the signature before your workflow runs.

Every operation is thin routing over the public /api/v1 REST surface — the same
surface the SDK and the Zapier app use.

Nodes

RIGA Trigger — starts a workflow when a RIGA event fires. Registers a webhook
against your account automatically (create / checkExists / delete lifecycle), so there
is no URL to paste. Events:

send.viewed · send.downloaded · send.created · send.revoked · send.expired ·
record.appended.* · record.corrected.* · record.retracted.* · dataroom.opened ·
dataroom.closed · participant.accepted · task.assigned · task.completed ·
qa.opened · resolution.proposed · consent.signed · delegation.granted ·
delegation.revoked · *

RIGA — actions:

• Send Document takes the file from a binary property (Google Drive, an email
  attachment, an HTTP response), or from a URL or base64 string. RIGA encrypts and
  hosts it, returns the recipient link, and reports every view, download and expiry as
  an event.
• Append Record is the notary act: you bring the content and an opaque pointer to
  your own object (external_resource — e.g. pennylane.invoice / INV-2026-114),
  RIGA apposes the author, the canonical hash, the chain position and the timestamp.
  One dataroom is one chain.
• Attest Record is the grounded variant: the attestation cites the exact document
  bytes it was derived from (grounded_document_hashes), and RIGA checks each hash
  against a recorded read by the same caller before accepting it.
• Upload Document is one-call ingest — the bytes ride the request, RIGA drives
  encrypt → dedup → chain event asynchronously; poll Get Upload Status until
  ready. Get (document read) requires the authorizing task_id: reads root in
  tasks, and the recorded read is what later grounds an attestation.
• Export Chain streams the whole ordered chain (seq #1→head) as one item per
  event, in the exact shape @val-protocol/chain-verifier consumes — a third party
  drops the output straight into the verifier, RIGA-dark.
• Propose Resolution submits a settlement text for the parties to consent to.
  The consent itself stays a human ceremony (see below) — the workflow proposes,
  Get Consents reports who has bonded and at which instrument grade.

Resources are listed alphabetically because n8n's verified-node lint requires it; Send is
the node's default because sends and records are the two operations that need no dataroom
parcours to be useful.

Usable as an AI Agent tool

Both nodes declare usableAsTool, so an n8n AI Agent can call RIGA directly. What the
agent does then lands on the chain as an attributable record — the agent acts under the
credential's authority, and its actions carry an author, a canonical hash and a chain
position like any other. The boundary in the next section holds for agents too.

By design, never actions

Consent, signature, ratification and retraction are personal acts. A workflow node is a
machine principal by construction, so these are not exposed here and will not be — and
attaching the node to an AI Agent does not change that. Access and delegation changes are
governance acts recorded on the chain, not workflow side effects.

Credentials

Create a RIGA API credential with:

• API Key — a riga_sk_* key from the RIGA developer console. Scopes:
  webhook:write + webhook:read (Trigger), share.send (Send), record.propose
  (Record, Task), dataroom:create (Dataroom, Mediation), send.read /
  send.revoke (send list and revoke).
• Base URL — https://api.riga.solutions/api, or
  https://dev.riga.solutions/api for development.
• Webhook Signing Secret — optional; the Trigger manages its own per-webhook secret.

The credential test calls GET /v1/usage.

How the trigger works

The trigger implements n8n's webhookMethods:

• create → POST /v1/webhooks { url, event_types }, storing the returned id +
  signing_secret.
• checkExists → GET /v1/webhooks/:id (404 ⇒ re-create).
• delete → DELETE /v1/webhooks/:id.

Incoming deliveries are verified against the Webhook-Signature header
(t=<unix>,v1=HMAC-SHA256(secret,"<t>.<body>"),kid=<sha256(secret)[:8]>). During a
secret rotation the header carries several (v1,kid) pairs; the node matches the pair
whose kid is its own.

Install

Community nodes: Settings → Community Nodes → Install @riga-solutions/n8n-nodes-riga.
Self-hosted from source: npm install, npm run build, then load the dist/ output.

Publishing and community-node verification

n8n discovers community nodes from npm; the verified badge is a separate review.

1. Build and inspect the artifact. npm run build, then npm publish --dry-run
   and confirm the tarball carries dist/, README.md, CHANGELOG.md and the
   licence files.
2. Publish. npm publish --access public. Judge the result by exit code and a
   registry probe (npm view @riga-solutions/n8n-nodes-riga version), never by stdout — the success
   line is identical in a dry run.
3. Submit for verification at n8n community node
   verification
   once the package is live. n8n checks that the package name begins with
   n8n-nodes-, that keywords contains n8n-community-node-package, that the
   n8n manifest block lists every credential and node path, that the node has no
   runtime dependencies beyond n8n-workflow, and that a licence file ships.
4. After verification, the node appears in the in-app node panel for cloud
   users; before it, self-hosted users install it by package name.

Requirements this package already satisfies: n8n-nodes- prefix, the community
keyword, n8nNodesApiVersion: 1, credential and node paths under dist/, and
n8n-workflow as a peer dependency only.

License

Apache-2.0