What Deluge “CRM tasks” actually do

Deluge has first-class tasks for Zoho apps. In Creator, they ride on your configured OAuth Connection and shield you from low-level HTTP details:

// Creator function (Deluge)
leadId = input.lead_id.toLong();
rec = zoho.crm.getRecordById("Leads", leadId);   // uses your CRM Connection under the hood
info rec;

• Auth is easy – attach a Connection once; no manual tokens.
• Less boilerplate – pass module + ID; get parsed JSON back.
• Good defaults – fewer gotchas (DC domains, headers, etc.).

What invokeurl actually does

invokeurl is Deluge’s generic HTTP client. You can call any REST API—Zoho or not. You control the URL, method, headers, query, and error handling:

// Creator function (Deluge) — direct CRM API call
resp = invokeurl
[
  url: "https://www.zohoapis.com/crm/v3/Leads/" + input.lead_id
  type: GET
  connection: "crm_oauth"   // Creator > Settings > Connections
  // headers: { "If-Modified-Since": "2025-01-01T00:00:00Z" } // optional
];
info resp;

• You choose the host (must match your data center: www/eu/in/au/jp.zohoapis.com).
• You handle pagination, rate limits (429), and retries.
• You follow the CRM endpoint contracts (request/response fields).

Which should I choose for Creator → CRM?

Use Deluge CRM tasks when…

• You’re doing supported, standard operations (read/update/insert).
• You want fewer moving parts and faster delivery.

Use invokeurl when…

• You need COQL, Bulk, or a niche endpoint not exposed by tasks.
• You need custom headers, strict pagination, or bespoke retry logic.
• You’re integrating with other Zoho product APIs or third-party APIs.

Common gotchas (and fixes)

1. 1

   Data-center host mismatch

   Use the correct domain for your org’s DC: www.zohoapis.com, eu.zohoapis.com, in.zohoapis.com, au.zohoapis.com, jp.zohoapis.com. Wrong DC = auth/404 issues.

2. 2

   Pagination & limits

   List endpoints page results. With invokeurl you must loop using page/ per_page (or tokens) until complete. Tasks that return collections can still require your loop—check the endpoint/task behavior.

3. 3

   Errors & throttling (HTTP 429)

   Add backoff and retry for 429/5xx. Log request/response snippets to diagnose payload shape and field errors. Keep concurrency modest to avoid throttling.

4. 4

   Connections over manual tokens

   In Creator, define an OAuth Connection (CRM scope) and reference it from tasks or invokeurl. It rotates tokens for you—don’t hand-build Authorization headers unless absolutely necessary.

Side-by-side patterns

A) Get one CRM record (simple & safe)

// Deluge task (preferred for simple reads)
leadId = input.lead_id.toLong();
rec = zoho.crm.getRecordById("Leads", leadId);
info rec;

// invokeurl (when you need low-level control)
resp = invokeurl
[
  url: "https://www.zohoapis.com/crm/v3/Leads/" + input.lead_id
  type: GET
  connection: "crm_oauth"
];
info resp;

B) Advanced filtering with COQL (powerful WHERE)

payload = {
  "select_query": "select Id, Last_Name, Email from Leads where City = 'Dubai' limit 200"
};

resp = invokeurl
[
  url: "https://www.zohoapis.com/crm/v3/coql"
  type: POST
  connection: "crm_oauth"
  content-type: "application/json"
  parameters: payload
];

info resp;

C) Bulk read for large datasets

// 1) Submit bulk-read job
jobReq = {
  "query": { "module": "Leads", "fields": ["Id","Last_Name","Email"] }
};

job = invokeurl
[
  url: "https://www.zohoapis.com/crm/v3/bulk/read"
  type: POST
  connection: "crm_oauth"
  content-type: "application/json"
  parameters: jobReq
];

// 2) Poll job.status until "COMPLETED", then download file_url
// (Keep retries/backoff; handle failures.)

Wait—what about Zoho Creator API “Get Records”?

Those docs are for Creator’s own REST API (forms/reports in your Creator app). They don’t make CRM faster. If you need CRM data, call CRM—either via Deluge tasks or via CRM’s REST endpoints with invokeurl. Creator API “Get Records” applies to Creator data, not CRM modules.

Is invokeurl faster?

Not inherently. Both paths ultimately talk to the same CRM service. Real-world speed depends on: the endpoint, network/DC proximity, fields selected, and how you page/batch the work (fewer, larger calls usually beat many tiny calls). Choose based on features/control; then optimize your queries and pagination.