Genesys Cloud IP ranges for firewall allow-lists, filtered by region and purpose

The integration is built and tested. The Architect flow calls a data action, the data action calls an API behind the corporate firewall, and in the test org everything works because the test endpoint sits in a permissive network zone. Production is different. The network team needs a change request listing exactly which source addresses Genesys Cloud will use, in which region, for which service – and they need it before the change advisory board meets on Monday.

This is not an exotic request. Email relays must accept Genesys’ senders, Open Messaging middleware receives Genesys webhooks, an AudioHook receiver takes streamed audio, a bring-your-own bot or speech engine is called from Genesys, and a local key manager for recording encryption must accept Genesys callouts. Every one of those is an allow-list rule, and every rule needs an authoritative, current source. Getting it wrong either breaks the integration or opens more of the network than anyone intended.

Genesys documents this carefully in its Resource Center article on IP addresses for the firewall allowlist. Genesys Cloud runs in a public cloud where addresses are expected to change, and all client connections – BYOC Premises Edges, WebRTC clients and hard phones – start as outbound connections to Genesys Cloud services. Where firewalls restrict access, Genesys recommends allowing client outbound access on the specified ports to any IP destination. For public-facing media services Genesys owns specific /20 and /21 CIDR ranges, which the article lists; other addresses come from third-party provider pools.

For traffic from Genesys to your endpoints, the article is precise: Genesys Cloud uses certain addresses for outbound recording encryption key traffic, data action traffic, Open Messaging, AudioHook, SMTP and IMAP, and you retrieve them by calling GET /api/v2/ipranges. The FAQs for Bot Connector, Audio Connector, AudioHook Monitor and BYOT speech-to-text point to the same endpoint, and the Bot Connector FAQ tells you to use the range marked bot-connector. Whenever possible, Genesys announces changes to the data action and SMTP lists under Features coming soon.

So the native source is not a PDF or a static table – it is a live API, and that is exactly right for address space that changes. The catch is ergonomic rather than technical. A JSON payload is perfect for automation and awkward for a human preparing a change request: it has to be filtered to one region and a handful of services, sorted sensibly, sized, and pasted into a document someone else will approve.

The endpoint returns an IpAddressRangeListing: an entities array of IpAddressRange objects, each with a cidr, a service, a region and a direction. The Platform API defines thirteen service values – api, data-actions, smtp, imap, graphapi, audiohook, open-messaging, tts-connector, audio-connector, byot-stt, bot-connector, byo-smpp and encryption – and three direction values: inbound, outbound and both, from Genesys Cloud’s perspective. The call takes no parameters, needs a valid OAuth token, and lists no specific permission or role.

IP Ranges signs in once with an OAuth client-credentials grant for your org and makes that one call. In our experience the response spans every Genesys region, each entry tagged with its own region, so the region you pick at sign-in decides only where your org authenticates – not which data you can see. That shaped the whole design: the region control is a client-side filter over data already loaded, never a re-authentication or a second fetch, and switching regions is instant.

The table is built from the payload rather than hard-coded. CIDR block comes first with a derived Addresses column beside it, then purpose, direction and region, then any extra fields Genesys adds in future, humanised automatically. Purpose chips – one per service, with live row counts – map the raw codes to friendly labels such as Data Actions, AudioHook or Recording Encryption, and new service values appear as new chips without a release. The chips multi-select, so SMTP plus IMAP for a mail flow is two clicks.

Filters stack: a region dropdown built from the regions actually present, with friendly names such as EU (London); an All, Inbound, Outbound or Both control, shown only when the payload carries at least two direction values; and a free-text search across every field. Clicking the CIDR header sorts numerically by parsed address and then prefix, with IPv6 after IPv4, so the export reads like a routing table rather than an alphabetised accident.

Four stat tiles track the filtered view live: ranges in view with the IPv4 and IPv6 split, distinct purposes, total IPv4 addresses and regions. The Addresses value is the full block size, 2 to the power of 32 minus the prefix, network and broadcast included; it is left blank for IPv6, where the numbers are meaninglessly large. A security reviewer asking “how much address space are we actually opening?” gets an answer, not a shrug.

Back to Friday afternoon. The engineer signs in with the org’s existing client-credentials client, picks EU (London) in the Region dropdown because that is where the org is deployed, and clicks the Data Actions chip. The table drops from the full catalogue to just the rows that matter, the stat tiles confirm a single region and a single purpose, and the Addresses total tells the firewall team exactly how much source address space the rule will admit. A click on the CIDR header puts the rows in numeric order.

The same pattern covers the rest of the integration estate. A mail flow needs SMTP and IMAP together, which is two chips. An AudioHook receiver or a bring-your-own speech-to-text engine is one chip each, matching the service names in the Genesys FAQs. The free-text search finds a specific block when a firewall log shows an unexpected source and someone asks whether it belongs to Genesys. Each finished view exports to the Excel workbook, which goes straight onto the change request with the fetch timestamp in its footnote – a few minutes’ work rather than an afternoon of copying JSON into a spreadsheet by hand.

There is a second Genesys allow-list, and mixing the two up is a classic source of confusion in security reviews. Under Organization Settings, the Allowed IP Addresses feature limits access to your Genesys Cloud account to users and API applications visiting from CIDR blocks you specify – up to 150 of them, IPv4 only. Genesys notes that IP addresses from Data Actions integrations are automatically allowed, and warns against enabling the feature if you use dynamic IPs.

That control protects your Genesys org from unexpected sources. The ranges from /api/v2/ipranges serve the opposite job: they tell your firewall which Genesys sources to trust when Genesys calls you. Both matter, and they belong in different change requests with different approvers. We find that drawing the distinction explicitly – in the design documentation and in the ticket – saves a round of questions from every security team we work with.

Address space changes, so the app treats every view as a dated snapshot. A footnote records the exact source and the fetch timestamp; Refresh re-queries live, silently renewing an expired token once. CSV, a themed Excel workbook assembled entirely in the browser, and copy-as-JSON all contain exactly the current filtered and sorted view, and file names carry the region filter. The guide’s rule is simple: refresh before every change ticket and quote the timestamp. The app calls one Genesys data endpoint, has no write surface, and keeps the client secret server-side.

Small as it is, this app came out of the same method as our larger builds. Our IT Systems, Telecoms & SIP Engineer wrote the requirements from real firewall and SBC change requests; a Software Developer built a zero-build single-page client with schema tolerance, so an upstream rename degrades gracefully rather than breaking; and testing covered single-region orgs, payloads without a direction field and expired tokens. In Run & evolve, our release readiness reviews of Genesys release notes and our Support Engineers use it whenever a client’s network team asks what changed – backed by the whole practice.