Make.com API (Make COM API): Complete REST guide for automations, scenarios, webhooks & data stores

The Make.com API (often searched as “Make COM API” or “Make.com API”) is Make’s official REST API. It’s designed so you can control and integrate your Make workspace outside the UI: manage organizations and teams, create/update/run scenarios, inspect logs, manage connections to third-party services, handle webhooks, and work with data stores.

Make organizes the API into resource-oriented URLs (classic REST style) with a dedicated API reference. If you’re building an internal admin dashboard, a SaaS product that provisions automations for customers, or a CI/CD-style deployment process for scenarios, the Make API is the interface you’ll use.

The fastest way to confirm your setup is correct is: (1) create an API token in your Make profile, (2) call a simple GET endpoint (like listing organizations), (3) confirm you receive JSON results, and (4) store the token securely (never in frontend code).

# 1) Set your Make API token as an environment variable
export MAKE_TOKEN="YOUR_MAKE_API_TOKEN"

# 2) Call the Make API (example: list organizations)
curl --request GET \
  --url "https://api.make.com/v2/organizations" \
  --header "Authorization: Token ${MAKE_TOKEN}" \
  --header "Accept: application/json"

import fetch from "node-fetch";

const token = process.env.MAKE_TOKEN;
const res = await fetch("https://api.make.com/v2/organizations", {
  headers: { "Authorization": `Token ${token}`, "Accept": "application/json" }
});

if (!res.ok) throw new Error(`Make API error ${res.status}: ${await res.text()}`);
console.log(await res.json());

import os, requests

token = os.environ["MAKE_TOKEN"]
res = requests.get(
  "https://api.make.com/v2/organizations",
  headers={"Authorization": f"Token {token}", "Accept": "application/json"},
  timeout=60
)

res.raise_for_status()
print(res.json())

Make uses API tokens (often called “API keys” in the UI) that you create inside your Make profile. When you create a token, you choose the scopes (permissions) it can access, and you should store the token value securely because it’s shown in full only once.

In most setups, you send the token in the Authorization header (for example Authorization: Token YOUR_TOKEN), and the API returns JSON. If you get 401 or 403, verify the token is valid and has the required scopes.

Make accounts can run in different regions (for example, EU or US infrastructure). In the Make UI and some docs you may see region hostnames like https://eu1.make.com. For the public API, Make provides an API host and versioned paths (commonly /v2).

Best practice: store your “environment URL” / region configuration in your app settings and don’t hardcode it everywhere. If Make changes region routing or you add multiple regions, you’ll only update it in one place.

Make’s API is organized around workspace resources. Here are the most common ones you’ll use in real systems. (This is a “map” so you can design your integration cleanly.)

In Make, an organization is the main container that contains teams, scenarios, and users. Your API integration typically starts by determining which organization(s) the token can access, then selecting a target org for operations.

Once you have the org context, you can manage teams (grouping users and assets) and users (inviting, setting roles, removing). This is especially valuable if you embed Make into a product that provisions automations per customer.

Scenarios are Make’s automation workflows—graphs of modules that pull data from one system, transform it, and push it elsewhere. The Make API supports scenario lifecycle operations such as: listing scenarios, getting a scenario, creating/updating, running a scenario, toggling scheduling, and inspecting logs and executions.

Scenario operations are the core of “Make-as-a-platform” integrations. Common patterns include: deploying new scenarios from templates, updating scenario variables per customer, running a scenario on-demand from your UI, and collecting run results for reporting.

In Make, a connection is the saved authentication/config needed for Make modules to talk to external services (Google, Slack, CRMs, payment processors, etc.). Most apps in Make require a connection. The API provides endpoints to create and manage connections.

If your product provisions workflows for customers, connection management is critical. You may: create a connection when a user authorizes (OAuth), rotate tokens when they expire, or delete connections when customers churn.

Make supports webhooks as a way to trigger scenarios immediately when data arrives (instant triggers), or to collect webhook requests into a queue and process them on a schedule (scheduled processing). Webhooks are commonly used when an external system can “push” events to Make (for example, “new order created” or “new lead captured”).

Key webhook concepts in Make:

• Instant webhooks: run the scenario immediately on each incoming request (can be parallel or sequential depending on scenario settings).
• Scheduled webhooks: store incoming requests in a queue and process them periodically based on schedule settings.
• Webhook response: Make can return a response to the webhook sender; you can customize it with modules.
• Queue limits: webhook queue size depends on your plan/allowances; when full, Make rejects new webhook data.
• Rate limits: Make can rate-limit webhook intake; excessive requests may receive 429.

When a scenario uses scheduled webhook processing, incoming requests are placed into a webhook processing queue. Make provides API endpoints under “Hooks > Incomings” to inspect and update the webhook processing queue (for example, viewing queued items, deleting problematic items, or managing queue behavior depending on the endpoint features).

Operationally, this is useful when you need observability and recovery: if a scenario fails repeatedly on a certain payload, you can inspect the queue, isolate the bad item, and allow processing to continue without blocking everything.

Data stores are Make’s built-in storage feature used to store data from scenarios or transfer data between scenario runs. You can manage data stores via API endpoints: create stores, update them, and manage records inside a store.

Real-world uses:

• Idempotency & dedupe: store processed event IDs to avoid double-processing in webhook-driven workflows.
• Stateful workflows: store “last processed timestamp” or pagination cursors for polling triggers.
• Cross-scenario handoff: Scenario A writes to a data store; Scenario B reads later (like a lightweight queue/state store).
• Feature flags: store a small configuration map (enabled/disabled) used by scenarios to change behavior.

Make’s API includes a Keys resource that lets you manage and retrieve metadata for authentication keys in a custom keychain. These keys can be used to manage authentication in Make’s HTTP or Encryptor apps similarly to other connections.

When you’re building enterprise-grade automation, separating “connection configuration” from “secret storage” can help: your app can update key references without repeatedly distributing secrets across many scenarios.

Many Make API list endpoints (organizations, scenarios, connections, webhooks, logs) return paginated results. Even if your first integration “works” on small accounts, pagination becomes required once organizations grow.

Tip: If you build a dashboard, cache list responses for a short time (30–120 seconds) so frequent refreshes don’t burn your rate limit.

Make enforces API rate limits based on your organization plan. The official “Rate limiting” guide lists the default limits as: Core: 60/min, Pro: 120/min, Teams: 240/min, Enterprise: 1000/min. If you exceed the limit, you receive 429 with a message like “Requests limit for organization exceeded, please try again later.”

Treat Make’s API like any external dependency: errors will happen (expired tokens, missing permissions, deleted scenario IDs, rate limits, temporary outages). Your integration should classify errors and respond consistently.

If you’re building a serious Make integration (internal tool or SaaS feature), treat it as a production system: a backend service owns tokens, your app enforces who can run which scenario, and you log actions for audit.

A solid architecture looks like:

• Frontend triggers “jobs” (not direct Make calls).
• Backend API validates input, checks permissions, creates a job record.
• Worker processes jobs, calls Make API with token, applies retries/backoff, stores results.
• Observability dashboards show success/failure, queue depth, and 429/5xx spikes.