Use Call API actions in workflows
Built-in workflow actions cover the most common operations, but sometimes you need to hit a specific endpoint or pass custom parameters that aren’t available as a ready-made action. Call API lets you make direct API calls to your connected integrations from a code script inside a workflow — no tokens, no credential references, no manual auth headers.
If the app you need to call isn’t connected through the integrations page, or you need to reach a system that isn’t available there, use the Make an HTTP request action with a saved credential instead.
How Call API works
Call API is available inside the Execute Code action. Once an app is connected from the integrations page (Settings > App store), your code scripts get access to a typed SDK method for that app:
The method name follows the app: API.datadog.datadogCallApi, API.azure_ad.azureAddUserToGroup, and so on. Type Workflow. or API. in the code editor and press Cmd+I (or Ctrl+I) to see the available functions and autocomplete them, or click Insert function. You can also use the Workflow.* namespace — Workflow.datadogCallApi(...) resolves to the same function.
[!NOTE] Call API is used from code scripts only — it does not appear as a separate action in the workflow builder’s action picker. To use it, add an Execute Code action to your workflow and call the SDK method from your script.
For a broader overview of how Call API fits alongside HTTP requests and the credential store, see the Calling external systems guide.
Parameters
Each integration accepts both endpoint and url. Use endpoint to pass just the path (e.g. /api/v1/users) — Atomicwork fills in the base URL from the connection. Use url when you need to specify the full address (e.g. https://atomicwork.okta.com/api/v1/users). We’d recommend endpoint where possible — it avoids hard-coding the base URL, so the call stays correct if your connection’s hostname changes.
Both endpoint and url go through destination safety validation. The difference is only in how the target address is built — not whether it’s checked.
What Atomicwork handles for you
-
Authentication. The connection’s credentials are resolved server-side and applied to the outgoing request. Your script never sees a token, and an auth header you set yourself cannot override the one Atomicwork injects.
-
Token refresh. For OAuth-based connections, expired tokens are refreshed automatically before the call goes out. You don’t need to handle token lifecycle in your code.
-
Destination safety. Calls are restricted to the hosts that belong to the connected app. For apps with a per-tenant address — Okta, Workday, ServiceNow — calls are further restricted to your own instance. A request to any other host is rejected with a
403.
Example: Mute a Datadog monitor during maintenance
Here’s a script that mutes a specific monitor and then confirms the mute was applied:
Supported apps
Call API is enabled per app, not universally. Most major integrations have it — including Okta, Jira, Slack, Microsoft Graph, GitHub, Workday, ServiceNow, Cloudflare, Datadog, Rippling, Google Workspace, Azure AD, Notion, Linear, and Grafana — but the list grows as new integrations are added.
If the app you need isn’t on the integrations page, or doesn’t have a Call API method, use the Make an HTTP request action with a saved credential from the credential store instead.
When to use Call API vs Make an HTTP request
Troubleshoot common issues
Learn more
-
Code actions — setting up Execute Code actions, testing, and using AI Assist
-
HTTP requests — calling systems that aren’t connected through the integrations page
-
Managing credentials — the credential store and public API tokens
-
Calling external systems — the complete guide to outbound integrations
