Agile CRM n8n integrationAutomate Agile CRM with n8n.

This operation adds a company record to Agile CRM and gives back the created object, identifier included. Nothing is strictly required, so the shape of the record comes from what you pass in the optional collection of 8 fields.

• Name: the company name, usually {{ $json.company }} taken from the form or the spreadsheet that started the run.
• Website: the company websites collection, handy when the domain becomes your matching key later.
• Star Value: a rating from 0 to 5 to flag the accounts worth a closer look.

Removes one company from Agile CRM. The call targets a single record and touches nothing else, which is why it sits at the end of a deduplication branch rather than in the middle of a sync.

• Company ID: the ID of the company to delete, not its name. Read it from a previous company.getAll step with {{ $json.id }}.

Fetches a single company and hands its stored fields to the next node, so the rest of the workflow can branch on what the CRM actually holds instead of guessing.

• Company ID: the unique identifier for a particular company. A name or a domain will not resolve here, so look the ID up first.

Returns companies as a list, which is the read to reach for when the workflow needs the book rather than one record.

• Return All: on, n8n walks every page of the API until the list is complete; off, Limit caps how many companies come back.
• Filter: none, manual to build conditions in the interface, or json to paste them.
• Must Match: anyFilter widens the result, allFilters narrows it.
• Simplify: returns a trimmed response instead of the raw payload.

Writes new values onto a company that already exists. The optional collection carries 8 fields, from Phone to Custom Properties, and you send the ones the workflow actually knows.

• Company ID: the unique identifier for a particular company, the anchor of the update.
• Email: the company email, in the name@email.com shape the field suggests.
• Tags: unique identifiers added to the company to keep the base manageable.

Builds a contact in Agile CRM out of whatever the previous node produced. As with companies, no field is mandatory, and the optional collection carries 12 of them.

• First Name and Last Name: the contact name, typically {{ $json.first_name }} mapped from the form payload.
• Email: the contact email collection, the field most workflows key on afterwards.
• Lead Score: the score the contact starts at, so a demo request does not land level with a newsletter signup.
• Title: the professional title, useful when routing to the right rep.

Erases one contact from the CRM. Single record, single call, which makes it easy to park behind an approval step instead of letting it run over a whole list.

• Contact ID: the ID of the contact to delete. Resolve it first with contact.getAll, because an email address is not accepted in this field.

Reads one contact and passes its fields down the workflow. Everything stored on the record travels with the item, so later steps work on real values rather than on what the trigger happened to carry.

• Contact ID: the unique identifier for a particular contact, the only input this operation takes.

Pulls a list of contacts with the same filtering toolkit as the company list. This is where a segment gets built without anyone opening the Agile CRM interface.

• Return All: on, every page is fetched; off, Limit sets the maximum number of contacts returned.
• Field and Condition Type: any searchable field compared with EQUALS, BEFORE, BETWEEN and the rest, against Value and Value 2.
• Sort: orders the result before it reaches the next node.

Overwrites the values of a contact with what the workflow has just worked out. The 12 optional fields are the set used at creation, so the mapping stays identical between the create branch and the update branch.

• Contact ID: the unique identifier for a particular contact.
• Lead Score: the new score, often {{ $json.score }} coming from a scoring step upstream.
• Company: the company name attached to the contact, worth refreshing when someone changes jobs.

Opens a deal in the pipeline. It is the one operation in the node with a real required set: 5 fields have to be filled or the execution stops there.

• Name: the deal name, the label the sales team reads in the pipeline.
• Close Date: the closing date, a dateTime value, so a date computed upstream fits straight in.
• Expected Value and Probability: the expected value of the deal and the expected probability, both numbers.
• Milestone: the milestone the deal enters at.
• Contact IDs: optional, ties the deal to the contacts behind it.

Drops a deal from the pipeline. The place for it is a cleanup routine, when an opportunity was logged by mistake and the forecast should stop carrying it.

• Deal ID: the ID of the deal to delete, taken from the creation step or from a deal.getAll lookup.

A single deal comes back with its current values, which is how a workflow checks where an opportunity stands before it acts on it.

• Deal ID: the unique identifier for a particular deal, so keep the ID from the step that created or listed it.

Lists the deals in the pipeline. It takes two parameters, both about how much comes back, which makes it the plainest read in the node.

• Return All: on, n8n pages through the API until every deal has been collected.
• Limit: the maximum number of deals returned while Return All stays off, handy for a quick test run.

Changes the values of a deal already in the pipeline. The deal identifier is the only thing the operation demands, and 5 optional fields are available on top of it.

• Deal ID: the ID of the deal to update.
• Probability: the new expected probability, the field a forecast usually hangs on.
• Expected Value: the revised amount, for instance {{ $json.amount }} after a renegotiation.
• Custom Data: your own keys and values, for what the team tracks on top of the standard fields.