Calling a REST API in Deluge means sending an HTTP request from a Deluge script to an external service and working with the response inside Zoho, and the task that does it is invokeUrl. Whether you are wiring Zoho CRM to a shipping provider or pulling data into Creator, knowing how to call a REST API in Deluge is the pattern we reach for on almost every custom software development integration, and it replaces the older getUrl and postUrl functions with one unified task.
Zoho now serves more than one million paying customers and over 150 million users worldwide (Zoho, February 2026), so odds are the external system you need to reach already has a REST API waiting. Here is how to talk to it.
Every call has the same shape. You assign the result of invokeUrl to a variable, then pass a set of named keys inside square brackets:
response = invokeUrl
[
url: "https://api.example.com/v1/status"
type: GET
headers: {"Authorization": "Bearer YOUR_TOKEN"}
];
info response;The keys that matter most:
url — the endpoint you are calling.
type — the HTTP method: GET, POST, PUT, PATCH, or DELETE. It defaults to GET.
headers — a Map of header keys and values, including auth and content-type.
body or parameters — the payload. You cannot use both in the same call.
connection — an optional named connection that handles OAuth for you.
When detailed is left at its default of false, the response comes back as just the content (a Map or List if the body is JSON). Set detailed:true and you instead get a Map with responseCode, responseHeader, and responseText — which is what you want for real error handling.
For a POST, build a Map, convert it to a JSON string with toString(), and set the content type header. The response parses straight into a Map, so you read a field with a simple get().
payload = Map();
payload.put("name", "Ada Lovelace");
payload.put("email", "ada@example.com");
response = invokeUrl
[
url: "https://api.example.com/v1/contacts"
type: POST
headers: {"Authorization": "Bearer YOUR_TOKEN", "content-type": "application/json"}
body: payload.toString()
];
new_id = response.get("id");
info new_id;A few things worth internalizing. The body key sends a raw payload, while parameters sends form or query values — mixing them up is the most common reason a call quietly fails. And because the auth header is spelled out here, this is a good moment to point developers toward Zoho's business systems integration practices before secrets end up hardcoded across a dozen functions.
A 200 is never guaranteed. Use detailed:true so you can check the status code and read the raw body before trusting the data. We have seen more than one production automation break silently because it assumed the API always returned a clean Map — until the day the endpoint returned a 429 and the script tried to get() a key that was not there.
response = invokeUrl
[
url: "https://api.example.com/v1/contacts"
type: GET
headers: {"Authorization": "Bearer YOUR_TOKEN"}
detailed: true
];
status = response.get("responseCode");
if(status == 200)
{
data = response.get("responseText");
info data.get("email");
}
else
{
info "API error: " + status + " - " + response.get("responseText");
}Wrap that check around every call and your integrations degrade gracefully instead of throwing cryptic runtime errors. For the auth side of the equation, our Zoho engineering team leans on named connections rather than raw bearer tokens, so credentials rotate in one place instead of a hundred.
Run through this every time you write a new call:
Set type explicitly — do not rely on the GET default when you mean POST.
Match your content-type header to the body (JSON needs application/json).
Choose body or parameters, never both.
Use detailed:true and check responseCode for anything that touches customer data.
Prefer a connection over pasted tokens so auth is centralized and rotatable.
Log the response with info during development, then trim it out.
If you want a deeper walkthrough of the language itself, our Zoho Deluge scripting examples and the seven Deluge lessons we learned the hard way cover the patterns that keep these scripts maintainable.
Calling a REST API in Deluge comes down to one task, invokeUrl, plus disciplined error handling. Set the method and headers deliberately, send JSON as a stringified Map through body, read the result as a Map, and always verify responseCode before you use the data. Get those habits right and you can connect Zoho to almost anything. If you would rather have experienced engineers build and harden the integration for you, book a free Zoho consultation and we will map it out with you.
By the CodeStringers Team — Zoho Experts & Custom Software. CodeStringers is a custom software engineering firm writing from work we've actually shipped for clients.
In a no-risk discovery we look at your CRM, finance and operations systems and who owns each part, and show what a connected system would do differently. You pay only if you proceed. Or see how we approach it.
More on the same problem:
Zoho Integrations: Connecting Zoho to the Rest of Your Business (article)
CoStar API Integration for a Commercial Real Estate CRM: What It Takes (article)
Use the built-in integration tasks, such as zoho.crm.getRecordById or zoho.crm.updateRecord, whenever they cover what you need, because they handle authentication for you and are easier to read. Use invokeUrl for Zoho endpoints the integration tasks do not expose, for bulk and search operations with parameters the tasks do not accept, and for every system outside Zoho. Mixing the two in one function is fine as long as each call is wrapped in the same error checks.
In the Zoho product you are scripting in, open Setup, find Connections, and create a new connection for the target service. Choose the service if it is listed or define a custom one with its authorization and token URLs, enter the client credentials from the external service, select the scopes, and authorise once. The connection is then referenced by name in invokeUrl, and Zoho refreshes the token for you, so no secret appears in the script.
Read the pagination fields the API returns, such as a next page token, a next URL or a page number and total count, and loop until they indicate the end, appending each page's records to a list. Keep the loop bounded with a maximum page count so a misbehaving API cannot run the function past its execution limit. For large data sets, process pages in a scheduled function that stores where it stopped and resumes on the next run.
Yes. invokeUrl accepts a files parameter that takes a file object, for example one fetched from a CRM attachment or returned by another API call, and sends it as multipart form data. The content type header must match what the receiving API expects. Response size and execution time limits still apply, so very large files are better moved through the API of the storage service directly rather than passed through a function.
The call has to complete within the execution limit of the function it runs in, which is short for functions tied to buttons, workflows and validation rules and longer for scheduled functions. A slow external API therefore fails a workflow function before it would fail a scheduled one. For APIs that take a while, trigger the work asynchronously, poll for the result in a later run, or move the call into a scheduled function.
Not in the script. Use a connection wherever the service supports OAuth, so the credential is stored and refreshed by Zoho. Where only a static key is possible, store it somewhere access-controlled, such as a secured settings record or an organisation variable that only administrators can read, and reference it from the function. Rotate keys on a schedule and when a developer leaves, which is only practical if the key lives in one place.
"Something isn't working." "We're outgrowing our tools." "We're afraid to make the wrong move." No-Risk Discovery is a short, practical conversation that gets you clarity before you commit to anything big. We'll tell you if we're a fit. If we're not, we'll tell you that too.
Say who you are and ask. A person replies within one business day.
