Skip to main content
A destination is a connected publishing target. A destination can receive a Post when its status is ready. Examples include a LinkedIn profile, a Facebook Page, or a Mastodon account. The destination list contains only targets that are linked to a current provider connection. It does not contain a static provider catalog. An empty data array means that the Workspace has no connected publishing targets. Supported providers are bluesky, x, youtube, facebook, instagram, threads, mastodon, linkedin, and tiktok. Use one of these values when you create a connection session. During the beta, some providers are not connectable yet in every deployment; a connection session for one of these fails with a destination_unavailable error.

​
Connection lifecycle

  1. Create a connection session for a provider.
  2. Open the returned authorization URL in a browser.
  3. Complete the provider authorization.
  4. Get the connection session until its status is completed, failed, or expired.
  5. List destinations and save the new destination ID.
OpenPMM keeps provider access tokens on the server. Your integration receives destination IDs, not provider credentials.

​
Destination status

Use the status as the publishing decision. You do not need to combine configuration, connection, and availability flags. The single-destination response includes publishing limits. capabilities.body_text_limit gives the maximum length and measurement unit. The field is present when OpenPMM knows the provider limit. X uses weighted_characters as its unit. Standard X accounts report 280. Eligible X Premium tiers report 25000. Run destinations refresh after an X subscription change. YouTube destinations also include allowed_privacy_statuses and minimum_upload_lead_minutes. Other channels omit these fields. YouTube supports public, unlisted, and private Posts.

​
Enabled and default destinations

A ready destination can receive a Post. A Workspace can have one default destination for each channel. Send destination_id when you must use a specific destination.
Store destination IDs in your configuration. Show the provider and account name to users. Send the destination ID to the API.

​
Destination queue

Each Destination has its own queue policy. The policy contains enabled weekdays and local-time posting windows. Each posting window gives one queue slot on each matching weekday. OpenPMM creates suggested windows for a new Destination. You can change, add, or delete these windows. OpenPMM uses the Workspace time zone for every future queue allocation. Queue policy changes do not move a queued Post. The Post keeps the exact time that OpenPMM selected when it entered the queue.