Build around a clear publishing workflow.

Keep access specific

An integration should request access to the workspaces and actions it needs. Reading a calendar, editing a draft, and publishing a post are different permissions.

Keep API credentials in your backend or automation platform. Social platform tokens belong inside Faryen's protected publishing service and should never be passed to your application.

Model the post and its destinations

A post holds the shared idea. Its destinations hold account choices, format, and follow-up comments. Model those separately so the same idea can become a carousel for one account and a regular post for another.

A comment delay is measured from confirmed publication of its destination. Plan comments only for combinations of platform and format that support them.

Treat publication as a process

Creating or scheduling a post does not mean it has already been published. Keep the post identifier and inspect its per-destination outcomes.

An uncertain provider response needs verification. Resubmitting the same content can create duplicates, so check the existing result before creating a replacement. Build retries around a stable request identifier.

Read metrics with their context

Keep the account, reporting period, and metric definition with each value. Platforms provide different analytics, and an unavailable metric is different from zero.

For a custom dashboard, keep publishing status separate from content performance. A confirmed post and its latest analytics answer different questions.

Endpoint reference and examples

The versioned API reference will include authentication, request and response schemas, media uploads, pagination, rate limits, errors, and webhook events. Runnable examples will be published alongside the implemented endpoints.