Incoming and outgoing domains and IP addresses
Outgoing IP addresses
Rewst uses static NAT Gateway IPs for outbound connections from our services hosted in AWS. These IPs should be included in any necessary allow lists for outbound connections.
North America
US
13.58.15.1418.218.107.1983.139.170.31
Europe
UK
18.132.221.22618.171.196.23.9.62.134
DE
3.67.166.233.69.14.2223.76.128.23
Australia
13.210.158.9113.237.143.17152.65.55.149
Hostnames with dynamic IPs
For the following services, Rewst employs application load balancers, resulting in dynamic IP addresses. We recommend using DNS names when adding these services to your allow list.
North America
US
app.rewst.io: Front-end web application for user logins.engine.rewst.io: Back-end application handling workflow execution, including webhooks.api.rewst.io: API for app and engine communication.
Europe
UK
app.eu.rewst.io: Front-end web application for user logins.engine.eu.rewst.io: Back-end application handling workflow execution, including webhooks.api.eu.rewst.io: API for app and engine communication.
DE
app.rewst.eu: Front-end web application for user logins.engine.rewst.eu: Back-end application handling workflow execution, including webhooks.api.rewst.eu: API for app and engine communication.
Australia
app.rewst.asia: Front-end web application for user logins.engine.rewst.asia: Back-end application handling workflow execution, including webhooks.api.rewst.asia: API for app and engine communication.
Third-party services
featureassets.org: A Statsig API for feature flaggingprodregistryv2.org: A Statsig API for feature flagging
Wildcard domains
Rewst customers can create subdomains (*.rew.st) to host their apps. These domains are fully managed by Rewst, making them easier to set up and maintain. Depending on your integration needs, you should also include these domains in your allow lists to ensure proper connectivity.
Custom domains
In addition to wildcard subdomains, Rewst customers can configure and use their own custom domains to host their apps. These custom domains should also be added to your allow lists as needed for integrations. Hosting apps on a domain you own helps maintain a professional and consistent brand presence for your customers and internal users.
Important information for RMM integrations and Agent Smith
When Rewst initiates a PowerShell task through an RMM platform, it is the endpoint located within the customer’s environment — such as a domain controller, Exchange server, or workstation at the customer’s office — that connects to a webhook. This webhook is dynamically created during the execution of the associated Rewst workflow. The connection targets the dynamic hostname beginning with engine.*, based on the customer’s region.
These webhook URLs are designed for one-time use. If a security system outside the endpoint attempts to scan, inspect, or pre-fetch the URL before the PowerShell task executes, it can consume or invalidate the link. This can prevent the customer’s device from successfully completing the connection. Examples of systems that may cause such interference include:
ThreatLocker
Hardware firewalls with URL filtering: e.g., Fortinet, Palo Alto Networks, SonicWall, Sophos
Web security gateways: e.g., Cisco Umbrella, Zscaler
DNS filtering services: e.g., DNSFilter, OpenDNS
Proxy servers performing content or URL inspection
Antivirus or EDR platforms with network traffic scanning features: e.g., CrowdStrike Falcon, Sophos Intercept X
It is important to note that SSL inspection or filtering performed directly on the endpoint, such as a server or workstation, generally does not cause problems. However, if SSL inspection, URL filtering, or pre-fetching occurs at the network level — for example, by a firewall, proxy, or upstream security device — it may prematurely trigger the webhook URL.
To avoid disruption, it’s recommended to configure allowlists or bypass rules in network security systems to exclude these one-time webhook URLs from scanning, pre-fetching, or blocking.
Email filter considerations
In environments where Rewst webhook URLs are sent via email, such as in workflow notifications, approval requests, or alert messages, it's important to consider how email security systems interact with these links.
Many modern email protection platforms automatically scan, rewrite, or pre-fetch links to check for threats. This behavior can prematurely trigger a one-time-use webhook URL, making it unavailable when the actual endpoint tries to connect.
Examples of email security solutions that could interfere include:
Microsoft Defender for Office 365 (Safe Links)
Proofpoint Email Protection
Mimecast Secure Email Gateway
Barracuda Essentials
Sophos Email
Cisco Email Security Appliance (ESA)
Recommendations
Add the Rewst Engine* Hostnames for your region in any Safe Links or URL Rewriting policies.
Exclude Rewst Engine* Hostnames for your region in URLs from pre-click scanning and link validation where possible.
Review email security logs if webhook links fail immediately after being sent via email.
Taking these precautions helps ensure that webhook URLs embedded in emails are not consumed before they are properly triggered by the intended device or user action.
Additional troubleshooting
If issues persist, it may be necessary to extend allowlisting beyond just the one-time webhook URLs. Some security systems could also interfere with broader Rewst operations by inspecting or blocking traffic to core Rewst services. In these cases, ensure that the following endpoints are allowed and not inspected or altered:
.rew.st (wildcard for all Rewst App Builder subdomains)
Best practice
First review logs — including firewall logs, proxy logs, endpoint protection logs, and email filtering logs — to determine whether connections or emails containing Rewst webhook URLs are being blocked, inspected, or altered. Only after confirming should allowlisting or bypass rules be added.
Last updated
Was this helpful?