Connecting to systems that require OAuth
Use two API call actions to fetch an OAuth access token and then call the real API with it, using the client credentials grant.
Many systems require OAuth2 rather than a static API key, which means fetching an access token from the authorization server before calling the actual API with it.
A care flow models this as two API call actions in sequence.
What's needed first
- The credentials to authorize with the authorization server: a client ID and client secret.
- Working knowledge of API call actions and OAuth2.
Step 1: Fetch an access token
- Find the token endpoint. Check the system's documentation or ask their administrator for the URL that issues tokens.
- Make a POST request to it with an API call action, sending the client ID and client secret as the client credentials grant expects.
- Store the token in a data point using JSON path on the response.
Keep the client ID and secret in constants, not typed into the action.
Step 2: Use the access token
Add a second API call action for the real request, and pass the stored token in the Authorization
header as a variable.
The two actions must run in order, so put them in sequence in the same step or in consecutive steps.
Tokens expire
An access token has a lifetime. A care flow that fetches a token and then calls the API days later finds it expired.
Fetch the token immediately before the call that uses it, rather than once at the start of a long flow. Where a flow makes several calls over time, each needs its own fresh token.
Next steps
For a worked example against a real vendor, see setting up a GraphQL API call to Healthie.
The API call action
Call any REST or GraphQL API from inside a care flow to fetch or send data, and store the response in data points the flow can build logic on.
Store static values in constants
Define an API URL, key or other unchanging value once and reuse it across a care flow or an entire organization.