n8n workflows

The official community package is n8n-nodes-factuarea, version 0.1.2 in the September 2026 release baseline. It requires Node.js 22+. It provides a Factuarea credential and an event trigger; use n8n’s HTTP Request node for other REST operations.

Install and subscribe

Install the package through Community Nodes in your n8n instance. Create a Factuarea credential with an API key containing events:read, webhooks:read, webhooks:write and webhooks:delete. Add the Factuarea Trigger, select the credential and choose event types from the catalog. Activating the workflow creates its webhook endpoint; deactivating it removes the endpoint owned by that trigger.

Expose the n8n webhook through public HTTPS. Private addresses and local-only destinations are rejected; an outbound-host exception for a store does not enable private webhook delivery. Test credentials record events but do not deliver public webhooks, so use a controlled live scenario to verify end-to-end delivery.

Use the event snapshot

For a paid-invoice workflow, subscribe to invoice.paid, then map the resource from data.object. The event’s id identifies the notification; data.object.id identifies the invoice. For store events, data.order.external_id identifies the provider order. Persist the event ID in your own system before applying a non-repeatable effect.

{{ $json.id }}
{{ $json.type }}
{{ $json.data.object.id }}
{{ $json.data.object.total }}

Signatures and recovery

The trigger checks HMAC over the raw request body and validates the signature timestamp. The default tolerance is 300 seconds, configurable from 30 to 3600. Its active-node deduplication keeps the latest 1000 event IDs in memory; it does not replace persistent deduplication across restarts.

After rotating the endpoint secret, deactivate and reactivate the trigger so it receives the new secret; dual signatures only cover the 24-hour grace period. If activation times out, inspect the endpoint list before retrying because creation may have succeeded. Repeated permanent delivery failures can degrade or suspend an endpoint; fix the cause and explicitly recover it. See webhook delivery and the package limitations.

Listen to a whole account

The same trigger has two modes. Listen On is Company by default, which is everything described above: one company, and a workflow saved before the option existed behaves that way. Set it to Account and the trigger registers an account webhook when the workflow is activated and removes it when the workflow is deactivated, so the workflow hears the events of the whole account: its own tax IDs and the accounts it manages. The package still declares one node and one credential; account mode is a mode of the same node, not a second node. The mode is read on activation, so after switching it, activate the workflow again.

The credential needs the same four scopes as in company mode (events:read, webhooks:read, webhooks:write and webhooks:delete).

Name the account

Type the account UUID in Account ID on the node, or in Default Account ID on the credential; when both are filled, the node wins. The trigger never deduces the account from the API key. With both empty it refuses to activate and names the two fields. The UUID of the active account appears in the example cURL request of Settings → Developers.

Events and filters

• Events offers the public event catalog plus the fixed list of fifteen account.* events that the package carries, because no catalog route serves them. A new account.* event reaches the picker only with a newer package version. Company mode offers none of them.
• Account Relationship takes own, managed or all (default all). It is sent when the endpoint is created and stays fixed for it. Each delivered event says whether it is own or managed, never all.
• Company ID Filter is optional and takes the UUID of one tax ID of the account. When it is filled, a signed delivery whose company_id is another one is answered with 200 and dropped without starting the workflow, so Factuarea does not retry it. An event of the account itself, such as account.member_added, has no company_id and always starts the workflow. The filter runs after the signature check and before deduplication, and it only filters what the trigger emits: the endpoint still receives every event of the account.

The emitted item adds account, account_relationship and company_id to the event:

{{ $json.type }}
{{ $json.account.id }}
{{ $json.account_relationship }}
{{ $json.company_id }}

Signature of account deliveries

An account delivery is verified exactly like a company one: the same HMAC over the raw body, the same tolerance, the same acceptance of two signatures during a rotation and the same deduplication by event ID. Its envelope adds account ({ "id": … }), account_relationship (own or managed) and company_id, which is null for an event of the account itself. The delivery also carries the Factuarea-Account-Relationship header, with the same own or managed value. The same tax ID event delivered to a company endpoint and to an account endpoint has the same id in both. See the envelope and its headers.

Requirements and rejections

OAuth is out of scope: the credential is an API key, and an OAuth connection is not an account credential. A test account endpoint can only be created from the Factuarea dashboard.

Package version

Account mode is part of the target version 0.2.0 of the package, listed as unreleased in its changelog together with the company axis. The 0.1.2 version above does not include it, and this guide does not state that 0.2.0 is published.