n8n & Make.com

No-code automation platforms like n8n and Make.comdon’t speak MCP, but they don’t need to — PostFuze’s tools are a thin layer over a plain REST API. Use a generic HTTP Request node to call any endpoint, and a Webhook trigger to react when a post goes live. The base URL is https://api.postfuze.com/api/v1 and every request carries Authorization: Bearer sk_live_….

Calling the API from an HTTP node

The most common flow: publish a post when something upstream happens (a new row in a sheet, an RSS item, a form submission). Configure the HTTP Request node as POST to /posts with a JSON body.

The body is the same contract the Posts API documents — a containers array (or a flat content string) plus the target accounts:

{
  "content": "New on the blog: {{ $json.title }} → {{ $json.url }}",
  "accounts": ["a1b2c3d4-…", "b7c8d9e0-…"],
  "scheduled_at": "{{ $json.publishAt }}",
  "config": {
    "youtube": { "title": "{{ $json.title }}", "privacyStatus": "public" }
  }
}

The {{ }} expressions are n8n bindings pulling fields from the previous node; Make.com uses its own mapping pills in the same places. Pass an Idempotency-Key header (or an external_refin the body) so a retried run doesn’t double-post — PostFuze returns the original post on replay. See Idempotency.

Raw HTTP, for reference

Both platforms ultimately send this request. Useful for testing the call in a terminal before wiring up the node:

curl https://api.postfuze.com/api/v1/posts \
  -H "Authorization: Bearer sk_live_…" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: sheet-row-4821" \
  -d '{
    "content": "Automated from n8n 🚀",
    "accounts": ["a1b2c3d4-…"]
  }'

The other endpoints work the same way: GET /social-accounts to resolve account IDs, GET /posts to list, GET /posts/{id}/analytics for metrics, and the two-step media upload when attaching images or video.

Triggering on a webhook

To run a workflow when a post publishes, register a PostFuze webhookthat points at your automation’s inbound URL. In n8n, add a Webhook trigger node (or a Custom webhook module in Make) and copy its generated URL, then register it with PostFuze:

curl https://api.postfuze.com/api/v1/webhooks \
  -H "Authorization: Bearer sk_live_…" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://your-instance.app.n8n.cloud/webhook/postfuze",
    "events": ["post.published", "post.error", "account.token_expired"]
  }'

PostFuze then POSTs a signed JSON payload to that URL whenever a subscribed event fires. The body carries a top-level event, an ISO-8601 timestamp, and an event-specific data object:

{
  "event": "post.published",
  "timestamp": "2026-06-10T15:00:04.812Z",
  "data": {
    "postId": "p1a2b3c4-…",
    "orgId": "org_5c1…",
    "socialAccounts": [
      { "accountId": "a1b2c3d4-…", "network": "x", "username": "acme", "platformPostId": "1799012345678901234" }
    ]
  }
}

Map fields straight from the trigger output into the next node — e.g. post a Slack message with data.socialAccounts[0].network and its platformPostId, or branch on event to handle post.error differently. Each entry in socialAccounts[] carries platformPostId on success or an error on failure. Available events include post.published, post.error, account.token_expired, import.completed and import.failed. See Webhooks for every payload; they are generated directly from the delivery code, so the fields above are exact.

A complete loop

Put together, a typical content pipeline looks like:

1. Trigger — a new CMS entry, sheet row, or schedule fires the workflow.
2. HTTP → POST /posts — create the post with an Idempotency-Key; capture the returned id.
3. Webhook trigger — a second workflow listens for post.published and notifies your team (Slack, email) with the live URLs, or opens a ticket on post.error.

Next steps

• Posts API — the full request/response contract behind the HTTP node.
• Webhooks — event catalog, signing, and retry behavior.
• MCP setup — if your tool of choice does speak MCP, skip the HTTP plumbing entirely.