Do I need APIM between Fabric and vendor APIs?

If the main goal is controlling where outbound traffic can go, start by checking whether the Fabric workload and connector you plan to use can actually route through your chosen gateway and network path. A gateway is not automatically a general-purpose tunnel for every Fabric operation. Confirm the supported connection path and external endpoint behavior before designing around it.

If that checks out, a gateway with centralized firewall egress may be enough. Keep the path as simple as possible, then test representative API calls, throughput, retries, and timeouts. Extra network hops can add latency and troubleshooting work, but the actual impact depends on the workload and configuration.

APIM is useful when you need API-management features, not just because traffic is going to a public API. It can provide a managed interface, policy enforcement, rate limits, transformations, or a shared governance point. Whether it can provide the credential handling or caching you want depends on how the integration is designed.

If this is a one-off ingestion path and your organization does not already operate APIM as a shared service, it may be extra cost and another component to maintain. If APIM is already part of the standard platform and several teams can use it, the case is stronger. I’d define the requirement APIM solves before adding it.

Be precise about the threat you are addressing. A firewall can restrict outbound destinations and provide centralized monitoring, which may help reduce the chance of unauthorized egress. But routing through a firewall alone does not prevent every form of data exfiltration, especially if allowed destinations or identities are too broad.

Pair network controls with least-privilege credentials, careful secret storage, destination allowlisting where feasible, and logging. Also check whether the vendor publishes stable endpoint ranges or other details your firewall policy can reliably use. The right controls depend on your data sensitivity and threat model.

For a hub-and-spoke setup, decide where the gateway belongs based on the documented Fabric gateway requirements and the network team's ownership model. Check subnet sizing, connectivity, DNS, routes, and firewall rules, then verify the deployed path with a real connection. Avoid assuming that placing a component in the hub automatically makes every Fabric request traverse it.

I wouldn’t assume multiple firewalls will cause a bottleneck, but I also wouldn’t guess about performance from the architecture diagram. Measure end-to-end duration and throughput with realistic payloads, pagination, concurrency, and vendor rate limits. Those can matter as much as network latency.