Zoho CRM n8n integrationAutomate Zoho CRM with n8n.

A company record lands in Zoho CRM and the node hands back its identifier for the steps that follow.

• Account Name: the single required field, often {{ $json.company }} taken from the form or the sheet that started the run.
• Additional Fields: 17 optional fields, among them Industry, Phone, Website, Annual Revenue and a Billing Address group.

Matching happens on the account name: a record already carrying it gets updated, anything else becomes a new company. No lookup step is needed in front.

• Account Name: the value that decides between update and create, so it has to be what your source system treats as unique.
• Additional Fields: the same 17 optional fields, written in both branches.

One field, one removal. The node sends the deletion to Zoho CRM and passes the result down the workflow.

• Account ID: the identifier of the account to delete, visible at the end of the record URL in Zoho CRM, or carried over from an earlier node with {{ $json.id }}.

Sometimes a workflow only holds an identifier. This operation turns it back into the full company record before any decision is taken.

• Account ID: identifier of the account to retrieve, the same value found at the end of the URL.

The company list comes back in bulk, page after page when you ask for it.

• Return All: enabled, n8n follows every page of accounts; disabled, Limit sets how many come back.
• Options: Territory ID with Include Child narrows the export to one territory and those under it, while Approved keeps only approved records.

Corrections and enrichment land here: the record keeps its identifier, only the fields listed change.

• Account ID: the account to update.
• Update Fields: 18 fields, including Account Name itself, Employees, Annual Revenue and Website.

People rather than companies. The operation writes a person record in Zoho CRM and returns its identifier.

• Last Name: the only field Zoho CRM insists on, and an empty value stops the node.
• Additional Fields: 21 fields, including Email (Primary), First Name, Title (the position held at their company), Department and Mobile.

Email decides the outcome. When a contact already carries the address, Zoho CRM updates that record; otherwise it opens a new one.

• Email (Primary): sits in Additional Fields and acts as the match key for the upsert.
• Last Name: still required, even when the address already exists in the CRM.

Removal requests and stray duplicates end here, one person record per execution.

• Contact ID: identifier of the contact to delete, usually read from an earlier search or stored next to the person in your own database.

One identifier in, one full person record out. Fetching a single contact keeps the rest of the workflow honest: what runs downstream is what Zoho CRM holds right now, not what a spreadsheet remembered last quarter.

• Contact ID: identifier of the contact to retrieve.

Whole segments of the address book come back at once here.

• Return All: on for a complete extraction, off to stop at Limit when a sample is enough to test the rest of the branch.
• Options: Fields keeps the payload to the columns you actually use, and Sort By with Sort Order decides the order contacts arrive in.

Same person, new values. The identifier stays put and the listed fields are rewritten.

• Contact ID: the contact to update.
• Update Fields: 23 fields, among them Email (Primary), Phone, Title, Department and Last Name.

An opportunity opens in the pipeline. Two fields are required, and the stage is one of them, so a deal never lands without a place to sit.

• Deal Name: the label the sales team reads in the pipeline view.
• Stage Name or ID: pick a stage from the list n8n loads, or pass an ID through an expression.
• Additional Fields: Amount, Closing Date, Next Step and Probability, a percentage written plainly (12 for 12%).

Here the deal name carries the match: an opportunity already named that way is updated, anything else is created.

• Deal Name: doubles as the match key, so it should encode something stable like a project reference.
• Stage Name or ID: required in both branches, which means a stage has to be supplied even when the opportunity already exists.

Pipelines get polluted by tests and by mistakes. This operation drops a single opportunity from Zoho CRM.

• Deal ID: identifier of the deal to delete, kept from the node that created it or from an earlier Get Many.

Reading one opportunity gives the workflow the state it is in today, before anything gets written back.

• Deal ID: identifier of the deal to retrieve.

The pipeline arrives as data rather than as a dashboard screenshot.

• Return All: switch it on for the full pipeline; leave it off and Limit decides how many opportunities the node returns.
• Options: Sort By with Sort Order brings the newest or the largest up first, and Fields trims each deal to the columns a report needs.

Stage changes, corrected amounts and pushed-back dates all go through this operation. The opportunity keeps its identifier, so the history stays attached to it.

• Deal ID: the opportunity to update.
• Update Fields: 12 fields, including Stage Name or ID, Amount, Closing Date and Probability.

Billing documents can be assembled from the workflow itself, product lines included.

• Subject: required, the title of the invoice, and the only field the node will not let you skip.
• Products: one entry per line, with Product Name or ID, Quantity, Unit Price and Tax.
• Account Name or ID: ties the invoice to a company, alongside Invoice Date, Due Date and Status.

The subject line is what Zoho CRM compares: an invoice already carrying it is updated, otherwise a new document is created.

• Subject: match key and title at the same time, so an order reference works better than a generic label.
• Products: the lines are written in both branches, each with its Quantity, Unit Price and Total.

Drafts created by mistake do not have to be cleaned up by hand.

• Invoice ID: identifier of the invoice to delete, returned by the operation that created it.

One document, fetched by identifier, in the state Zoho CRM stores it. Reading before writing is what keeps a billing workflow from acting on an outdated copy of the same invoice.

• Invoice ID: identifier of the invoice to retrieve.

Invoices come back as a list, which is what a follow-up routine actually needs.

• Return All: on, n8n pages through every invoice; off, Limit caps the batch so a test run stays small.
• Options: Fields reduces each invoice to the few columns a reminder uses, and Sort By with Sort Order brings the oldest ones up first.

Status and totals move during the life of a document, and this is where a workflow writes them back.

• Invoice ID: the invoice to update.
• Update Fields: 19 fields, including Status, Due Date, Invoice Number, Grand Total and the Products list itself.

Adds a fresh lead to the Lead module and hands back its record ID, which later nodes reuse to update or delete that same lead.

• Company: the company the lead works at, required by Zoho even for a one-person business, usually mapped with an expression (a reference to the incoming item) such as {{ $json.company }}.
• Last Name: the surname, also required; an empty value stops the node.
• Additional Fields: 23 optional fields added one by one, among them Email, Phone, Lead Source and Lead Status.

Matching runs on the email address: when a lead already carries that address Zoho updates it, otherwise a new record appears. One operation instead of a search plus a branch.

• Company and Last Name: both required, exactly as in a plain creation.
• Email: sits in Additional Fields and carries the match. If a record with this email exists it gets updated, otherwise a new one is created.

Removes the lead from Zoho CRM. The call needs nothing but an identifier, and nothing in the node asks for a confirmation, so build the safety into the workflow ahead of it.

• Lead ID: the ID of the lead to delete, not the person's name or email. Read it from an earlier Get Many step or from the creation node, for instance {{ $json.id }}.

Reads one lead and returns its stored values, so a workflow can decide what to do with data that is current rather than with whatever the form sent.

• Lead ID: the ID of the lead to retrieve. Zoho returns it when the record is created, and it also travels in the output of a Get Many step.

Lists the fields defined on the Lead module, custom ones included. It answers the question that blocks most mappings: what is this field really called on the API side.

No parameter to fill. Pick the operation, run the node once, read the output.

Pulls a batch of leads, one item per record, ready to be filtered, written to a sheet or counted.

• Return All: on, n8n walks the API pages until every lead is out; off, Limit caps how many come back.
• Approved and Converted: approved records only by default, converted ones left out by default.
• Sort By and Sort Order, ascending or descending, plus Fields to keep the payload small.

Writes new values on an existing lead without touching the rest of the record. Only the fields opened in the collection are sent.

• Lead ID: the ID of the lead to update, the same identifier the creation step returned.
• Update Fields: 25 fields available, including Lead Status, Description, Phone and Custom Fields.

Registers an item in the Products module, which quotes, sales orders and purchase orders then reference by name or by ID.

• Product Name: the only required value.
• Additional Fields: 10 optional fields, among them Unit Price, Quantity in Stock, Manufacturer, Product Category and Taxable.
• Commission Rate: a percentage typed as a plain number, so 12 means twelve percent.

Here the product name doubles as the key. Zoho updates the record bearing that name, and creates one when the catalog has never seen it.

• Product Name: required, and used for the match. If a record with this product name exists it will be updated, otherwise a new one is created.
• Additional Fields: the same optional set, useful to refresh Unit Price or Quantity in Stock on every run.

Drops a product from the catalog. Records that already reference it keep their own history, but nothing new can point at it afterwards.

• Product ID: the ID of the product to delete, not its commercial name. A Get Many step upstream turns a name into that ID.

Returns a single product with its current values, which is what you want before quoting anything.

• Product ID: the ID of the product to retrieve, taken from a previous node, typically {{ $json.id }}.

Lists the catalog, one item per product, which makes it the entry point for any export or comparison against another system.

• Return All: enabled, the node chains the API pages to bring back the whole catalog; disabled, Limit sets the ceiling.
• Fields: returns only the columns asked for, handy when a product carries dozens.
• Sort By, Sort Order and Territory ID narrow the batch further.

Changes the values of an existing product. Fields left out of the collection stay exactly as they were in Zoho CRM.

• Product ID: the ID of the product to update.
• Update Fields: 10 fields available, including Unit Price, Quantity in Stock, Quantity in Demand, Description and Product Active.

Issues a purchase order to a vendor and returns the created record, with its lines already priced.

• Subject: the title of the purchase order, the only required value.
• Vendor Name or ID: picked from the list loaded from Zoho, or supplied as an ID through an expression.
• Products: each line takes a Product Name or ID, a Quantity and a Unit Price; Due Date, Terms and Conditions and Discount sit alongside them.

The subject acts as the identifier here. An order already titled that way is updated, anything else becomes a new purchase order.

• Subject: required, and used for the match. If a record with this subject exists it will be updated, otherwise a new one is created.
• Vendor Name or ID and the Products lines are filled the same way as in a creation.

Erases a purchase order from Zoho CRM. Useful when an order should never have existed, rather than when it simply ended.

• Purchase Order ID: the ID of the purchase order to delete, not its subject.

Fetches one purchase order with its lines and totals as they stand in Zoho CRM right now.

• Purchase Order ID: the ID of the purchase order to retrieve, returned by the creation step or read from a listing.

Returns purchase orders in bulk, which is how you get a spend picture without exporting anything by hand.

• Return All: active, every page of the API is fetched; inactive, Limit decides how many orders come back.
• Sort By and Sort Order: newest first with a descending sort on a date field.
• Fields: keeps only the columns a report needs.

Applies changes to an order already in Zoho CRM, typically as it moves through its lifecycle.

• Purchase Order ID: the ID of the purchase order to update.
• Update Fields: 20 fields available, including Status Name or ID, Tracking Number, Carrier, Due Date and Subject.

The node writes a new record into the Quotes module of Zoho CRM and returns the quote it created, record ID included, so the next node can pick it up.

• Subject: the title of the quote, required, usually mapped from the incoming item with {{ $json.subject }}.
• Additional Fields: the optional collection where Valid Till, Terms and Conditions and Quote Stage Name or ID are set.
• Products: one entry per line, each with Quantity, Unit Price and Total.

Subject does the matching. A quote already carrying that subject gets updated, anything else is created, which stops a workflow that runs twice from leaving two quotes behind.

• Subject: required, and the value the match is made on.
• Additional Fields: the same optional collection as the create path, for Sub Total, Grand Total or Description.
• Products: Product Name or ID comes from the dropdown, or from an expression when the product ID travels with the item.

One call, one record gone. The quote leaves the Quotes module for good, so a safety check belongs upstream rather than after the fact.

• Quote ID: the record identifier of the quote to delete, not its subject, typically {{ $json.id }} carried over from a previous step.

Reading a single quote back, field by field, is what this one does. Useful when the workflow holds an identifier and needs the rest of the record.

• Quote ID: the identifier of the quote to retrieve; Zoho CRM expects that ID, a subject will not resolve.

Quotes come back as a list, one n8n item per record, which makes this the entry point of any export or reporting branch.

• Return All: on, n8n walks the pages of the Zoho CRM API until every quote is in; off, Limit caps how many come back.
• Sort By and Sort Order: the field records are ordered on, ascending (asc) or descending (desc).
• Approved: on by default, so quotes still waiting for approval stay out until you turn it off.

Nothing is created here. An existing quote is patched, and only the values placed in Update Fields change.

• Quote ID: required, the record being edited.
• Quote Stage Name or ID: moves the quote along its stages, picked from the list or set through an expression.
• Valid Till: the date the quote stops being valid.
• Grand Total and Adjustment: the amount after tax and discounts, and the correction applied to it.

A sales order is written into Zoho CRM and attached to an account, which is the step that usually follows an accepted quote.

• Account Name or ID: required, chosen from the dropdown or resolved by expression when the account ID travels with the item.
• Subject: required, the title the order shows in lists.
• Products: the ordered lines, with Quantity, Unit Price and Discount, where you enter 12 for 12%.
• Due Date: when payment or delivery is expected.

Two required fields, same as the create path, with one difference that matters: the subject decides whether Zoho CRM writes a new order or refreshes the one already carrying it.

• Subject: required, and the match key.
• Account Name or ID: required too, the account the order belongs to.
• Status Name or ID: the status of the sales order, from the list or an expression.
• Sales Order Number: the order number stored on the record.

Deletion targets one order and removes it from the module. It belongs at the end of a branch that has already checked something, never straight after an unfiltered list. The identifier usually comes from a Get Many step, or from the order created earlier in the same run.

• Sales Order ID: the identifier of the sales order to delete.

Handy when an order identifier arrives from another system and the workflow needs the actual record: the node fetches one sales order and passes its fields downstream.

• Sales Order ID: the identifier of the sales order to retrieve, often {{ $json.id }}.

Every sales order, or just the first few, depending on one checkbox. Each record lands as a separate item, ready to be filtered or summed further down.

• Return All: ticked, n8n keeps requesting pages until the module is exhausted; unticked, Limit sets the ceiling.
• Territory ID: keeps only the records of one territory, and Include Child restricts the response to its child territories.
• Converted: off by default, turn it on to keep converted records only.

Orders move. A status changes, a date slips, a commission is agreed. This operation writes those values onto an existing record and leaves the rest alone.

• Sales Order ID: required, the record being edited.
• Status Name or ID: the new status of the sales order.
• Due Date: the revised date.
• Sales Commission: the commission of the sales person as a percentage, 12 for 12%.

Vendors are the supplier side of Zoho CRM. This operation adds one and returns the record, so a purchasing workflow can keep going on the same run.

• Vendor Name: the only required field.
• Email, Phone and Website: the contact details, all three in Additional Fields.
• Category: how the supplier is classified internally.

Vendor Name plays the part of the key here: a supplier already registered under that exact name is updated, anything else is created from scratch.

• Vendor Name: required, and the value the match is made on.
• Address: the address collection, filled field by field.
• Currency: the currency attached to the supplier.
• Custom Fields: your own Zoho CRM fields, in the same collection.

Suppliers leave, and their record follows. Pass an identifier and the vendor is removed from Zoho CRM, with no way to bring it back from n8n.

• Vendor ID: the identifier of the vendor to delete; the vendor name will not do here, so a lookup step usually comes first to resolve it.

Sometimes all a workflow holds is a vendor identifier. The node turns it into the full record, phone number and category included. Nothing is written back, so it is safe to drop anywhere in a branch.

• Vendor ID: the identifier of the vendor to retrieve, typically {{ $json.id }} from an earlier node.

The whole supplier directory can be pulled in a single node, then sorted, filtered or written somewhere else.

• Return All: paginates through every vendor; left off, Limit decides how many items come back.
• Fields: the fields kept in the response, which keeps long runs light.
• Sort By: the field the list is ordered on, with Sort Order set to asc or desc.

Contact details age faster than anything else on a supplier record. Feed the identifier plus the values that changed, and the rest of the vendor stays as it was.

• Vendor ID: required, the vendor being edited.
• Vendor Name: editable here, unlike the upsert path where it serves as the match key.
• Email and Phone: the details worth refreshing first.
• Description: free text about the supplier.