Description

n8n-nodes-furious


This is an n8n community node package for Furious Squad — the all-in-one ERP for agencies, studios and consulting firms (CRM, proposals, projects, time tracking, invoicing, purchasing, HR). It lets you automate your own Furious instance natively from your n8n workflows.

It ships three nodes:

• Furious — covers the whole Furious REST API v2: 87 resources with Create / Get Many / Update / Delete operations (where the API supports them), plus a Custom API Call escape hatch for anything else
• Furious Trigger — starts workflows on Furious webhook events (real time), with optional shared-secret verification, event filtering and automatic fetching of the full record behind the event
• Furious Polling Trigger — starts workflows when records are created or updated in any searchable Furious resource, with no webhook configuration at all; every workflow can have its own polling trigger

> 🏢 Furious is instance-based: your credential points to your instance URL (e.g. https://your-agency.furious-squad.com). The exact modules and permissions available depend on your instance and on the API user you connect with.

Installation · Compatibility · Credentials · Resources & operations · Usage · Furious Trigger · Polling Trigger · Limitations · Development · Version history

Installation

Follow the installation guide in the n8n community nodes documentation.

Self-hosted n8n: go to Settings > Community Nodes > Install, enter n8n-nodes-furious and confirm.

Compatibility

• Minimum n8n version: 1.86.0 (the nodes use the NodeConnectionTypes API, which older versions do not provide). Developed and tested against n8n 1.x releases of 2026.
• The package has no runtime dependencies and only talks to the Furious instance configured in the credential.
• To use the Furious node as a tool for AI Agents on self-hosted n8n, set the environment variable N8NCOMMUNITYPACKAGESALLOWTOOL_USAGE=true.

Credentials

Create a Furious API credential with:

| Field | Description |
| —————- | ———————————————————————————– |
| Instance URL | The base URL of your Furious instance, e.g. https://your-agency.furious-squad.com |
| Username | The username of a Furious API user |
| Password | The password of that API user |

The node authenticates against POST /api/v2/auth/ and sends the returned JWT in the F-Auth-Token header on every request. Tokens expire after 1 hour — n8n fetches and renews them automatically; you never handle tokens yourself.

> 🔐 The permissions of the API user determine which modules the node can read and write. If a request fails with a permission error, review the API user’s rights in Furious.

The credential can also be used with n8n’s generic HTTP Request node (predefined credential type) to call any Furious endpoint manually.

Resources & operations

Operations map 1:1 to the Furious API v2 actions:

• Create → POST /api/v2// with {"action": "create", "data": {...}}
• Get Many → GET /api/v2//?query={Entity(filter,limit,offset,order){fields}}
• Update → PUT /api/v2// with {"action": "update", "data": {"id": ..., ...}}
• Delete → DELETE /api/v2// with {"action": "delete", "data": {"id": ...}}

CRM & Sales

| Resource | Create | Get Many | Update | Delete |
| ————————— | :—-: | :——: | :—-: | :—-: |
| CRM Cutoff Pipeline | | ✓ | | |
| CRM History | | ✓ | | |
| CRM Interaction | ✓ | ✓ | | |
| Campaign | ✓ | ✓ | ✓ | |
| Client (CRM) | ✓ | ✓ | ✓ | |
| Client Objective | ✓ | ✓ | ✓ | |
| Client Opportunity | ✓ | ✓ | ✓ | |
| Company | ✓ | ✓ | ✓ | ✓ |
| Contract | ✓ | ✓ | | |
| External Email | | ✓ | | |
| Opportunity Cutoff Pipeline | | ✓ | | |
| Opportunity History | | ✓ | | |
| Opportunity Relation | | ✓ | | |

Proposals

| Resource | Create | Get Many | Update | Delete |
| ———————- | :—-: | :——: | :—-: | :—-: |
| Proposal | ✓ | ✓ | ✓ | |
| Proposal Addon | ✓ | ✓ | | |
| Proposal History | | ✓ | | |
| Proposal PDF | | ✓ | | |
| Proposal Rate Card | ✓ | ✓ | ✓ | ✓ |
| Quotes Cutoff | | ✓ | | |
| Quotes Cutoff Pipeline | | ✓ | | |

Projects & Todos

| Resource | Create | Get Many | Update | Delete |
| ————————- | :—-: | :——: | :—-: | :—-: |
| Document | ✓ | ✓ | | |
| Predefined Todo List | ✓ | | | |
| Project | ✓ | ✓ | ✓ | |
| Project Advancement | ✓ | ✓ | | |
| Project Cutoff | ✓ | ✓ | | |
| Project Cutoff BU | ✓ | ✓ | ✓ | |
| Project Gantt Phase | ✓ | ✓ | ✓ | |
| Project KPI | | ✓ | | |
| Project Rate Card | ✓ | ✓ | ✓ | |
| Project Rate Card History | ✓ | ✓ | ✓ | |
| Time Category | ✓ | ✓ | ✓ | |
| Todo | ✓ | ✓ | ✓ | |
| Todo Category | ✓ | ✓ | ✓ | |
| Todo Comment | ✓ | ✓ | ✓ | |
| Todo Task | ✓ | ✓ | ✓ | |

Time Tracking

| Resource | Create | Get Many | Update | Delete |
| ——————- | :—-: | :——: | :—-: | :—-: |
| External Time Entry | | ✓ | | |
| Time Entry | ✓ | ✓ | ✓ | ✓ |

Invoicing & Purchasing

| Resource | Create | Get Many | Update | Delete |
| —————– | :—-: | :——: | :—-: | :—-: |
| Accounting Split | ✓ | ✓ | | |
| Invoice | ✓ | ✓ | ✓ | |
| Invoice Milestone | ✓ | | ✓ | ✓ |
| Invoice PDF | | ✓ | | |
| Partial Invoice | ✓ | ✓ | | ✓ |
| Partial Purchase | ✓ | ✓ | ✓ | |
| Purchase | ✓ | ✓ | ✓ | |
| Purchase History | ✓ | ✓ | | |
| Purchase PDF | | ✓ | | |
| Purchase Type | | ✓ | | |

Finance & Accounting

| Resource | Create | Get Many | Update | Delete |
| ———————- | :—-: | :——: | :—-: | :—-: |
| Accounting Export | | ✓ | | |
| Cash Planner | | ✓ | | |
| Currency Exchange Rate | | ✓ | | |
| Cutoff AI | | ✓ | | |
| Cutoff BU Period | | ✓ | | |
| Cutoff Entity Period | | ✓ | | |
| Financial Flow | | ✓ | | |
| Tax | | ✓ | | |
| Unpaid Invoices KPI | | ✓ | | |

HR & People

| Resource | Create | Get Many | Update | Delete |
| ————————– | :—-: | :——: | :—-: | :—-: |
| Absence | ✓ | ✓ | ✓ | |
| Absence Balance | ✓ | | | |
| Archived User | | ✓ | ✓ | |
| Availability KPI | | ✓ | | |
| CJM History | | ✓ | | |
| Cancelled Absence | | ✓ | | |
| Candidate Skill | ✓ | ✓ | ✓ | |
| Evaluation | | ✓ | | |
| Public Holiday | ✓ | ✓ | ✓ | |
| Skill | ✓ | ✓ | ✓ | |
| TJM History | | ✓ | | |
| Team | ✓ | ✓ | ✓ | |
| User | ✓ | ✓ | ✓ | |
| User Contract | ✓ | ✓ | | |
| User Daily Cost History | ✓ | ✓ | ✓ | ✓ |
| User Daily Hours History | ✓ | ✓ | ✓ | ✓ |
| User Diploma History | ✓ | ✓ | | |
| User Medical Visit History | ✓ | ✓ | | |
| User Production KPI | | ✓ | | |
| User Salary History | ✓ | ✓ | ✓ | ✓ |
| User Skill | ✓ | ✓ | ✓ | |
| User Tax History | ✓ | ✓ | ✓ | ✓ |

Workspace & Organization

| Resource | Create | Get Many | Update | Delete |
| ———————- | :—-: | :——: | :—-: | :—-: |
| Business Unit | | ✓ | | |
| Desk Booking | | ✓ | | |
| Entity | | ✓ | | |
| Equipment Room | | ✓ | | |
| Equipment Room Booking | ✓ | ✓ | ✓ | ✓ |
| Event | | | ✓ | |
| Knowledge Base | ✓ | ✓ | ✓ | ✓ |
| Permission | | ✓ | ✓ | |
| Post-It | ✓ | ✓ | ✓ | ✓ |

Usage

Get Many (search)

• Fields to Return — pick the fields you need; leave empty to request all documented fields of the module.
• Filters — add conditions on any filterable field. Conditions on different fields are combined with AND; two conditions on the same field are merged (e.g. Greater Than or Equal + Less Than = range). Operators map to the Furious query language: Equals eq, Not Equals neq, Contains like, Does Not Contain nlike, In in, Not In nin, Less Than le, Less Than or Equal leq, Greater Than gt, Greater Than or Equal gte, Is Null null.

– For In / Not In, enter a comma-separated list (12,13,14).
– For Is Null, enter true or false.

• Return All / Limit — the node paginates automatically with limit/offset (up to 250 items per request) until everything (or your limit) is fetched.
• Options > Sort — order results by one or more fields. ⚠️ Furious requires sorted fields to be part of the returned fields.
• Options > Offset — skip results from the start.

Create / Update

• Required fields are top-level parameters; everything else is under Additional Fields (create) or Update Fields (update).
• Date fields use the YYYY-MM-DD format.
• Array fields (tags, assigned people, byentity, customfields…) accept either a comma-separated list (tag1,tag2) or a JSON array ([{"myentity": 1}], [{"name": "mtier", "value": "..."}]). For byentity fields, the object keys are the entity slugs of your instance.
• JSON Parameters — flip this switch to provide the data payload as raw JSON instead of individual fields. You can pass a single object or an array of objects (multi-batch): the Furious API accepts up to 10 elements per request, and the node automatically chunks larger arrays into successive requests of 10.
• On update, only the fields you set are modified; id is always required (a few modules use a different key, such as id_system for invoice milestones — the node exposes the right one).

Delete

Available on the modules that support it (Company, Time Entry, Invoice Milestone, Partial Invoice, Knowledge Base, Post-It, Equipment Room Booking, Proposal Rate Card, user history modules…). Provide the ID of the element to delete.

Custom API Call

A raw escape hatch for anything not covered: choose the HTTP method, an endpoint relative to your instance (e.g. /api/v2/crm/), optional query parameters and body as JSON. Authentication is applied automatically. Example search query parameter:

{ "query": "{Clients(filter:{lastname:{like:"dupont"}},limit:25){lastname,firstname,email}}" }

Error handling

Furious replies 200 OK with success: false and a message when a write is rejected — the node turns this into a proper n8n error (and plays nicely with Continue On Fail). Multi-batch responses are returned as-is, one result item per element, each with its own success flag; if every element of a batch fails, the node throws instead.

Furious Trigger

Furious can call a webhook whenever one of its events fires (proposal created, invoice paid, absence requested…). Webhooks are configured by hand in the Furious UI — there is no registration API — so setting up the trigger takes three steps:

1. In Furious, enable the webhook service: Configuration > General configuration > Webhook configuration.
2. Open Configuration > Messages & Automation > Events configuration, edit the event you want, and select the webhook channel.
3. Paste the production webhook URL shown on the Furious Trigger node, and pick the variables to send — they become the fields of the payload your workflow receives.

Three options make the trigger more robust:

• Expected Token — Furious does not sign its webhook calls. Add a webhook variable (default name token) with a secret value in the Furious event configuration and set the same value here: calls that do not carry the correct value are rejected with a 401, and the token is stripped from the workflow data.
• Only Events — a comma-separated list of accepted values for the event field (default field name event, configurable). Calls whose event does not match are acknowledged with a 200 but do not start the workflow. Add an event variable identifying each event in the Furious event configuration to use this.
• Fetch Full Record — Furious webhooks only carry the variables you selected, often just an ID. Turn this on (with a Furious API credential) and the trigger looks up the complete record (all documented fields) for the resource of your choice, delivered under record next to the raw payload. If the lookup fails, the event is still delivered, with an enrichError field explaining why.

You can monitor and replay webhook deliveries in Furious under Configuration > Logs > Webhook access.

One webhook URL, many workflows (hub pattern)

Furious sends all webhook events to a single URL, and in n8n a webhook URL belongs to a single active workflow — two workflows cannot listen on the same URL (this is an n8n platform constraint, common to all integrations limited to one webhook destination). To drive several workflows from Furious events, use a hub:

1. In each Furious event configuration, add an event variable identifying the event (e.g. proposalcreated, invoicepaid) next to the variables you need.
2. Create one hub workflow: a Furious Trigger (its URL is the one — and only — URL you paste in Furious), followed by a Switch node routing on {{ $json.event }}.
3. Behind each Switch branch, call the target workflow with Execute Sub-workflow. The sub-workflows start with the core When Executed by Another Workflow trigger and receive the full payload (including record if the hub enriches).

The URL registered in Furious never changes again: you can add, remove or rework sub-workflows freely without touching the Furious configuration. For simple setups with a single workflow, skip the hub and use Only Events directly on the trigger.

Furious Polling Trigger

The polling alternative to webhooks: it checks the Furious search API on a schedule (n8n’s standard Poll Times parameter, down to every minute) and emits only what changed since the previous run. Nothing to configure in Furious, and — unlike webhooks, which are limited to one URL per instance — every workflow can have its own polling trigger.

Pick an Event and a Resource:

• New Item — fires once per newly created record, tracked by a strictly increasing ID watermark (any searchable resource with an id field — 62 of them). No duplicates; no gaps unless the API exposes IDs out of creation order (concurrent writes committing late).
• Updated Item — fires when a record’s update date moves forward, tracked by an updatedat / lastupdateat / lastupdated_at watermark (only resources exposing such a field are offered). ⚠️ On most modules Furious documents these fields with day precision (Y-m-d): a record then fires at most once per day it is updated, and repeated same-day edits are coalesced. Modules with datetime precision (Company, Client Opportunity…) track to the second.

Behavior details:

• On first activation the trigger initializes its watermark from the current data without backfilling — only records created/updated after activation fire.
• Executing the node manually in the editor returns the 10 most recent records as samples, without touching the watermark.
• Records are delivered with all documented fields of the resource.
• Options > Max Items (default and maximum 250, the API page size) caps how many records one poll run fetches; any backlog is drained by the following runs, including days where more than 250 records change.
• Changing the watched resource or event resets the watermark automatically.
• Delivery is at-least-once: rare edge cases (or reactivating a workflow after a pause) can re-emit a record — deduplicate downstream on id if your workflow is not idempotent. Malformed or far-future update dates are ignored by the watermark so a single bad record cannot stall the trigger.
• n8n persists trigger state together with executions: restarting n8n between the trigger’s activation and its first emission may re-initialize the watermark (records from that short window are skipped). This is standard n8n polling behavior.

Webhook trigger vs polling trigger: webhooks are real time and event-shaped (use them, with the hub pattern, when latency matters); polling adds up to one poll interval of latency but needs zero Furious configuration and scales to any number of independent workflows.

Known limitations

• Webhook registration is manual. The Furious API has no endpoint to create webhooks, so the Furious Trigger cannot register itself — follow the three steps above. Deactivating the n8n workflow does not stop Furious from calling the (now dead) URL; disable the webhook channel in Furious too.
• Instance-specific values. Some enum values shown in field descriptions (entity slugs shown as my_entity, custom field names, purchase types…) depend on your instance — check your own instance’s API documentation (Furious > Configuration > API) for your values.
• Some modules are read-only (search only: KPIs, cutoffs, histories, PDFs…) and a few are write-only (e.g. Absence Balance, Predefined Todo List, Invoice Milestone) — the operation list of each resource reflects exactly what the API documents.
• Opportunity Relation searches require a filter on opportunity_id (API constraint).

Development

The per-resource descriptions are generated from scripts/api-spec.json, a machine-readable extraction of the official Furious API documentation (206 pages):

npm run generate   # regenerate nodes/Furious/descriptions/* and nodes/Furious/resources.ts
npm run format
npm run lint:fix
npm run build

To update the node after a Furious API change: edit scripts/api-spec.json (or re-extract it from the updated PDF), then run the pipeline above.

Resources

• Furious Squad
• n8n community nodes documentation
• Your instance’s API documentation: Furious > Configuration > API

Version history

• 1.2.0 — n8n Cloud verification readiness: passes @n8n/scan-community-package with zero findings; the token-expiry re-authentication was restructured (Furious signals expiry as HTTP 200, so the node refreshes the token itself and retries once); all errors are now proper n8n error types. ⚠️ The webhook trigger’s Token Field parameter was renamed to Verification Field — re-select your field name there if you had changed it from the default token.
• 1.1.0 — new Furious Polling Trigger node (New Item / Updated Item watermarks, no webhook configuration needed).
• 1.0.2 — webhook trigger: Only Events filter and hub-pattern documentation for running many workflows behind the single Furious webhook URL.
• 1.0.1 — full English wording pass; instance-specific values genericized.
• 1.0.0 — initial release: Furious node (87 resources), Furious Trigger (webhook), credential with automatic token renewal.

License

MIT — © Picture Element / Ben Gosciniak

Disclaimer

This is a community package, not an official Furious Squad product. Furious and the Furious logo are trademarks of their respective owners.