Skip to content

Scheduling, approvals & delivery

A post's life

A post belongs to one brand and fans out to one or more channels (targets). Each target has its own copy of the content (you can override the text per channel) and its own delivery state:

draft → in review → scheduled → publishing → published → verified

  • Without a schedule, a post is saved as a draft.
  • With a schedule (ISO 8601 with an offset, for example 2026-10-22T08:30:00+02:00), it's scheduled, unless it needs approval.
  • Times in the past are refused.
Create a scheduled post
curl -X POST "https://api.mynahcast.xyz/v1/posts" \
  -H "Authorization: Bearer $MYNAHCAST_KEY" \
  -H "Idempotency-Key: rye-thursday-01" \
  -H "Content-Type: application/json" \
  -d '{
    "brandId": "<brand-uuid>",
    "content": { "body": "Rye sourdough is back on Thursday." },
    "targets": [{ "channelId": "<channel-uuid>" }],
    "schedule": { "at": "2026-10-22T08:30:00+02:00" }
  }'

Approvals

When a post comes from an Agent key, it waits in review until a person approves it in the app. An approval is tied to the exact content it approved: edit the post afterwards and it goes back to review. You can also ask for approval on any post with submitForApproval: true.

Validate before you save

POST /v1/posts/validate (MCP: mynahcast_validate_post) checks a post against every target's limits (characters, media, threads) without saving it, and tells you whether it would need approval. Errors come back as application/problem+json with a fix hint an agent can act on.

Exactly once

  • Your requests: send an Idempotency-Key header on writes. Repeating the request with the same key returns the first response instead of creating a second post. Every write also accepts a dry run (?dry_run=true, or dry_run in MCP).
  • Our sends: each delivery to a platform has its own idempotency key. Mynahcast records the attempt before calling the platform. If a send's outcome is unknown (a crash or a timeout), it looks the post up on the platform before deciding to retry, and asks a human when it can't tell.

Verified delivery

After publishing, Mynahcast reads the post back from the platform by its id where the platform allows it, and marks it verified. If a post later disappears, it's flagged. A few channels (Slack webhooks, for example) return no post id; there Mynahcast trusts the platform's success response and says so on the channel's page.

Rate limits, expired tokens and platform errors are retried with backoff where that's safe. Content the platform rejects is never retried; you'll see why it failed.