Vtiger node reference - all 48 operations, the credential it needs, and a worked example.
Vtiger CRM REST API. 48 operations: generic record CRUD against any module (create, get, partial update, full replace, delete, reopen, changed-since sync); VQL query plus list, find, count and phone/email lookup builders; per-module shortcuts for contacts, organizations, leads, deals and cases; lead conversion; record relationships and tags; and metadata discovery (modules, field definitions, related modules, picklist dependencies, current user).
Credential: Vtiger instanceUrl|username|accessKey - see Credentials.
Vtiger has no scope system and no OAuth flow. The credential is HTTP Basic — a CRM username plus that user's access key, found on the user's My Preferences page in the CRM (it is not the login password, and it is regenerated, not chosen). Nothing is ticked when the key is created, so every operation below is reachable by any valid key and a refusal is never a missing checkbox on the credential.
What gates a call is the CRM user the key belongs to. Their Role decides which records they can reach at all (their own, their subordinates', or everyone's) and their Profile decides what they may do per module — the View / Create / Edit / Delete checkboxes, plus per-field visible / read-only / writable toggles — both under Settings → User Management. So the grant question here is "which user is this key for, and what is that user allowed to do in the Contacts (or Leads, or HelpDesk…) module", and the fix for a refusal is to widen that user's Profile or to issue a key for a different user. Limit the blast radius the same way: create a dedicated integration user on a restricted Profile rather than using an admin's key.
Because the module is chosen at run time rather than baked into the endpoint, the per-operation answer is only knowable against a live instance — which is why the node ships Describe a module's fields. It returns createable, updateable, deleteable and retrieveable for the calling user on that module, and each field's mandatory and editable flags. Run it against the module you are about to write to and you have the exact permission answer for that user.
Two things that look like permission errors and are not: Vtiger meters API calls per user per day by edition, so a sudden refusal on a workflow that worked yesterday is usually an exhausted quota; and elementType is case-sensitive, so contacts fails where Contacts succeeds.
| Operation | What it does |
|---|
create | Create record |
retrieve | Get record by ID |
revise | Update record fields (partial) |
update | Replace record (all mandatory fields) |
delete | Delete record |
reopen | Reopen a closed record |
sync | Get records changed since a time |
| Operation | What it does |
|---|
query | Run a VQL query |
listRecords | List records in a module |
findRecords | Find records by field value |
countRecords | Count records |
lookup | Find records by phone or email |
| Operation | What it does |
|---|
createContact | Create contact |
retrieveContact | Retrieve contact |
updateContact | Update contact |
listContacts | List contacts |
findContacts | Find contacts by field value |
| Operation | What it does |
|---|
createAccount | Create organization |
updateAccount | Update organization |
listAccounts | List organizations |
findAccounts | Find organizations by field value |
getAccountHierarchy | Get organization hierarchy |
| Operation | What it does |
|---|
createLead | Create lead |
updateLead | Update lead |
listLeads | List leads |
findLeads | Find leads by field value |
convertLead | Convert lead |
| Operation | What it does |
|---|
createPotential | Create deal |
updatePotential | Update deal |
listPotentials | List deals |
findPotentials | Find deals by field value |
| Operation | What it does |
|---|
createTicket | Create case |
updateTicket | Update case |
listTickets | List cases |
findTickets | Find cases by field value |
| Operation | What it does |
|---|
retrieveRelated | List related records |
queryRelated | Query related records (VQL) |
addRelated | Link two records |
deleteRelated | Unlink two records |
| Operation | What it does |
|---|
addTags | Add tags to a record |
retrieveTags | Get a record's tags |
deleteTags | Remove tags from a record |
| Operation | What it does |
|---|
listModules | List modules |
describeModule | Describe a module's fields |
listRelatedTypes | List a module's related modules |
getPicklistDependency | Get picklist dependency map |
getCurrentUser | Get the API user |
| Operation | What it does |
|---|
retrieveFile | Retrieve a file's contents |
Query records without hand-writing VQL
Vtiger's only list/search primitive is a SQL-like query string, and asking a workflow author to type SELECT * FROM Contacts WHERE email = 'x' LIMIT 0,100; into a text box is a bad form. findContacts composes it. Two limits worth knowing: VQL has NO bracket grouping — conditions are evaluated strictly left to right — and a query returns at most 100 rows, silently truncating above that.
Set Operation to findContacts, then fill in:
| Field | Value | Notes |
|---|
email | {{ myTrigger.email }} | Composed into the WHERE clause |
limit | 100 | Vtiger's hard ceiling; results above it truncate SILENTLY, so page with offset rather than raising this |
Sets {{matches.records}} and {{matches.count}}.