> For the complete documentation index, see [llms.txt](https://help.rhythms.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.rhythms.ai/connectivity/rhythms-outbound-ip-ranges-for-allowlisting.md).

# Rhythms outbound IP ranges for allowlisting

When Rhythms connects out to one of your systems — a database, an on-premises API, a self-hosted MCP server, a Jira Data Center instance — the connection originates from static addresses that Rhythms owns. If that system restricts inbound traffic by source IP address, add both ranges below to its allowlist.

These are outbound ranges only. They are the addresses Rhythms connects *from*. Nothing here opens inbound access to your Rhythms workspace.

## The ranges

**Both ranges are required.** Traffic can originate from either one.

| Range             |
| ----------------- |
| `20.72.177.36/30` |
| `104.40.3.64/30`  |

## Hostname allowlist or IP allowlist: which one you need

A hostname allowlist and an IP allowlist are different controls. Which one you need depends on the direction of the traffic and on what the filtering system can see.

* **Your people reaching Rhythms.** A web proxy or firewall that filters your users' outbound web traffic by hostname should allow `https://app.rhythms.ai/**`. It is inspecting requests leaving your network, so it can match a hostname, and the IP ranges above are irrelevant to it.
* **Rhythms reaching your system.** A firewall in front of a database, an internal API or a self-hosted MCP server sees an inbound connection with a source IP address. There is no hostname for it to match, so it needs the IP ranges above.

The two controls are independent. Allowing the hostname does not allow the IP ranges, and allowing the IP ranges does not allow the hostname. Cloud services that Rhythms connects to through their public APIs — Google Sheets, HubSpot, Linear, Atlassian Cloud and similar — normally need neither; the ranges matter when your system sits behind a firewall you control.

## If these ranges ever change

The ranges above are static and are not rotated. If Rhythms ever needs to change them, affected workspace administrators are notified at least **30 days** in advance, and the old and new ranges run **in parallel** through the transition so a correct allowlist never stops working.

## Frequently asked questions

**Do I really need both ranges?** Yes. Rhythms may connect from either range, and an allowlist with only one of them will fail intermittently.

**Does allowlisting these ranges expose my Rhythms workspace?** No. The ranges describe where Rhythms connects from when it reaches out to your systems. They do not open any path into your workspace, which is reached only through your users' sign-ins.

**My connector works without allowlisting. Do I still need this?** Only if the system Rhythms connects to filters inbound traffic by source IP. If the connector already works, that system is not filtering, and no change is needed.

## Related articles

* [Manage connectors for your workspace](/connectivity/manage-connectors-for-your-workspace.md)
* [Get access to the Rhythms REST API](/connectivity/api-reference/get-access-to-the-rhythms-rest-api.md)
* [Troubleshooting and Support](/workspace-settings-and-administration/troubleshooting-and-support.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://help.rhythms.ai/connectivity/rhythms-outbound-ip-ranges-for-allowlisting.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `build a script that syncs our docs to a CMS` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.