How to Allow make.com IP Addresses in Your Network

This guide explains how to allow make.com IP addresses in your firewall or network so your scenarios can connect reliably to web services, APIs, and databases.

When you run scenarios, the platform needs to reach external systems and, in many cases, those systems must also be able to reach back in. Correctly configuring allowlists for the documented IP ranges prevents connection errors and keeps your integrations running smoothly.

When You Need to Allow make.com IP Addresses

Most cloud services are open to public traffic and require no special configuration. However, you must allow the documented IP addresses in the following cases:

• Your server, database, or API is behind a firewall that blocks unknown IPs.
• You restrict access to specific IP ranges for security or compliance reasons.
• You use on-premises systems exposed via VPN or a limited public endpoint.
• Your webhooks, callback URLs, or inbound APIs accept traffic only from trusted sources.

If any of these apply, you should explicitly add the IP ranges used by the platform to your firewall rules or security groups.

Where to Find Official make.com IP Ranges

The official and current list of IP ranges is maintained in the product documentation. Always consult the latest version before updating any firewall rules, because IP ranges can change over time.

You can find the authoritative list of IP addresses here: Allow connections to and from Make IP addresses.

Use only the IP blocks listed on that page when configuring your network. Avoid copying IPs from unofficial sources, old screenshots, or scripts that are not linked from the official documentation.

How make.com Connects to Your Services

Scenarios communicate with your services in two main directions:

• Outbound connections from the platform to your apps, APIs, and databases.
• Inbound connections from your systems back to the platform, usually via webhooks or callbacks.

Knowing which direction a module uses helps you decide where to apply IP allowlists.

Outbound Connections from make.com

Most integration modules establish outbound connections from the platform to your infrastructure. Examples include:

• HTTP modules calling your REST or SOAP API.
• Database modules connecting to SQL servers through public endpoints.
• File transfer modules uploading or downloading from your storage.

In these cases, you must allow the designated IP ranges in:

• Network firewalls protecting your servers.
• Cloud security groups (for example, AWS Security Groups, Azure NSGs, GCP firewall rules).
• Application-level access control lists if they filter by source IP.

Inbound Connections to make.com

Some modules expect your systems to send data into the platform. Typical examples include:

• Webhook modules receiving POST requests from your application.
• Callback URLs for OAuth, payment gateways, or notification systems.
• Any external service that must send events into a scenario trigger.

For inbound traffic, your infrastructure sends requests to URLs hosted by the platform. You normally do not need to allow any IP addresses on your side for this direction, because your systems are the ones initiating the connection to the cloud endpoints.

However, if you reverse-proxy or restrict egress from your network, confirm that outbound traffic from your infrastructure to the platform’s domains is permitted.

Step-by-Step: Allow make.com IPs in Your Firewall

The exact steps differ by firewall vendor, but the overall process is similar. Always coordinate with your network or security team when changing production rules.

1. Retrieve the Official IP List

1. Open the documentation page: Allow connections to and from Make IP addresses.
2. Identify the IP blocks or ranges that apply to your account and region, if specified.
3. Copy the values exactly as shown, including subnet masks (for example, /24, /32).

2. Identify the Systems That Need Access

List all resources that your scenarios must communicate with:

• Web APIs or applications restricted by source IP.
• On-premises or cloud databases behind private firewalls.
• FTP, SFTP, or other file servers with limited access.
• Any private endpoints that block general public traffic.

For each system, confirm which firewall, gateway, or security group controls incoming connections.

3. Create Allow Rules for make.com IP Ranges

In your firewall or security console, create rules that:

• Source: Use the official IP ranges from the documentation.
• Destination: The IP or subnet of your protected service.
• Ports: Open only the ports required by your service (such as 80, 443, or database ports).
• Protocol: Typically TCP; confirm if your service needs others.

Apply the changes and ensure they are saved and deployed according to your organization’s change management policies.

4. Test Connectivity from a Scenario

After changing your rules:

1. Run or schedule a scenario that connects to the protected service.
2. Check the module execution details for connection errors or timeouts.
3. Verify that all required operations (read, write, update) succeed.

If connections still fail, inspect your firewall logs to see if any packets from the documented IP ranges are being blocked.

Maintaining Your make.com IP Configuration

Because cloud architectures evolve, IP ranges can occasionally be updated. To avoid unexpected disruptions, implement these practices:

• Bookmark the official IP documentation page and review it periodically.
• Subscribe to product or status notifications if available, so you learn about critical changes in advance.
• Document which systems rely on these allowlists, including rule names and locations.
• Coordinate firewall updates with maintenance windows where possible to prevent downtime.

Common Issues When Allowing make.com IPs

If scenarios cannot reach your resources even after updating the rules, consider the following possibilities:

• The wrong IP version (IPv4 vs IPv6) was used.
• Rules were added to the wrong firewall layer or security group.
• Network address translation (NAT) changes the apparent source IP, and an upstream device is blocking traffic.
• Application-level access control still blocks requests despite network rules.
• Your service listens on non-standard ports that are not open to the documented IP ranges.

Review both your firewall configuration and application logs, and confirm that traffic from the correct IP ranges is arriving and being accepted.

Advanced Considerations for make.com Integrations

For complex environments, you might need additional planning:

• Segmentation: Decide which network segments can be reached from the integration platform.
• High availability: Ensure that redundant firewalls share consistent rules for the IP ranges.
• Compliance: Confirm that granting access from these IPs complies with internal and external regulations.
• Monitoring: Set up alerts for denied connections that should be allowed, so you can react quickly to configuration drifts.

Get Help With make.com Network Configuration

If you are unsure how to interpret the official IP list or how to apply it to your specific firewall, involve your network team or consult with integration specialists.

For broader automation strategy, system architecture, and technical consulting related to integrations and IP access control, you can explore expert services at Consultevo.

By correctly allowing the documented IP ranges and maintaining them over time, you ensure that your scenarios can connect securely and reliably to every system they need, without unnecessary exposure of your infrastructure.

Need Help With Make.com?

If you want expert help building, automating, or scaling your Make scenarios, work with ConsultEvo — certified workflow and automation specialists.

Get Help