PostEverywhere Zapier Guide
Connect Zapier to PostEverywhere to publish posts from any of 7,000+ apps. Includes the working raw-JSON setup, the array-as-string gotcha, and the exact action and field formats.
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.
What you need before building the Zap
- Get an API key: Sign in to PostEverywhere, open Developers, and click Create key. Copy it (you only see it once). Keys start with
pe_live_. - 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. - 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
| Field | Value |
|---|---|
| Method | POST |
| URL | https://app.posteverywhere.ai/api/v1/posts |
| Data Pass-Through? | false |
| Data | Leave empty (we use the JSON body below) |
| Unflatten | no |
| Headers | Content-Type: application/jsonAuthorization: Bearer pe_live_yourkeyhere |
| Wrap Request in Array | no |
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 behind most 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 invalid_datetime
"Invalid scheduled_for value. Must be a valid ISO 8601 datetime in UTC"
(a date in the past returns 400 past_schedule_time)
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 after your first Zap
- Create Post API reference: every field PostEverywhere accepts
- Errors: full list of error codes and what they mean
- Authentication: how API keys, scopes, and revocation work
- Rate Limits: per-minute and per-hour caps
If you get stuck, contact support@posteverywhere.ai with the request body and the full error response: those two are usually enough to spot the issue.
Related: the API quick start · the CLI, if you prefer a terminal · webhooks for real-time status · social media automation with PostEverywhere