HTTP and Custom Connectors

Analogy categoryAnalogies

Calling External APIs with the HTTP Action

The premium 'HTTP' action lets a flow call any REST endpoint directly, specifying method, URI, headers, and body, which makes it the escape hatch for integrating with systems that don't have a pre-built Power Automate connector. Unlike connector-specific actions that pre-parse responses into typed dynamic content, the HTTP action returns a raw string body that must be parsed, typically with a 'Parse JSON' action against a schema (either hand-written or generated by pasting a sample payload), before individual fields become usable dynamic content elsewhere in the flow. Because 'HTTP' is a premium action, using it in a flow requires at least a per-user or per-flow Power Automate premium license, which is a common licensing surprise for teams that started on seeded/free licensing tied to Microsoft 365.

🏏

Cricket analogy: The HTTP action as an escape hatch is like a team bringing in a specialist net bowler to simulate an opponent's unusual bowling action that the regular training setup doesn't cover, a direct workaround for a gap in the standard toolkit.

Building a Custom Connector

A custom connector is a reusable, first-class connector definition (built from an OpenAPI/Swagger definition, imported from a Postman collection, or authored manually in the connector wizard) that wraps a REST API's operations behind named actions with typed inputs and outputs, so anyone building a flow sees 'Get Customer Balance' with clearly labeled parameters instead of a raw HTTP action with a hand-typed URI. Custom connectors centralize authentication configuration too, supporting API key, OAuth 2.0, Basic auth, or Azure AD-based authentication defined once at the connector level, so individual flow makers just pick a connection rather than juggling secrets and token refresh logic themselves inside each flow. Once published (as an organization-scoped custom connector, not marketplace-published), it appears in the connector picker just like Microsoft's own connectors and can be shared with specific users, security groups, or the whole environment via standard Power Platform sharing controls.

🏏

Cricket analogy: A custom connector wrapping raw HTTP calls behind named actions is like a franchise's analytics team packaging raw ball-tracking data into a clean 'Get Bowler Economy Rate' dashboard widget, so coaches don't touch the raw feed.

Defining Request and Response Schemas

When authoring a custom connector manually, each operation's request body and response are defined using JSON schema examples in the connector wizard's 'Import from sample' feature: paste a realistic sample request or response and the wizard infers the schema, including nested objects and arrays, which then surfaces as individually named dynamic content fields (e.g., 'customer > address > postalCode') for flow makers, exactly like a native connector's outputs.

Handling Pagination, Retries, and Errors

Many REST APIs paginate large result sets using either an offset/limit pattern or a 'next link' URL returned in the response body, and a flow consuming such an API typically needs a 'Do until' loop that calls the endpoint, extracts the next page token or URL with 'Parse JSON', and repeats until no further pages are indicated, since neither the raw HTTP action nor a custom connector's individual action automatically pages through results the way some native connectors' 'List' actions do internally. For resilience, both the HTTP action and custom connector actions expose a 'Configure run after' setting to branch on failure, and the HTTP action additionally supports a built-in retry policy (configurable count and interval) for transient failures like 429 (throttled) or 503 (service unavailable) responses, which should be tuned to respect any 'Retry-After' header the API returns rather than retrying blindly on a fixed interval.

🏏

Cricket analogy: Paging through results with a 'next link' token is like following an over-by-over highlights reel where each clip ends with a pointer to the next over's clip, requiring you to fetch each segment in turn rather than getting the whole innings at once.

text

// HTTP action configuration
Method: GET
URI: https://api.example.com/v2/customers?limit=100&offset=@{variables('offset')}
Headers: { "Authorization": "Bearer @{variables('accessToken')}" }

// Do until loop condition (pseudocode)
Do until: variables('nextPageUrl') is empty
  HTTP GET variables('nextPageUrl')
  Parse JSON (body('HTTP'))
  Set variable nextPageUrl = body('Parse_JSON')?['nextLink']

The HTTP action's built-in retry policy defaults to a fixed exponential backoff and does not automatically read a 'Retry-After' response header; for APIs that return an explicit Retry-After value on 429 responses, implement custom logic (a Delay action reading that header's value before retrying) rather than relying on the default policy, or you risk retrying too aggressively and getting further throttled.

The premium 'HTTP' action calls any REST endpoint directly but requires 'Parse JSON' to turn its raw string body into usable dynamic content.
Using the HTTP action requires at least premium per-user or per-flow licensing, a common surprise for Microsoft 365-seeded tenants.
Custom connectors wrap a REST API behind named, typed actions and centralize authentication (API key, OAuth 2.0, Basic, Azure AD) in one place.
Custom connectors can be built from an OpenAPI definition, a Postman collection, or authored manually with 'Import from sample'.
Neither the HTTP action nor custom connector actions auto-paginate; use a 'Do until' loop following next-page tokens or offset/limit parameters.
'Configure run after' lets a flow branch on failure paths for both HTTP and custom connector actions.
The HTTP action's default retry policy doesn't read 'Retry-After' headers automatically, so build custom delay logic for APIs that specify one.