From make-skills
Builds or reuses a reusable Make API-call shell for retrieving data from email, CRM, tickets, and similar SaaS systems. Handles connection discovery, credential requests, and scenario patching.
How this skill is triggered — by the user, by Claude, or both
Slash command
/make-skills:make-api-shell-connection-workflowThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Use this skill for one specific workflow family:
Use this skill for one specific workflow family:
This skill is primarily about provisioning and shell construction. Treat business retrieval as a second phase that starts only after the connection is ready and the shell has been validated against current workspace metadata.
The generic shell described here is an API transport wrapper, not business logic. It should behave like a reusable API endpoint for any SaaS app that Make can front, including email, CRM, ticketing, support, marketing, or task systems.
Known Make module id: the Make Code module is "module": "code:ExecuteCode".
Read the file that matches the current task:
| Task | Reference |
|---|---|
| Discover the app, module, and connection type layers | Discovery and Shells |
| Create, inspect, or resolve a credential request | Connection Requests |
| Choose and execute the post-connection retrieval path | Retrieval Execution |
| Repair provider authorization or scope failures after a shell run | Retrieval Execution |
| Sanitize examples and prepare a public shareable version | Sanitization and Sharing |
| Start from a generic blueprint template | Example shell blueprint |
| Provider has no Make app: generic HTTP shell with noAuth / API key / Basic auth / OAuth 2.0 | HTTP Fallback Shells |
When a fresh agent gets a request such as "get my unread emails", "pull my open CRM leads", or "fetch my Jira tickets", the default operating sequence is:
GET /api/v2/imt/apps ignores search, limit, and scoredSearch and always returns the full ~4k-app catalog, so never rely on server-side search. Match locally instead: search a curated top-apps catalog first (in helper environments, search_apps(query=...) does this); only when nothing matches there, fetch the full catalog once and filter it client-side, case-insensitively, over name and label. All query words score; without an exact phrase match the first query word must hit for a candidate to count, and the first ranked result is the recommended app.
communityApp-*) are excluded from matching; custom apps (catalog prefix app#*) are allowed. Authoritative check: GET /api/v2/imt/apps-meta lists all verified and custom apps available to the organization (custom-app names appear there without the app# prefix). Builtin utility pseudo-apps (builtin, util, gateway, regexp) are not SaaS providers and must never surface as search results. If the provider only exists as a community app, treat it as "no app" and build a generic HTTP fallback shell instead — see HTTP Fallback Shells.GET /api/v2/imt/apps/{appName}/{version} and record the exact API-call module slug and both connection type layers.GET /api/v2/connections/{connectionId} plus POST /api/v2/connections/{connectionId}/test.http:MakeRequest instead of giving up — see HTTP Fallback Shells.The agent should not jump straight from "user wants SaaS data" to "create a new connection" or "call a direct SDK" without walking this sequence.
Before provisioning or retrieval, explicitly resolve these inputs:
If one of those items is missing and cannot be discovered safely, stop and ask only for that exact missing item.
https://us1.make.com and keep placeholders generic. Do not mention we.make.com in public examples unless the current user explicitly provides or requests that zone. Valid zones can be eu1, eu2, us1, us2, or we, and if the user provides a custom zone or BASE_URL, accept it.scenario-service:ReturnData with ExpectDataAny, the final mapper must return the app module response body as data: {{MIDDLE_API_MODULE_ID.body}}.3, so the example mapper is data: {{3.body}}. If the real blueprint uses different module ids, use the real middle module id instead. For example, a Make UI export may use StartSubscenario 2, API-call module 5, and ReturnData 4, so the correct mapper is data: {{5.body}}.{{MIDDLE_API_MODULE_ID}} or {{MIDDLE_API_MODULE_ID.data}} just because the full bundle looks tempting. The shell is meant to return the API response body, not the entire Make module bundle.body contains the intended payload or error object — not to redefine the generic shell contract.GET /api/v2/users/me and GET /api/v2/imt/apps/... can succeed on multiple zones, while GET /api/v2/connections?teamId=... or scenario endpoints on the wrong zone can fail with 403 Permission denied./api/v2/connections endpoint, filter with type=... or type[]=.... Do not assume query parameters such as accountName=... are honored just because an MCP tool uses accountName terminology.actions/create, actions/create-by-credentials) work on a wide range of plans; only requesting credentials from a different person (requests/v2) is the Enterprise/Partner feature gated by license.credentialRequests (see Connection Requests, "Choose the request path by recipient first"). When no request path works, guide the user through creating the connection in the scenario editor instead. In all flows state the exact credential paste format (Bearer prefix or raw key) — never assume the user knows it.PUT, PATCH, or DELETE, warn explicitly before execution. Treat those methods as mutating live SaaS operations, not passive retrieval.StartSubscenario.metadata.interface is enough for scenario runs. After creating or updating an on-demand shell, explicitly set the scenario-level interface with /api/v2/scenarios/{scenarioId}/interface and verify it before the first run./api/v2/scenarios/{scenarioId}/run as the standard execution path for this shell family. Pass the business payload under data with keys that match the scenario interface exactly, and prefer responsive: true for validation runs.qs. Use qs for provider API query parameters such as Gmail search options, Drive fields, Drive q, Graph $select, pagination, or supportsAllDrives. If a caller provides a query string in path, normalize it into qs before running the shell.subflows[0].flow, while scenario create/update payloads require a top-level flow. Do not send a raw UI export to create/update without normalization.POST /api/v2/connections/{connectionId}/test. A response with verified: true is the liveness proof. A stale Credential Request status does not override a verified connection. Liveness is not proof that the provider will authorize every path, method, or scope; provider authorization is proven only by a successful shell run for the intended operation. On provider auth or scope errors, use the Authorization Repair Playbook.requestId; inspect the request, then list and verify connections. Do not create a new Credential Request while an active request for the same app/account is still being resolved.expire timestamp as valid. Treat only a past expiry, revoked connection, failed verification, or provider auth error as invalid.The shell pattern is generic, but each actual shell is bound to one discovered Make app module.
Do not treat “Google” or “Microsoft” as a single interchangeable connection family. In Make, app families often split by product surface.
Common examples:
| Business surface | Example API-call module | Scenario/module connection parameter type | Common connection listing or request type |
|---|---|---|---|
| Gmail | google-email:makeAnApiCall | account:google-email | google-email or workspace-specific variants such as google-restricted |
| Google Calendar / Sheets / Drive style apps | app-specific Google module discovered from metadata | commonly account:google | commonly google |
| Outlook / Microsoft mail | microsoft-email:makeApiCall | account:azure | azure |
Rules that follow from this:
When in doubt, inspect the exact app metadata and existing connection detail instead of inferring compatibility from the vendor name.
The reusable shell has exactly three modules:
scenario-service:StartSubscenarioscenario-service:ReturnDataExpose these shell inputs through StartSubscenario:
pathmethodheaderqsbodyUse the discovered middle module as the only app-specific part of the shell.
This shell is a generic API endpoint wrapper.
It receives:
pathmethodheaderqsbodyIt forwards those values into the app-specific Make API-call module.
Default retrieval should use GET. Treat PUT, PATCH, and DELETE as write/destructive methods and require explicit user confirmation before running them.
It returns exactly one thing:
Therefore the shell contract is:
{
"data": "{{MIDDLE_API_MODULE_ID.body}}"
}
In this skill's generic example blueprint, MIDDLE_API_MODULE_ID is 3, so the example value is {{3.body}}. In a real Make export, always inspect the module ids and use the actual API-call module id.
That contract is generic across SaaS providers. It applies whether the middle module fronts Gmail, Outlook, HubSpot, Jira, or another provider-specific Make API-call module.
The shell should not try to return:
{{3}}{{3.data}}The shell is transport only. Business interpretation happens later.
Complete these steps first:
POST /api/v2/connections/{connectionId}/testDeliverable at the end of Phase A:
Only after Phase A succeeds:
ReturnData fixed as the generic shell contract and update only downstream normalization if neededDo not treat a successful credential request as proof that the retrieval stage is already solved.
Important:
data: {{MIDDLE_API_MODULE_ID.body}} where MIDDLE_API_MODULE_ID is the actual app API-call module id in the blueprintFor on-demand shells, treat interface provisioning as a separate deployment step:
/api/v2/scenarios/{scenarioId}/interface/api/v2/scenarios/{scenarioId}/runUse a run payload shaped like:
{
"data": {
"path": "...",
"method": "GET",
"header": [],
"qs": [],
"body": null
},
"responsive": true
}
The key names under data must match the scenario interface exactly. If the interface was never explicitly set, run can reject the call even when the StartSubscenario module itself contains interface metadata.
Keep the generic shell contract stable, but do not assume every provider module tolerates an empty or null body the same way.
Observed-safe pattern:
bodybody mapper entirely when the provider module serializes empty payloads badly on GET or DELETEIf a provider-specific Make API-call module fails only when body is present-but-empty, prefer one of these patterns:
body mapperbody mapperDo not change ReturnData for this. This is a Module 2 request-shape compatibility issue, not a shell-output-contract issue.
When using this skill:
PUT, PATCH, or DELETE, stop and warn before executionReturnData looks wrong, stop calling the flow complete and report the exact failing phasemake-scenario-building for broader scenario architecture beyond this shell patternmake-module-configuring for detailed module configuration, mapping, webhooks, keys, and data storesmake-mcp-reference for Make MCP connection methods, scopes, and timeout behaviornpx claudepluginhub integromat/make-skills --plugin make-skillsGuides designing Make scenarios: choosing modules, composing flows, setting routing/branching/filtering/iterations/aggregations, building blueprints, deploying, error handling, scheduling.
Guides when to use Zapier vs Make, how to build reliable no-code automations, and when to graduate to code. Covers triggers, actions, and platform-specific patterns.
Automates Make (Integromat) tasks via Composio's Rube MCP: retrieves operations data, lists languages and timezones for scenarios. Useful for managing workflows and enum lookups.