When to Build a Custom IntegrationHub Spoke (and When Not To)

IntegrationHub is ServiceNow's answer to "how do we call external systems from a flow without writing raw REST calls in every flow that needs it." A custom spoke wraps an external API as a set of reusable, versioned actions with defined inputs and outputs. The tooling makes building one deceptively easy — which is exactly why teams end up with sprawl.

What a spoke actually buys you

Without a spoke, every flow that calls an external API embeds its own REST message configuration, its own auth handling, its own response parsing. Change the API's auth method and you're hunting down every flow that calls it individually. A spoke centralizes all of that: one place defines the connection, the auth, and the action's input/output schema, and every flow that uses it just calls a named action with typed parameters.

That's the real value — not "it's easier to call an API," but "there's exactly one place to fix it when the API changes."

When a custom spoke is worth building

• The API is called from more than one flow, or clearly will be soon. A single one-off REST call in a single flow doesn't need the overhead of a full spoke definition.
• The integration needs to be governed — access to it should go through defined actions rather than raw HTTP configuration anyone can edit inline.
• The API is complex enough that wrapping it (pagination, auth refresh, response transformation) saves real duplicated effort across consumers.

When it's overkill

For a single flow calling a simple internal endpoint once, a plain REST step inside the flow is faster to build, easier to read in context, and doesn't add another artifact to a spoke inventory nobody's tracking. Building a spoke for every API call "for consistency" produces the same sprawl problem RPA programs hit with bot registries — a pile of thinly-used integrations nobody remembers the purpose of.

Version your spoke actions like an API contract

Because multiple flows depend on a spoke's action signatures, changing an input or output on an existing action is a breaking change for every consumer, even if it doesn't look like one in the spoke editor. Add new fields rather than renaming existing ones, and version the action (or the spoke) explicitly when a breaking change is unavoidable — the same discipline you'd apply to any shared API, because that's what a spoke actually is.

The right mental model: a spoke is a small internal API product, not a convenience wrapper. Build it when more than one consumer justifies that overhead, and maintain it with the same care you'd want from a team that owned an API you depended on.