Introduction
A few months back I was building a Zoho Deluge function that called an external REST API. The real API was under development, so I needed something to test against — something predictable, something that could mimic a slow response. A quick search brought me to Postman Echo, specifically its /delay endpoint.
I typed https://postman-echo.com/delay/2, assumed the 2 stood for 2 milliseconds, and ran the function. The script paused for a full two seconds. That's when I realized I had the unit completely wrong — and I've since seen the same confusion come up in Zoho forums, Stack Overflow threads, and developer Slack groups more times than I can count.
So this post is a proper walkthrough. What Postman Echo is, what the delay endpoint actually does, how to use it inside a Zoho Deluge invokeurl block, and — most importantly — a clear answer on whether that number is milliseconds or seconds.
What Is Postman Echo?
Postman Echo is a free, publicly available HTTP service hosted by the Postman team at https://postman-echo.com. Its entire purpose is to give developers a real, live endpoint to test HTTP client behavior — without needing to stand up a backend server yourself.
Think of it as a mirror for your HTTP requests. You send a request, it reflects information back at you. Beyond basic echoing, it also supports a set of utility endpoints for testing specific behaviors that are otherwise hard to simulate:
- Request echoing (headers, body, query params)
- Basic and digest authentication
- Cookie handling
- Compressed (gzip) responses
- Redirect chains
- And the one we're focused on — delayed responses
No API key required. No account. No setup. You just call the URL and it responds. For development and testing purposes, it's genuinely one of the handiest tools available.
The /delay Endpoint — How It Works
The delay endpoint is one of the simplest APIs you'll ever use. The full structure is:
Where n is a whole number passed directly in the URL path. The server receives the request, holds it for n seconds, then sends back an HTTP 200 OK with a small JSON body.
Here's a quick reference for the values you'd actually use:
| URL | Server waits | In milliseconds | Notes |
|---|---|---|---|
/delay/0 | ~0 seconds | ~0 ms | Near-instant response |
/delay/1 | 1 second | 1,000 ms | Minimal delay |
/delay/2 | 2 seconds | 2,000 ms | Common test value |
/delay/5 | 5 seconds | 5,000 ms | Good for timeout testing |
/delay/10 | 10 seconds | 10,000 ms | Maximum accepted value |
A couple of things worth knowing upfront: the endpoint only accepts whole integers. Decimal values like /delay/1.5 aren't supported. And the cap is 10 seconds — pass anything higher and the behavior becomes unpredictable.
The Zoho Deluge Code — Full Breakdown
Here's the exact snippet that sparked the confusion for a lot of people:
delayResponseCall = invokeurl
[
url :url
type :GET
];
Let's go through each part deliberately.
Line 1 — Storing the URL
The URL is assigned to a variable before being passed into invokeurl. This is a small but worthwhile habit in Deluge. If you want to test with a different delay value — say, bumping from 2 to 5 seconds — you change it in exactly one place instead of hunting through the block syntax. It also makes the code easier to read at a glance.
The invokeurl Block
invokeurl is Zoho Deluge's built-in HTTP client. It uses a distinctive square-bracket syntax with colon-separated key-value pairs — a bit different from what you'd see in Python's requests library or JavaScript's fetch, but it follows the same underlying logic.
url : url— the firsturlis a Deluge reserved keyword for the parameter name; the second is your variable. This one trips people up initially.type : GET— sets the HTTP method. Since we're not sending any body or custom headers, GET with no other parameters is all we need here.
The entire block evaluates to the server's response, which gets stored in delayResponseCall. Deluge automatically parses the JSON body into a Map object, so you can access fields directly.
Reading the Response
After the delay, the server sends back:
Simple. One field confirming the number of seconds it waited. In Deluge, accessing that looks like this:
info "Server held the response for: " + secondsWaited + " second(s)";
Milliseconds or Seconds? Let's Settle This
/delay/2 is 2 seconds — that's 2,000 milliseconds, not 2 ms. There is no millisecond mode.
The confusion is easy to understand. Most timing functions in programming default to milliseconds. JavaScript's setTimeout(fn, 2000) takes milliseconds. Java's Thread.sleep(2000) takes milliseconds. So when you see a bare integer like 2 in a timing context, your brain fills in "milliseconds" automatically.
Postman Echo breaks that pattern. The path parameter maps directly to seconds, no conversion needed. There's no flag to toggle, no query parameter to switch units. It's seconds, always.
If you genuinely need sub-second delay simulation in your tests, the Postman Echo endpoint won't cut it. You'd need to either run a local mock server or use a service that accepts millisecond-precision parameters.
Real-World Use Cases in Zoho Deluge
Now the obvious question — when would you actually reach for this in a Deluge project? Here are four scenarios I've personally found it useful for, or seen others use it for.
1. Testing Timeout Handling
Zoho functions have execution time limits, and invokeurl has its own timeout behavior. If your workflow calls an external service and you want to verify that your error handling fires correctly when that service is slow, set the delay endpoint to a value near your timeout threshold. You get consistent, reproducible slowness on demand — no need to wait for a real API to have a bad day.
2. Building and Validating Retry Logic
If you're writing a retry loop — "try the call, wait a bit, try again if it fails" — you need something that responds slowly on purpose. The delay endpoint gives you that control. Pair a 5-second delay with a tight timeout setting and you can force the retry path reliably every single time during testing.
3. Benchmarking invokeurl Overhead
Want to know how much time Deluge's HTTP machinery adds to every outbound call, independent of server processing time? Hit /delay/0 and note the actual elapsed time. That delta is your baseline overhead — network round-trip plus Deluge's own internal processing. Useful when you're trying to optimize functions that make multiple API calls in sequence.
4. Development Placeholder
You're building a Zoho CRM workflow that will eventually call a third-party API — but that API isn't live yet. Instead of mocking the entire response structure, you can point your invokeurl at the delay endpoint temporarily. It keeps the plumbing working and lets you test the surrounding logic while you wait for the real endpoint to be ready.
Things to Watch Out For
Zoho's execution time limit
Deluge functions in Zoho CRM, Creator, and other Zoho apps have enforced maximum execution times. If you're testing with /delay/10, make sure you understand the time cap for your specific Zoho product. A function that exceeds the limit will be killed mid-execution, and your response variable will be empty or throw an error.
The 10-second ceiling
Values above 10 don't produce proportionally longer waits — they just behave unpredictably. Stick to integers between 0 and 10.
Don't use this in production
Worth repeating. Postman Echo is a shared, unguaranteed service. If it goes down, your production workflow goes down with it. This endpoint belongs in your dev and staging environments only.
Complete Working Example
Here's a clean, production-style Deluge snippet with proper response handling:
delaySeconds = 3;
url = "https://postman-echo.com/delay/" + delaySeconds;
// Make the HTTP GET call
response = invokeurl
[
url :url
type :GET
];
// Validate response
if(response != null)
{
confirmed = response.get("delay");
info "Response received. Server delayed for " + confirmed + "s";
}
else
{
info "No response — possible timeout or network error.";
}
Building the URL dynamically by concatenating the variable makes it easy to swap delay values without touching the invokeurl block at all.
Quick Reference
Endpoint: https://postman-echo.com/delay/{n}
Method: GET | Auth: None required
Parameter: n = whole number of seconds to delay (range: 0–10)
Response: {"delay": n} returned after the wait
In Deluge: Use invokeurl with type : GET — response is a Map
Unit clarification: The number is seconds, not milliseconds
Conclusion
The Postman Echo delay endpoint is deceptively simple — one URL, one integer, one JSON field in the response. But that simplicity is exactly what makes it useful. When you need reliable, reproducible latency in your tests, you don't want a complicated setup. You want something you can point your HTTP client at and move on.
The biggest takeaway from this entire post: the number in the URL path is seconds, not milliseconds. /delay/2 holds the response for a full 2,000 milliseconds. That single clarification saves a surprising amount of head-scratching, especially when you're integrating with Zoho Deluge's invokeurl and trying to figure out why your "fast" test is taking two full seconds to complete.
To recap what we covered:
- Postman Echo is a free, no-auth public API for testing HTTP clients — no setup required.
- The
/delay/{n}endpoint accepts a whole integer from 0 to 10 and waits that many seconds before responding. - In Zoho Deluge,
invokeurlwithtype : GETis all you need — the response comes back as a Map with a single"delay"key. - Practical uses include timeout testing, retry logic validation,
invokeurloverhead benchmarking, and development placeholders. - Never use Postman Echo in production — it's a shared public service with no SLA.
If this helped clear things up, or if you've used the delay endpoint for something I haven't covered here, drop a comment below. And if you're digging into Zoho Deluge HTTP patterns — POST requests with JSON bodies, custom headers, OAuth flows — those are worth a dedicated post. Let me know in the comments which one to tackle next.