n8n-nodes-rise-crm

The n8n community node for RISE CRM. Add RISE CRM to your n8n canvas as a first class node and build RISE CRM automation the same way you would with any built in integration: pick a resource, pick an operation, connect it up.

This package gives you a complete n8n RISE CRM integration in two nodes:

• RISE CRM - read and write clients, leads, invoices, invoice payments, estimates, proposals, projects, tasks, tickets, timesheets and custom fields.
• RISE CRM Trigger - a polling trigger that starts a workflow when records are created or, where RISE tracks it, updated.

Keywords people search for and land here on: n8n RISE CRM, RISE CRM automation, RISE CRM integration, n8n node for RISE CRM, RISE CRM API n8n, connect RISE CRM to n8n, RISE CRM webhooks and workflows.

---

⚠️ Requires the paid "REST API for RISE CRM" plugin

This node cannot talk to a stock RISE CRM installation. RISE CRM does not ship a REST API. This node is a client for the commercial plugin that adds one:

REST API for RISE CRM - by Themesic Interactive

Buy or read the full feature list here:
https://themesic.com/product/rest-api-plugin-for-rise-crm-connect-rise-with-third-party-applications/

Install and activate that plugin (version 2.1.0 or newer) on your RISE CRM installation first. Without it there are no /api routes to call, so every request from this node fails and the credential test cannot pass.

The node package itself is free and MIT licensed. The plugin it talks to is a separate paid product. That is the honest split, stated up front so nobody wastes an afternoon.

Other Themesic products for RISE CRM: https://themesic.com/products/

---

What you get

The plugin exposes 35 CRM resources - 34 of them with full CRUD and search, plus activity-logs, which is an audit trail and is therefore read only (list, get, search). On top of those sit 27 platform endpoints: MCP (2), Webhooks (8), Reporting (5), Custom Fields (4), Automation (3), Tooling (3), OpenAPI (1) and Batch (1). Plugin 2.1.0 adds ten more groups - line items, knowledge base, checklists, files, estimate and proposal comments, team, project members, roles and templates - for 54 endpoint groups and 322 documented endpoints in total. This node puts the most used slice of that surface behind a dropdown, and the rest stays one HTTP Request node away using the same credential.

Nodes in this package

Node	Type	What it does
RISE CRM	Action	Get Many, Get, Search, Create, Update and Delete against the real REST routes
RISE CRM Trigger	Polling trigger	Starts a workflow from GET /api/automation/poll/:resource

The RISE CRM node is also marked usableAsTool, so an AI Agent node can call it as a tool in n8n.

---

Installation

In the n8n UI (self hosted)

1. Go to Settings > Community Nodes.
2. Select Install.
3. Enter n8n-nodes-rise-crm.
4. Agree to the risks of using community nodes and select Install.
5. Reload the editor. RISE CRM and RISE CRM Trigger now appear in the nodes panel.

n8n's own guide: https://docs.n8n.io/integrations/community-nodes/installation/

Manually, on a self hosted instance

cd ~/.n8n
npm install n8n-nodes-rise-crm
# restart n8n

With Docker

Mount or bake the package into /home/node/.n8n/nodes, or set the community node environment variables documented by n8n, then restart the container.

From source

git clone <your-clone-of-this-package>
cd n8n-nodes-rise-crm
npm install
npm run build
npm link
# then, in ~/.n8n/nodes:  npm link n8n-nodes-rise-crm

---

Credentials

Create one RISE CRM API credential and both nodes use it.

Field	Example	Notes
Base URL	https://yoursite.com/index.php/api	The API root of your RISE installation. If your server rewrites index.php away, use https://yoursite.com/api. A trailing slash is ignored and /api is appended when missing.
API Token	eyJ0eXAiOiJKV1Qi...	Generated for an API user inside RISE.

Where the token comes from: in RISE, open the API settings screen added by the plugin, create an API user and copy its token.

How it is sent: as the authtoken HTTP header on every request. That is the plugin's authentication scheme - no OAuth, no Bearer prefix, no query string token.

Credential test: the built in test calls GET /api/reports, which returns the static report catalogue and touches no database table. It is the cheapest authenticated read in the plugin, so testing a credential never loads your CRM.

The test reads the body, not just the status code. The plugin reports a rejected token by printing {"status": false, "message": "Token not found"} and stopping, without ever setting an error status - the response goes out as HTTP 200. An unknown path is answered the same way, with {"status": false, "code": 404, "message": "Route not found"} and again an HTTP 200. The credential test therefore fails on that body shape as well as on the status code, so a wrong token or a wrong base URL shows up as a red credential instead of a green one.

---

The RISE CRM node

Resources and operations

Every resource below supports the same six operations, because the plugin registers the same route set for each of them.

Resource	REST path	Get Many	Get	Search	Create	Update	Delete
Client	/api/clients	✅	✅	✅	✅	✅	✅
Lead	/api/leads	✅	✅	✅	✅	✅	✅
Invoice	/api/invoices	✅	✅	✅	✅	✅	✅
Invoice Payment	/api/invoice-payments	✅	✅	✅	✅	✅	✅
Estimate	/api/estimates	✅	✅	✅	✅	✅	✅
Proposal	/api/proposals	✅	✅	✅	✅	✅	✅
Project	/api/projects	✅	✅	✅	✅	✅	✅
Task	/api/tasks	✅	✅	✅	✅	✅	✅
Ticket	/api/tickets	✅	✅	✅	✅	✅	✅
Timesheet	/api/timesheets	✅	✅	✅	✅	✅	✅

What each operation maps to:

Operation	Request	Notes
Get Many	GET /api/:resource	No paging parameters. The whole list comes back in one response.
Get	GET /api/:resource/:id
Search	GET /api/:resource/search/:keyword	Capped at 10 matches. Every search model ends its query with LIMIT 0, 10.
Create	POST /api/:resource	Accepts JSON, form-encoded and multipart bodies.
Update	PUT /api/:resource/:id	The API accepts PATCH on the same path as well. Both take JSON or form-encoded bodies - not multipart, which PHP cannot parse on those verbs. Fields you do not send keep their current value.
Delete	DELETE /api/:resource/:id

Custom Fields

The Custom Field resource has its own operation set, because RISE addresses custom field values by context plus record id rather than by a single id.

Operation	Request
Get Many (definitions)	GET /api/custom-fields (optional context filter)
Get (one definition)	GET /api/custom-fields/:id
Get Values	GET /api/custom-fields/values/:context/:recordId
Set Values	PUT /api/custom-fields/values/:context/:recordId (the API also accepts PATCH and POST there)

The 20 contexts RISE allows are in the dropdown: clients, client contacts, companies, contracts, estimates, events, expenses, invoices, items, leads, lead contacts, orders, projects, project files, proposals, subscriptions, tasks, team members, tickets and timesheets.

Writing records

Create and Update offer two input modes:

• Fields - add name and value pairs one at a time. Use the exact RISE column names, for example company_name and owner_id on a client.
• JSON - supply the whole body as a JSON object, which is the easier route when the fields come from an expression.

Example client body:

{ "company_name": "Acme Ltd", "owner_id": 1 }

Not sure which fields a resource accepts? Your own installation tells you: open GET /api/openapi.json, GET /api/swagger or GET /api/playground. Those are generated from the live plugin, so they are always right for your version.

---

The RISE CRM Trigger node

A polling trigger built on the plugin's Automation endpoints, which exist for exactly this purpose:

Endpoint	Used for
GET /api/automation/resources	Fills the Resource dropdown, live from your installation
GET /api/automation/poll/:resource?since=	Every scheduled poll
GET /api/automation/sample/:resource	A representative record when a manual test finds nothing

How it behaves

• The resource list is loaded from your own installation. Each entry is named the way the API describes it, so an entry only reads New or updated tickets when RISE really can detect updates on that resource. Resources that cannot be polled by timestamp are not offered at all.
• Cursor handling is automatic. The trigger stores meta.next_since from each response and sends it back on the next poll. That value is the RISE server clock read before the query ran, so a record written mid request is picked up by the following poll instead of vanishing between two cursors.
• De-duplication on id. The cursor is inclusive and several RISE date columns store a date with no time, so a record can legitimately come back twice. The trigger remembers recent ids and only emits each record once.
• First poll is quiet by default. Activating a workflow records the cursor and emits nothing, so you do not get flooded with the last 24 hours of history. Turn on Emit Existing Records on First Poll under Options if you want that history.
• Manual test shows real data. Executing the node by hand polls the last 24 hours without touching the stored cursor, and falls back to the sample endpoint so field mapping works even on a resource with no recent activity.
• Page Size is capped at 100 by the API.
• A full page never costs you records. The API returns the newest records first and takes no offset, so once a page is full the records behind it can only be reached by asking for a bigger page on the same cursor. That is exactly what the trigger does: it repeats the poll at the API maximum of 100 before doing anything else. If the page is still full at 100, more changed in that window than one poll can carry, and the trigger stops rather than stepping over them - the cursor is left where it was, nothing is emitted, and the node raises an error telling you to poll more often. Set Options > When a Poll Overflows to Emit the Newest Records and Skip the Rest if you would rather take the newest 100 and accept the gap; that choice also writes a warning to the n8n log every time it drops records.

About updates

RISE stores no generic "last modified" timestamp. Where a table carries a column that moves when a record is touched - a ticket's last activity, a task's status change, an invoice's cancellation - the API polls on those columns too and the trigger really does fire on updates. Where it does not, the trigger fires on new records only. The dropdown label tells you which one you are getting for every resource. No guessing, and nothing promised that the data cannot deliver.

---

Worked example: turn every new ticket into a task and a Slack message

Goal: when a support ticket arrives in RISE CRM, create a follow up task on the support project and tell the team in Slack.

1. RISE CRM Trigger

   • Credential: your RISE CRM API credential
   • Resource Name or ID: New or updated tickets
   • Page Size: 50
   • Poll Times: every 5 minutes
   • Options: leave Emit Existing Records on First Poll off and When a Poll Overflows on Stop and Raise an Error

2. Filter (optional, so replies to old tickets do not create duplicate work)

   • Condition: {{ $json.status }} equals new

3. RISE CRM - create the follow up task

   • Resource: Task
   • Operation: Create
   • Input Mode: JSON
   • Fields (JSON):

     {
       "title": "Follow up: {{ $json.title }}",
       "project_id": 7,
       "assigned_to": 3,
       "status_id": 1,
       "priority_id": 2
     }
     

   RISE requires title, project_id, assigned_to, status_id and priority_id when creating a task. Replace the ids with real ones from your installation.

4. Slack - post the alert

   • Message: New RISE ticket #{{ $('RISE CRM Trigger').item.json.id }}: {{ $('RISE CRM Trigger').item.json.title }}

Activate the workflow. That is a complete RISE CRM automation, running on a schedule, with no glue code.

More ideas that need no extra nodes

• New client > welcome sequence. Trigger on clients, then send an onboarding email and create the kickoff project.
• Invoice payment received > notify finance. Trigger on invoice payments, then post to a finance channel and update a spreadsheet.
• Lead created in a form > push into RISE. Webhook node in, RISE CRM node with Resource Lead and Operation Create out.
• Nightly sync. Schedule Trigger, then RISE CRM with Operation Get Many on invoices, then your BI tool or data warehouse.
• AI agent over your CRM. Drop the RISE CRM node in as a tool on an AI Agent node and let it look records up.

---

Beyond these nodes

The node covers the resources most workflows need. The plugin covers far more, and everything below works with the same credential through n8n's built in HTTP Request node, with Authentication > Predefined Credential Type > RISE CRM API:

Capability	Endpoint
The other CRM resources with the full route set (contacts, users, milestones, contracts, orders, subscriptions, expenses, items, taxes, notes, events, messages, announcements, todos, attendance, leave applications, labels, notifications and more)	/api/:resource with the same route pattern
New in 2.1.0 - line items on sales documents	GET/POST/PUT/PATCH /api/:parent/:id/items, DELETE /api/:parent/:id/items/:itemId (:parent = invoices, estimates, proposals, orders, contracts, subscriptions)
New in 2.1.0 - knowledge base, checklists, files	/api/knowledge-base/*, /api/checklists/*, /api/files/*
New in 2.1.0 - estimate and proposal comments, team, project members	/api/estimate-comments, /api/proposal-comments, /api/teams (+ GET /api/teams/:id/members), /api/project-members - full CRUD + search
New in 2.1.0 - roles and templates (read-only)	GET /api/roles, GET /api/templates and /api/templates/:type/...
Activity logs, which are an audit trail and therefore read only - there is no create, update or delete route for them	GET /api/activity-logs, GET /api/activity-logs/:id, GET /api/activity-logs/search/:keyword
Reporting aggregates for dashboards and BI	/api/reports, /api/reports/summary, /api/reports/invoices, /api/reports/projects, /api/reports/timesheets
Webhooks with HMAC-SHA256 signatures, an event catalogue and delivery logs	/api/webhooks and friends
Many operations in one call	POST /api/batch
Machine readable specs	GET /api/openapi.json, GET /api/postman.json
Interactive docs and playground	GET /api/swagger, GET /api/playground
MCP server for AI clients such as Claude Desktop, ChatGPT, Cursor and the n8n AI Agent	POST /api/mcp (JSON-RPC 2.0, opt in - enable it on the API settings screen)

---

Behaviour notes

Worth knowing before you debug something that is not a bug:

• No server side paging. The RISE list and search endpoints take no limit or offset parameters. Return All and Limit on this node therefore trim the result the API already returned - they do not make the query smaller. For large tables, prefer Search, or the trigger, or the reporting endpoints.
• Search returns at most 10 rows. Every search model in the plugin ends its query with LIMIT 0, 10, so a search is a lookup, not a bulk export. Raising Limit above 10 changes nothing.
• Empty results. The plugin answers "no data were found" with HTTP 404 rather than an empty list. The node reads that as an empty result so a Get Many over an empty table does not fail your workflow.
• A wrong base URL does not announce itself in the status code. The plugin's 404 override prints its JSON body and stops without setting a status code, so an unknown path comes back as HTTP 200 carrying {"status": false, "code": 404, "message": "Route not found"}. A rejected token arrives the same way, as HTTP 200 with {"status": false, "message": "Token not found"}. The node therefore inspects the body of every response: a "status": false envelope is turned into a node error naming the cause, instead of being passed down the canvas as if it were a record.
• Custom field values. Get Values returns nothing both when a record has no stored values and when the record does not exist, because the API answers 404 in both cases.
• Record ids are numeric. The node validates that before building the URL, so a bad id gives you a clear node error instead of an empty response body.
• Search terms cannot contain a slash. The API takes the keyword as a single URL segment.
• Field names are RISE column names. company_name, owner_id, project_id, assigned_to and so on. Your installation's GET /api/openapi.json is the authoritative list.

---

Compatibility

• n8n: 1.x, self hosted. Community nodes are installed from Settings > Community Nodes. On n8n Cloud, only packages that n8n has verified can be installed.
• Node.js: 20.15 or newer, matching n8n's own requirement.
• RISE CRM: any version supported by the REST API for RISE CRM plugin.
• REST API for RISE CRM plugin: 2.1.0 or newer. The trigger needs the Automation endpoints, which that version provides.

---

Development

npm install
npm run build     # tsc, then gulp copies the SVG icon and the .node.json codex files into dist/
npm run lint      # eslint with eslint-plugin-n8n-nodes-base, over nodes, credentials and package.json
npm run format    # prettier

The ESLint and Prettier settings live under the eslintConfig and prettier keys of package.json, which are officially supported config locations.

Two TypeScript projects, for one reason:

• tsconfig.json lists package.json among its files. The n8n ESLint rules lint package.json through @typescript-eslint/parser, and the parser refuses any file that is not part of a project.
• tsconfig.build.json extends it and excludes package.json again, because it is not a compilation input - left in, tsc would copy it to dist/package.json and ship a second, wrong manifest inside the package. npm run build uses this one.

tsc emits JavaScript only, so gulpfile.js copies the rest into dist/: riseCrm.svg for the node icons, and RiseCrm.node.json / RiseCrmTrigger.node.json, the codex files n8n reads for each node's categories, documentation links and search aliases. Both copies run through gulp.parallel, so the build waits for the streams to flush. After a build, check they are really in the package:

npm pack --dry-run   # dist/nodes/RiseCrm/RiseCrm.node.json and RiseCrmTrigger.node.json must be listed

---

Support

• Product page, documentation and purchase: https://themesic.com/product/rest-api-plugin-for-rise-crm-connect-rise-with-third-party-applications/
• All Themesic products: https://themesic.com/products/
• Your own installation is the best API reference: GET /api/swagger and GET /api/playground.

---

Licence

MIT - see LICENSE.md.

The MIT licence covers this n8n community node package only. It does not cover the REST API for RISE CRM plugin, which is a separate commercial product by Themesic Interactive, nor RISE CRM itself.