Skip to main content

Using PostEverywhere with Zapier

Zapier doesn't have a native PostEverywhere integration yet, but you can connect any of Zapier's 7,000+ apps to PostEverywhere through the Webhooks by Zapier action. This guide covers the exact setup that works, plus three pitfalls that cause silent failures.

Quick context

PostEverywhere has a REST API. Zapier sends data to it via a webhook. The most common reason these Zaps fail is that Zapier's default form-style action serializes JSON arrays as strings, but our API requires real arrays. Use Custom Request (raw JSON), not POST (form-fields). Details below.

Before you start​

  1. Get an API key — Sign in to PostEverywhere, open Developers, and click Generate API Key. Copy it (you only see it once). Keys start with pe_live_.
  2. Find your account IDs — On the same Developers page, the Your account IDs card lists every connected social account with a copyable integer ID. You'll use these in account_ids.
  3. Connect at least one social account in PostEverywhere before testing — the API rejects requests for accounts you haven't connected.

Step 1: Add the Webhooks by Zapier action​

In your Zap, add an action and search for Webhooks by Zapier. Choose Custom Request — not POST. Custom Request lets you send a raw JSON body, which is what PostEverywhere expects.

The form-style POST action wraps every field as a separate URL-encoded form field and stringifies arrays — both will break the request.

Step 2: Configure the Custom Request​

FieldValue
MethodPOST
URLhttps://app.posteverywhere.ai/api/v1/posts
Data Pass-Through?false
DataLeave empty (we use the JSON body below)
Unflattenno
HeadersContent-Type: application/json
Authorization: Bearer pe_live_yourkeyhere
Wrap Request in Arrayno

Then paste this as the Data (JSON / Raw) body — replace the account IDs with your real ones from the dashboard:

{
  "content": "Hello from Zapier!",
  "account_ids": [6409, 6413],
  "scheduled_for": "2026-06-04T18:30:00Z"
}

When you map Zapier trigger fields into the body, keep account_ids as a real JSON array in your body — don't wrap the array in quotes. The array must contain integers, not strings.

Step 3: Test the Zap​

Click Test action. A successful response looks like this:

{
  "data": {
    "post_id": "post_abc123",
    "status": "scheduled",
    "scheduled_for": "2026-06-04T18:30:00Z",
    "account_ids": [6409, 6413]
  },
  "error": null,
  "meta": { "request_id": "a1b2c3d4", "timestamp": "2026-06-04T01:23:45Z" }
}

If you get a 400 error, see the troubleshooting section below — the message in the error body almost always tells you exactly what to fix.

Three pitfalls that account for ~80% of Zapier failures​

Pitfall 1: account_ids arrives as a string​

400 account_ids_required
"account_ids is required and must be a non-empty array."

Why: You used the POST action (form-fields) or your trigger app surfaced the IDs as a string like "[6409, 6413]". Our API rejects strings — account_ids must be a real JSON array.

Fix: Use the Custom Request action and put the array in the raw JSON body as [6409, 6413] — no surrounding quotes. If you're computing the array dynamically (e.g. from a spreadsheet column), use a Code by Zapier step to JSON.parse(input) the value before the webhook step.

Pitfall 2: scheduled_for is not ISO 8601 UTC​

400 invalid_timezone

or

400 validation_error
"scheduled_for must be ISO 8601"

Why: Zapier formats datetimes in lots of ways depending on the source. 2026-06-04 6:30 PM CST, 06/04/2026, or Jun 4 will all fail. The API needs strict ISO 8601 in UTC.

Fix: Use Zapier's Formatter → Date / Time → Format step to convert your datetime to YYYY-MM-DDTHH:mm:ss[Z]. Example: 2026-06-04T18:30:00Z. To schedule for a specific local time, convert it to UTC first.

Pitfall 3: Your Filter step blocks the run but the webhook still fires​

If you see a 400 with a body that contains _zap_data_filter_summary, the request was sent without your content fields — the filter blocked the run but the webhook step ran on the filter metadata, not your actual post data.

Fix: Add the Filter step before the webhook step in your Zap (not after) so a failed filter prevents the webhook entirely.

Stale account IDs after a reconnect​

If you reconnect a social account in PostEverywhere (e.g. when its token expires), it sometimes gets a new integer ID — even if the username didn't change.

Symptom: Your Zap starts returning 400 invalid_accounts: No valid social accounts found for the given account_ids.

Fix: Re-check the Your account IDs card on the Developers page in PostEverywhere and update the array in your Zapier action. (Or add a step that calls GET /v1/accounts first and uses the IDs from that response — slower but auto-heals.)

Where to go next​

If you get stuck, contact [email protected] with the request body and the full error response — those two are usually enough to spot the issue.