API reference · Posts

Preview or atomically edit scheduled posts

PATCH /v1/posts/bulk

Select 1 to 200 exact post IDs. First send dryRun=true and inspect the per-post before/after diff. Apply with dryRun=false and the returned snapshot. A changed, missing, non-scheduled or imminent post rejects the entire edit. A UTC shift updates all scheduled times atomically in storage; timer re-arming is best-effort, with the due-post cron as a backstop. Cancellation is a separate endpoint.

Request

Authenticate with a bearer API key. Agents calling over MCP authorise with OAuth instead and never handle the key.

curl -X PATCH https://api.postlake.dev/v1/posts/bulk \
  -H "Authorization: Bearer $POSTLAKE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"ids":["post_abc","post_def"],"patch":{"text":"Revised campaign caption"},"dryRun":true}'

Body

FieldTypeRequiredWhat it is
idsarray of stringYes
patchobjectYes
patch.textstringNo
patch.textOverridesobjectNo
patch.accountsarray of stringNoExact final destination list for every selected post.
patch.addAccountsarray of stringNoAdd these connected account IDs to each post, preserving its existing destinations and avoiding duplicates. Mutually exclusive with accounts. Each final destination is validated. Preview and apply must use the same patch.
patch.shiftMinutesintegerNoShift each scheduled UTC instant by this many minutes; all resulting times must remain in the future.
patch.campaignstringNo
patch.assetMetadataobjectNo
dryRunbooleanYes
snapshotstringNoRequired for apply; copy from the preview response.

Response

Preview or full edit, with per-post before/after results and snapshot. (200).

FieldTypeRequiredWhat it is
dryRunbooleanYes
snapshotstringYes
matchedintegerYes
resultsarray of objectYes

Example

{
  "dryRun": false,
  "snapshot": "…",
  "matched": 0,
  "results": [
    {
      "id": "…",
      "before": "…",
      "after": "…"
    }
  ]
}

Limits

Write operations are limited per account, and rate-limit responses include Retry-After. Do not automatically retry a write unless this operation explicitly documents idempotency.

Calling this from an agent

Agents do not call REST. They call tools. Over the hosted MCP server this operation is list_posts, and the agent authorises with OAuth so your API key is never pasted into a chat or seen by the model. The reply comes back in the same normalised shape you see above, which is what lets an agent reason about it without a per-network branch.

You control what any one agent may do with it: which brands it may act for, which networks it may reach, how much it may do in a day, and whether it may spend credits you bought up front. See the MCP server.

Errors

Every failure uses one shape: a stable type, a granular code, the field at fault in param, and a plain-language fix. An agent can act on it without a person reading the message. See Errors and retries.

Check the result before retrying a write. Only operations that explicitly support idempotency can safely replay an Idempotency-Key.

Common questions

Can an AI agent do this without the REST API?

Yes. Over MCP the same job is the list_posts tool. The agent authorises with OAuth, so no API key is pasted into a chat or seen by the model, and the answer comes back in the same normalised shape.

Is it safe to retry this call?

Do not automatically repeat a write after a timeout unless that endpoint explicitly documents idempotency. First read the resulting state; a second request could repeat the action.

What happens when it fails?

You get one error shape: a stable type, a granular code you can branch on, the offending field in param, and a fix written so an agent can correct itself rather than stop. Full list on Errors and retries.

Related