External Services
External Services is the declarative Salesforce feature that imports an external REST API into Flow as a set of invocable actions, without writing Apex.
Definition
External Services is the declarative Salesforce feature that imports an external REST API into Flow as a set of invocable actions, without writing Apex. You point External Services at an OpenAPI specification (the JSON or YAML description of the API), Salesforce parses the spec, generates strongly typed Apex wrapper classes, and exposes each endpoint as a Flow action that admins can drop into a flow like any other action.
The feature solves the problem of "I want to call this API from a flow, but I do not want to write Apex." Before External Services, every external integration required a developer to build an @InvocableMethod wrapper, define input and output classes, and deploy it. With External Services the wrapper is generated automatically from the spec. The trade-off is rigidity; the generated code reflects the spec exactly, and complex authentication or response handling still needs custom Apex.
How External Services turns an OpenAPI spec into Flow-ready integration actions
The OpenAPI 2.0 and 3.0 import process
External Services parses an OpenAPI specification document (Swagger 2.0 or OpenAPI 3.0) to learn about the API's endpoints, parameters, request bodies, response shapes, and authentication scheme. The spec can be pasted directly, uploaded as a file, or fetched from a URL. Each operation in the spec becomes one Flow action. Salesforce supports the most common spec features (paths, parameters, request bodies, response schemas, basic auth, API key auth) but rejects spec elements it cannot map (complex polymorphic responses, certain auth flows, file uploads with multipart encoding).
Generated Apex classes and the invocable bridge
After import, Salesforce auto-generates Apex classes named like ExternalService_YourServiceName with one inner class per operation. The classes are not editable in the UI; they regenerate every time you re-import the spec. Each operation class implements @InvocableMethod, which is how Flow Builder finds it. The generated code uses Named Credentials to handle authentication, so credentials are managed in Setup rather than baked into the spec.
Named Credentials as the authentication layer
External Services pairs every imported service with a Named Credential. The Named Credential stores the endpoint URL, the auth type (OAuth, API Key, AWS Signature, Basic), and the actual secret in an External Credential. The spec defines the auth shape; the Named Credential fills in the values. Changing the auth credential after import does not require re-importing; just edit the Named Credential and the next call uses the new credential. This separation is what makes External Services deployable across environments.
Using the actions in Flow
Once the spec is imported, every operation appears in Flow Builder's Action picker under the service name. Pick the action, configure inputs (path parameters, query parameters, request body fields), and bind outputs to flow variables. Output bindings are typed; a response object with fields name, age, email exposes those fields directly without manual JSON parsing. The action runs synchronously when the flow executes; for async work, wrap the flow in a Queueable Apex job or use Platform Events.
What External Services cannot handle
The feature works for clean REST APIs with simple auth, structured request/response bodies, and OpenAPI spec compliance. It struggles with multi-part file uploads, OAuth flows with token refresh, polymorphic response types (oneOf, anyOf), webhooks, GraphQL APIs, and SOAP. For these cases, fall back to hand-written Apex callouts. External Services is the 80% solution; the remaining 20% is genuinely complex and benefits from Apex flexibility.
Versioning and re-importing the spec
When the external API releases a new spec version, re-importing into External Services replaces the generated Apex classes with new versions. Existing flows continue to reference the old action signatures until you update them. Breaking changes in the spec (renamed fields, removed endpoints) cause the generated class to fail compile during re-import, surfacing the issue early. Re-imports are non-destructive on flows but require manual flow updates if the action signature changed.
External Services versus DataWeave versus custom Apex
Three integration paths in Salesforce. External Services for spec-driven REST API calls in Flow. DataWeave (recently added) for declarative payload transformation. Custom Apex for everything that does not fit the first two. The decision tree: if the API has a clean OpenAPI spec and the flow context is sufficient, use External Services. If the integration needs complex transformations on payloads, layer DataWeave on top. If the requirements exceed both, write Apex.
Registering an External Service and using its actions in Flow
External Services setup is two steps: create the Named Credential for authentication, then register the service against an OpenAPI spec. The service is then usable in any flow on the same org.
- Create the Named Credential
Setup, Named Credentials. New Named Credential. Configure URL, authentication type, and the External Credential (which stores the actual API key, OAuth token, or password). Named Credentials must exist before the External Service can reference them.
- Register the External Service
Setup, External Services. New External Service. Pick the Named Credential. Provide the OpenAPI spec by URL, paste, or file upload. Salesforce parses the spec and lists every operation. Pick which operations to expose as flow actions.
- Review the generated metadata
After save, Salesforce generates Apex wrapper classes named ExternalService_YourServiceName. Inspect them under Setup, Apex Classes. Do not edit; re-imports overwrite. The classes are deployable via change sets or DX.
- Use the actions in Flow
Flow Builder, add Action element. Filter to External Service. Pick the operation. Configure input parameters (path, query, body fields). Bind outputs to flow variables for downstream use.
- Handle errors
Add a Fault path on the Action element. The fault path receives a fault message variable with the response status and error body. Build a separate error-handling sub-flow that logs or escalates on integration failures.
Supports OpenAPI 2.0 (Swagger) and 3.0. Older Swagger 1.x specs need conversion before import. The spec source can be JSON or YAML.
Pick which operations from the spec to expose as flow actions. Limiting to relevant operations keeps the flow action picker clean and reduces generated metadata footprint.
Inherited from the Named Credential: OAuth (2.0 client credentials, JWT), API Key, Basic Auth, AWS Signature, Mutual TLS, custom. Switching auth requires editing the Named Credential, not the External Service.
Generated Apex types reflect the spec's response schemas. Strongly typed outputs let Flow bind fields directly without JSON parsing.
- Polymorphic response types (oneOf, anyOf) and certain auth flows (OAuth implicit, password grant) are not supported. Fall back to custom Apex for these cases.
- Generated classes are not editable; re-importing the spec replaces them. Custom modifications belong in a wrapper class, not the generated code.
- Multi-part file uploads and binary payloads are unsupported. APIs that require file upload need custom Apex callout code.
- The action picker in Flow shows every operation imported, even ones never used. Limit the import to relevant operations to keep the UI usable.
- Breaking spec changes cause re-import to fail compile. Treat the spec as a contract; major-version changes require coordinated migration of dependent flows.
Trust & references
Cross-checked against the following references.
- External Services OverviewSalesforce Help
- Register an External ServiceSalesforce Help
Straight from the source - Salesforce's reference material on External Services.
- External Services Schema ConsiderationsSalesforce Help
- Use External Services in a FlowSalesforce Help
Hands-on resources to go deeper on External Services.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What does External Services enable?
Q2. What format does External Services use to define APIs?
Q3. What's the value of External Services for admin-led teams?
Discussion
Loading discussion…