Skip to main content

​
Queue a Post

Set when to queue to use the next available Destination queue slot. Do not send time_zone for a queue request. OpenPMM uses the Workspace time zone.
OpenPMM selects and stores an exact time before it returns the Post. Each Destination can get a different time in the same request. The Post response includes scheduled_at, time_zone, schedule_mode, queue_local_date, and queue_window_id.

​
Configure a Destination queue

Each posting window gives one queue slot on each selected weekday. A Destination can contain 10 posting windows maximum. The start time is inclusive. The end time is exclusive. Use PATCH /workspaces/{workspace_id}/destinations/{destination_id} to change a queue policy. Send the Destination ETag in If-Match.
OpenPMM assigns an ID to each new window. Include this ID when you keep or change that window. Remove a window from the array to delete it. An exact schedule or immediate Post counts when OpenPMM finds an available day. You can still create another exact schedule or immediate Post for a full day. This manual Post does not move an existing queued Post.

​
Move queued Posts

Use POST /workspaces/{workspace_id}/posts/move-in-queue to move queued Posts to one local date. Send the current scheduled_at value for each Post. OpenPMM moves all requested Posts or does not move any Post.
The target date must have a queue slot for every requested Post. OpenPMM returns 412 if a Post schedule changed before the request. Use the same Idempotency-Key when you retry the same move.

​
Schedule an exact time

Set when to an ISO 8601 timestamp to schedule a post. The timestamp must include a UTC offset. Use time_zone to record the local time zone.
A Post can return 202 Accepted in the preparing state. The scheduled publication time and any provider upload lead time stay unchanged. Read the Post until it advances or needs action.

​
Update a scheduled post

Get the post and save the ETag response header. Send this ETag in If-Match when you cancel or reschedule the post. OpenPMM returns 412 if the post changed after it created the ETag. Send confirmed: true in the request body. Also send a new Idempotency-Key for the action.

​
Retry safely

  • Use the same Idempotency-Key when you retry the same request.
  • Get the post after a network timeout.
  • Do not assume that a provider error means that nothing was published.
  • Retry only when retry_safety is safe.
  • Verify the provider when retry_safety is may_duplicate.
  • Send acknowledge_duplicate_risk: true only after this verification.
  • For provider_publishing_limit, wait and use confirmed manual Retry. OpenPMM does not retry this error automatically.
  • A confirmed Retry can return 429 when Account publishing admission is temporarily limited. Read reason and wait until retry_at when it is present. The failed Post remains unchanged.
  • Review a Post with the needs-attention state. Use its available_actions.
A confirmed video-preparation retry can also return 202 Accepted. Continue with other work and read the same Post until it leaves preparing. See Idempotency for retry rules. See Errors for error handling.