QuotaGuard and Zoho Deluge Integration Guide

QuotaGuard Static IPs let your Zoho applications reach APIs and services that require IP allowlisting. This guide covers Deluge scripts across the Zoho suite (CRM, Creator, Flow, and the rest of Zoho One) and explains the one extra piece Zoho needs compared to other platforms.

Why Zoho Requests Get Blocked

Deluge scripts run inside Zoho’s cloud, and their outbound invokeUrl calls originate from Zoho’s shared infrastructure rather than from IP addresses you control. When the API you’re calling restricts access by source IP, those requests are rejected:

• 403 Forbidden from corporate firewalls and WAFs
• Access denied from banking APIs and payment gateways
• Blocked requests from any partner that maintains an IP allowlist

Your code and API keys are fine. The target service is blocking requests because they arrive from IPs it doesn’t recognize.

The Zoho Constraint

On most platforms, you point your HTTP client at the QuotaGuard proxy and you’re done. Zoho doesn’t give you that option:

• Deluge’s invokeUrl has no proxy setting.
• Zoho’s managed environment can’t run our QGTunnel helper, which needs a long-running process alongside your app.

So Deluge cannot send traffic through QuotaGuard directly. The working pattern is a small relay function that you host outside Zoho.

The Relay Pattern

Deluge invokeUrl --> your relay function --> QuotaGuard proxy --> target API

Your Deluge script calls the relay’s URL, passing the real target URL in a header. The relay forwards the request through QuotaGuard, so the target API sees one of your two static IPs. The response comes back to Deluge as the invokeUrl result.

We publish a ready-to-use relay for AWS Lambda, including setup steps and a Deluge invokeUrl example:

python/lambda-relay in quotaguard/static-examples

It’s a single Python file you paste into a Lambda function in the AWS console. It uses only libraries already present in the Lambda runtime, so there is nothing to package, and it’s protected by a secret key that you set as an environment variable. A Google Cloud Function works the same way if you prefer GCP.

Setup summary (details in the example’s README):

1. Sign up for QuotaGuard and note your Connection URL and two static IPs from the dashboard.
2. Create the Lambda, paste in the code, and set the QUOTAGUARDSTATIC_URL and RELAY_KEY environment variables.
3. Give the Lambda a Function URL and call it from Deluge with X-Relay-Key and X-Target-URL headers.
4. Add both static IPs to the target API’s allowlist. Both are active simultaneously, so allowlist both.

Choosing regions: create the Lambda in the AWS region closest to you, and pick the matching QuotaGuard region when you sign up. Your two static IPs stay the same regardless of how much traffic you send.

What This Covers (and What It Can’t)

The relay handles anything you call from Deluge or other custom code, since you control the URL being invoked.

It cannot change where Zoho’s built-in integrations connect from. If a Zoho app talks to an external service through a native connector rather than your Deluge code, that traffic goes out from Zoho directly and can’t be routed through QuotaGuard. Check which of your IP-restricted connections run through Deluge before planning the allowlist.

Testing

Point X-Target-URL at https://ip.quotaguard.com. It returns the IP your request came from, which should be one of the two static IPs shown in your dashboard. Once that checks out, switch the target to the real API.

If you run into anything odd during setup, contact support and include the error you’re seeing.