Every UiPath rollout we've run inside a corporate network hits the same wall in week one: Studio installs fine, but robots can't reach the services they need to actually run. It's rarely a UiPath problem — it's a firewall rule nobody wrote yet.
UiPath isn't one endpoint. It's a handful of distinct traffic categories, each with a different owner on the vendor side and a different reason your network team needs to know about it.
The four categories that matter
Orchestrator connectivity. If you're running Orchestrator (on-prem or Automation Cloud), Studio and every Robot need outbound access to it on HTTPS. This is usually the one IT already expects — it's the rest of the list that trips people up.
Package and activity feeds. Studio pulls activity packages and updates from UiPath's package feed the first time you use a new activity pack, and periodically after that. Block this and a project that worked yesterday starts failing on a machine that "hasn't changed."
Telemetry and licensing checks. UiPath phones home for licensing validation and diagnostic telemetry. This traffic is low-volume but non-negotiable — without it, Studio and Robot will eventually refuse to run even with a valid license.
Cloud storage and integration endpoints. Any automation that touches SharePoint, a cloud mailbox, or a third-party API needs its own outbound rule, separate from UiPath's own infrastructure. This is the category we see missed most often, because it's specific to what each individual bot does.
The pattern we see over and over: the firewall exception request goes in for "UiPath," gets approved for Orchestrator only, and three other categories of traffic quietly fail for weeks before anyone notices.
What to ask your network team for
Rather than requesting "access for UiPath," request it by category — Orchestrator, package feed, telemetry, and per-integration endpoints — and confirm each one against UiPath's current documented domain list before go-live, since these do change with product updates. A five-minute conversation with your network team before deployment saves a multi-day debugging session after it.
If your organisation is mid-deployment and hitting connectivity errors that don't make sense, this is almost always where the answer is hiding.