Rovo outbound IPs

[rachit_sharma]

Hi Team

I have integrating rovo workflow with my agent. I am posting the prompts to rovo and getting callback on one of my applications's endpoint. My infra is private so to whitelist rovo callbacks I need rovo oubound IPs. How to get rovo outbound IPs. Are these IPs fixed?

[Gabriela]

Rovo's callbacks leave Atlassian cloud through the same egress proxies every Atlassian cloud product uses, so there's no Rovo-specific IP list to allowlist. What you want are the outbound ranges published in the machine-readable file at https://ip-ranges.atlassian.com. Each entry carries a `direction` field, so filter for the ones tagged `egress` and allowlist those on your firewall. The same set is described on Atlassian's "IP addresses and domains for Atlassian cloud products" support page.

As for whether they're fixed, no, and Atlassian says so plainly. That file is the source of truth and the ranges can change. They keep changes to a minimum but recommend pulling the JSON programmatically and updating your allowlist rather than hardcoding a snapshot. There's also an SNS topic (arn:aws:sns:us-east-1:745490931007:atlassian-public-ip-changes) you can subscribe to for a notification whenever the file updates.

One caveat before you build around it. Those egress ranges are shared across Jira, Confluence, Forge, Rovo and the rest, so allowlisting them opens your endpoint to Atlassian's outbound traffic broadly. If your endpoint needs to confirm a call genuinely came from your Rovo integration, pair the IP allowlist with a shared secret or signature check on the callback payload.

[Arkadiusz Wroblewski]

Nice AI hallucination there.

I would be careful with this answer.

The author has not even specified what performs the callback, and the architecture has not been confirmed either. Without that context, this answer is mostly guessing.

[Gabriela]

@Arkadiusz Wroblewski — the point that it depends on the integration is fair, and I've reworked the answer around it below. The "hallucination" call isn't, though. The egress ranges, the direction field and the change-notification topic are all straight out of Atlassian's own docs, not invented — the answer was too general for an under-specified question, which is worth correcting, but tagging a fellow volunteer's post as an AI hallucination in public is a heavier call than that warranted. A first pass that gets sharpened together is how the forum is meant to work.

For @rachit_sharma — the constant is that Rovo has no single fixed outbound IP. From there it depends on what's sending the callback:

- Jira Automation "Send web request" (including a Rovo-triggered rule) leaves through Atlassian's web proxy, so the jira egress entries in ip-ranges.atlassian.com are the ones to allowlist.
- A Forge-based Rovo action egresses from Forge, which has no stable published IP range (open request FRGE-276), so allowlisting by IP won't hold there.
- An external tool over the Rovo MCP server sends from that tool's own IPs, not Atlassian's, with domain-based access rather than CIDR.

@rachit_sharma, which of those is doing the callback for you? That settles it. And since your infra is private, a reverse proxy in front of the endpoint, or a signature check on the payload, is steadier than tracking IP ranges whichever way it goes.

[Arkadiusz Wroblewski]

Hello @rachit_sharma 

Rovo does not have one fixed outbound IP address.

Are you using a Forge-based Rovo agent/action, the Rovo Agent Connector, Jira Automation with Send web request, an MCP integration, or something else?

When your Infra is private, would a reverse proxy be more stable?

Best,

Arek🤠

[rachit_sharma]

We're using Atlassian Studio Automation (workspace-level flow, not Jira project automation, not Forge, and not the Rovo Agent Connector).

Flow:

1. Our external app (agent on a private staging network) calls an Incoming webhook on Studio Automation (api.atlassian.com/automation/sc3/o/studio/...).
2. The rule runs the Use Rovo action (Studio Automation Rovo step).
3. The rule then uses Send web request to POST the Rovo answer back to our callback URL:
   POST My agent callback url
   Body: plain text (Content-Type: text/plain), not JSON-RPC or MCP.

We are not using a Forge Rovo app, Rovo Agent Connector, or MCP for this callback.

What we need for firewall allowlisting:
The source IP ranges used by Studio/Jira Automation Send web request when making outbound calls to our private endpoint.

Can you confirm:

1. Studio Automation Send web request uses the same outgoing IP ranges as Jira Cloud Automation?
2. Whether there is a narrower list for Studio (studio.atlassian.com) vs Jira project automation?
3. Whether the incoming webhook path (api.atlassian.com/automation/...) has any different egress requirements on our side (we call Atlassian outbound from staging)?

Our callback endpoint is on a private corporate network; we need to allowlist Atlassian egress IPs inbound to that host on port 443 (or our reverse proxy).