QuotaGuard and Make Integration Guide

Two ways to use this guide: Setting up the integration yourself? Follow the setup steps below. Working with an AI coding agent? Share this page and use the instructions below to help it configure the integration, verify the connection and troubleshoot issues.

To let your agent set up and test the connection, provide the required proxy connection details through its secure credential mechanism rather than sharing your QuotaGuard account password. Review any changes it proposes.

QuotaGuard Static IPs allow your Make scenarios to send outbound HTTP requests through a load-balanced pair of static IP addresses. Once configured, you can use QuotaGuard’s IPs to connect to firewalled APIs, enterprise databases, and services that require IP allowlisting.

You do not need QuotaGuard for internal Make operations or connections to services that don’t require IP whitelisting. QuotaGuard is specifically for reaching external services that block requests from unknown IP addresses.

Why Make Scenarios Get Blocked

Make uses shared AWS IP pools that rotate across each zone (US1, US2, EU1, EU2). Each zone has three egress IP addresses that Make rotates through. These IPs are shared with every other Make user in that zone, which creates problems:

• Enterprise firewalls and WAFs block cloud IP ranges by default
• Corporate APIs require IP allowlisting for access
• Financial services and healthcare APIs enforce strict access controls
• Google Workspace Context-Aware Access policies reject unknown IPs
• Database providers like MongoDB Atlas and Amazon RDS use IP-based security groups

The result is 403 Forbidden, connection refused, or authentication failures that have nothing to do with your scenario logic. Your API keys are valid. Your configuration is correct. The target service is simply blocking the shared Make IP addresses.

Even if you ask a partner to allowlist Make’s IPs, they would need to open their firewall to every Make user in your zone. Most security teams reject this request.

QuotaGuard gives your Make scenarios a fixed IP identity that partners can add to their firewall allowlists instead of opening their firewall to Make’s shared ranges.

Make’s Native IP Addresses

For reference, these are the egress IP addresses Make publishes per zone:

Make maintains this list in Allow connections to and from Make IP addresses, where it also notes that its ingress addresses are dynamic, so only the egress list above is usable for an outbound allowlist. These IPs are shared across all Make users in each zone. QuotaGuard provides an allowlistable static IP pair assigned to your subscription.

Getting Started

After creating a QuotaGuard account, you will be redirected to your dashboard where you can find your proxy credentials and static IP addresses.

Choose the right proxy region: Match your QuotaGuard region to your Make zone for optimal latency and data residency compliance.

Finding Your Make Zone: Look at your Make dashboard URL. If it starts with eu1.make.com, you’re in the EU1 zone. If it starts with us2.make.com, you’re in US2. You can also check your organization settings.

Finding Your Static IPs: Your two static IPs are displayed in the QuotaGuard dashboard. Both IPs are active simultaneously for high availability. Add both to any firewall allowlists you’re configuring on the target service side.

Your QuotaGuard proxy URL looks like this:

http://username:password@<your-quotaguard-proxy-host>:9293

For Make, you will need to split this into components:

• Host: <your-quotaguard-proxy-host>
• Port: 9293
• Username: Your subscription proxy username
• Password: Your subscription proxy password, not your QuotaGuard account password

Configuring Make Scenarios

Make’s HTTP module includes native proxy support in the Advanced Settings section. This works with all Make subscription tiers, including the free plan.

Step 1: Add an HTTP Module to Your Scenario

In the Make scenario editor, add an HTTP module. The current HTTP app, version 4, ships three:

• Make a request for any HTTP call, which is the one you want here
• Download a file for retrieving a file
• Resolve URL for expanding a shortened or redirecting URL

Authentication moved into the module in version 4. Rather than choosing a separate Basic Auth or API Key Auth module, set the Authentication type field on Make a request to No authentication, API key, Basic Auth or OAuth 2.0, then attach the matching Credentials: API key and Basic Auth store theirs in a keychain, OAuth 2.0 uses a connection.

If your scenario still shows older module names such as Make a Basic Auth request, it is running HTTP (legacy), which you select as Version 3 in the app’s version drop-down. Proxy configuration works the same way in both versions.

Step 2: Configure Your Request

Set up your HTTP request as you normally would:

1. Enter the URL of the API endpoint you’re calling
2. Select the Method (GET, POST, PUT, etc.)
3. Add any required Headers and Body content
4. Configure Authentication if needed

Step 3: Enable the Proxy in Advanced Settings

Scroll down to the Advanced settings section at the bottom of the HTTP module configuration panel.

1. Find the Proxy field
2. Click Create a keychain (or select an existing one if you’ve configured QuotaGuard before)
3. In the popup window, configure the following fields:

1. Save the keychain
2. The proxy is now active for this HTTP module

The same Advanced settings panel holds a Transport layer security (TLS) option offering None, Mutual TLS and TLS, plus a separate CA certificate keychain. Both describe the connection to your target API rather than the hop to the proxy, so neither changes how the module reaches QuotaGuard. The proxy keychain’s four fields are exactly what QuotaGuard Static’s HTTP proxy endpoint takes: your proxy host, port 9293, and your subscription proxy credentials. QuotaGuard Shield’s outbound endpoint has a different shape, an https:// URL on port 9294.

Step 4: Reuse the Keychain Across Modules

Once you’ve created a QuotaGuard keychain, you can reuse it in any other HTTP module within your scenario or across scenarios. Select the existing keychain from the Proxy dropdown instead of creating a new one.

This is more secure than copying credentials into each module and makes key rotation easier.

Regional Proxy Endpoints

QuotaGuard offers multiple regional proxy endpoints across the US, Canada, the EU, Asia-Pacific, and South America. Use the one closest to your Make zone. Your specific endpoint hostname is shown in your QuotaGuard dashboard. The port is always 9293 for HTTP proxy connections.

Common Use Cases

Connecting to Firewalled Enterprise APIs

Many enterprise APIs (Salesforce, SAP, Oracle, custom ERPs) require IP allowlisting. Configure the proxy in your HTTP module, then provide your QuotaGuard static IPs to the API provider for their allowlist.

Banking and Payment Gateway Integrations

Financial services APIs often have strict IP-based access controls. A static IP from QuotaGuard satisfies these IP-allowlisting requirements while keeping your automation running on Make.

Google Workspace Context-Aware Access

If your organization uses Google Workspace with Context-Aware Access policies, Make’s shared IPs may be blocked. Route your Google API requests through QuotaGuard, then add your static IPs to the Context-Aware Access policy.

Database Connections via HTTP APIs

While Make’s built-in database modules don’t support proxy configuration, many databases offer HTTP/REST APIs:

• Airtable via REST API
• Firebase via REST API
• Supabase via PostgREST
• Neon via its SQL-over-HTTP endpoint

MongoDB’s Atlas Data API used to belong on that list; it reached end of life on 30 September 2025, so Atlas now needs a driver connection or a relay function rather than an HTTP call from Make.

Taking Supabase as the example, a Make a request module pointed at https://your-project.supabase.co/rest/v1/users with the proxy keychain selected reads that table through your static IPs. Send the key in an apikey header: publishable and secret keys are short strings rather than JWTs, and an Authorization: Bearer header belongs there only when you are acting as a signed-in user and have that user’s own JWT. Both roles require SELECT grants for the queried data. With RLS enabled, anon and authenticated also need a matching SELECT policy; secret keys use service_role and bypass RLS.

Use the HTTP module with QuotaGuard to access these APIs when direct database connections are blocked.

Avoiding Rate Limiting from IP Reputation

Make’s shared IPs are sometimes rate-limited more aggressively because they’re associated with high-volume automated traffic.

Legacy SOAP Services

QuotaGuard works transparently with SOAP endpoints. Set the Content-Type to text/xml or application/soap+xml, include your SOAP envelope in the body, and the proxy handles the connection.

Testing Your Implementation

Create a simple test scenario to verify your proxy configuration is working:

Step 1: Create a Test Scenario

1. Create a new scenario in Make
2. Add a trigger you can fire on demand. Webhooks > Custom webhook works well: Make gives you a URL you can call whenever you want to run the test
3. Add an HTTP > Make a request module after it

Step 2: Configure the Test Request

1. Set the URL to: https://ip.quotaguard.com
2. Set the Method to: GET
3. In Advanced settings, configure the Proxy with your QuotaGuard keychain

Step 3: Run the Scenario

Click Run once in the scenario editor, then call the webhook URL to start the run. The HTTP module’s response body should return JSON with your static IP:

{"ip":"<one of your two assigned QuotaGuard IPs>"}

The returned IP must match one of the two IPs assigned to your subscription, as shown in the QuotaGuard dashboard.

Step 4: Verify Load Balancing

You can run the test scenario multiple times. Each returned IP must match either assigned IP in your QuotaGuard dashboard; observing both addresses is not required for success. Allowlist both assigned IPs at the destination.

If you see a different IP (one of Make’s native IPs), the proxy configuration is not active. Double-check that the keychain is correctly selected in Advanced Settings.

Scenario Design Patterns

Pattern 1: Selective Proxy Routing

Only route sensitive requests through QuotaGuard to minimize latency and quota usage:

1. Module 1: Trigger (webhook, scheduler, etc.)
2. Module 2: HTTP request to public API (no proxy)
3. Module 3: HTTP request to firewalled API (QuotaGuard proxy enabled)
4. Module 4: Process and store results

This approach is cost-effective when only some of your API calls require static IPs.

Pattern 2: All-Proxy Scenarios

For scenarios where all endpoints require static IPs or consistent IP identity:

1. Create a single QuotaGuard keychain
2. Apply it to every HTTP module in the scenario
3. All traffic routes through your static IPs

Pattern 3: Error Handling with IP Verification

Add validation to your scenarios:

1. Before making the sensitive API call, call https://ip.quotaguard.com with the proxy
2. Use a Filter module to verify the returned IP matches either of your two assigned QuotaGuard IPs
3. Only proceed if the IP check passes
4. This catches misconfigurations before they cause production failures

Latency Considerations

Using QuotaGuard adds a network hop to your requests:

For high-volume or latency-sensitive scenarios, match your QuotaGuard region to your Make zone.

Timeout Settings: If you have strict timeouts configured on your HTTP modules (e.g., 5 seconds), consider increasing them slightly (e.g., 10-15 seconds) to account for the proxy routing. This is especially important for cross-region configurations.

Limitations

App-Specific Modules

Make’s built-in app modules (Slack, Gmail, Salesforce, etc.) make HTTP requests internally but do not expose proxy configuration. The proxy setting is only available in the HTTP module family.

Workaround: Use the HTTP module with the service’s raw API instead of the app-specific module. For example, use Salesforce’s REST API via HTTP instead of the Salesforce module.

Database Modules

Make’s native database modules (MySQL, PostgreSQL, MongoDB) connect directly to databases over TCP, not HTTP. These modules do not support proxy configuration.

Workaround: If your database offers a REST/HTTP API, such as Supabase’s PostgREST front end, use the HTTP module with QuotaGuard. Otherwise, build a lightweight API wrapper on a platform that supports SOCKS5 (a small Express server on Heroku or Render with QuotaGuard’s QGTunnel, for example) and call that from Make.

SFTP/FTP Modules

SFTP and FTP modules use non-HTTP protocols and do not support the HTTP proxy setting.

Workaround: For SFTP operations requiring static IPs, you would need an intermediary service. Contact QuotaGuard support for enterprise options.

Troubleshooting

403 Forbidden Errors

If you’re still seeing 403 errors after configuring the proxy:

1. Verify the proxy is active: Test with ip.quotaguard.com to confirm traffic routes through QuotaGuard
2. Check the destination allowlist: Ensure both of your QuotaGuard static IPs are added to the target service’s firewall
3. Confirm the keychain is selected: The proxy keychain must be explicitly selected in each HTTP module’s Advanced Settings

407 Proxy Authentication Required

Your proxy credentials are incorrect:

1. Verify the subscription proxy username and password in your keychain match the dashboard connection details, not your QuotaGuard account login
2. Check for extra spaces or special characters that may have been copied incorrectly
3. Ensure the host and port are exactly as shown in your dashboard

Connection Timeout

1. Verify the proxy hostname is correct (check your QuotaGuard dashboard)
2. Ensure port 9293 is used for HTTP proxy connections
3. Try increasing the timeout setting in the HTTP module’s Advanced Settings
4. Test from a different Make zone if possible

Wrong IP Address Returned

The proxy may not be configured correctly:

1. Verify the keychain is selected in Advanced Settings (not just created)
2. Check that you’re not testing a cached response
3. Try deleting and recreating the keychain
4. Ensure you’re testing with the HTTP module, not an app-specific module

Scenario Execution Time Increased

This is expected when routing through a proxy. How much the extra hop adds depends on which QuotaGuard region you use relative to your Make zone and on the destination you are calling; see Latency Considerations above. If this is problematic:

1. Ensure you’re using a QuotaGuard region that matches your Make zone
2. Only proxy requests that actually require static IPs
3. Consider batching API calls where possible to reduce the number of proxied requests

QuotaGuard Static vs QuotaGuard Shield

QuotaGuard offers two products for static IPs:

For most Make scenarios, QuotaGuard Static provides everything you need. Choose Shield if you’re handling protected health information (PHI), payment card data, or have specific compliance requirements such as HIPAA or PCI. Neither product decrypts your payload; Shield encrypts the hop between your app and the proxy with TLS.

Using QuotaGuard Shield through an HTTPS relay

Route individual HTTP > Make a request calls as Make → your HTTPS relay → QuotaGuard Shield → HTTPS API, using the shared relay pattern.

1. Follow the Shield Lambda relay setup. On the relay, set QUOTAGUARDSHIELD_URL to your exact Shield dashboard Connection URL (https://, port 9294) and RELAY_KEY to a long random secret.
2. In Make HTTP v4, set URL to the relay’s HTTPS Function URL, choose the destination’s method and body, and leave Advanced settings > Proxy unset. Select API key authentication and configure API key credentials: Key = your RELAY_KEY value, API key placement = In the header, API key parameter name = X-Relay-Key.
3. Add X-Target-URL with the full HTTPS destination URL, including any query parameters. The relay forwards Content-Type, Accept, and Authorization; supply the destination’s Authorization header if required. Prefix other destination headers with X-Fwd-: X-Fwd-X-Api-Key reaches the target as X-Api-Key. Relay control headers stay at the relay.
4. Verify routing with GET, no body or destination credentials, and X-Target-URL: https://ip.quotaguard.com. The response’s ip must match either assigned IP in your Shield dashboard. Allowlist both IPs at the destination, then restore the destination URL, method, body, and authentication headers.

The relay terminates Make’s HTTPS connection and can read request headers and bodies; treat it as a trusted processing component. Shield adds TLS between the relay and proxy. Only HTTP calls sent to the relay use this route.

Monitoring and Usage

Checking Your Quota

Log in to the QuotaGuard dashboard to view:

• Current monthly usage (request count and bandwidth)
• Remaining quota
• Usage trends over time

Operations Impact

Using a proxy in Make’s HTTP module does not consume extra Make operations. The proxy configuration is a setting within the existing HTTP module, not a separate step.

Ready to Get Started?

Get in touch or create a free trial account.

Get QuotaGuard for Make

View Make Integration Features

Contact Support