Migrating from Ayrshare: a practical guide

Ayrshare authenticates requests with an Authorization: Bearer header carrying an API key, and PostGate works the same way — every request needs a PostGate key in that header. Both APIs center on a single endpoint that accepts a post body and a set of target destinations rather than one endpoint per platform, and both use a per-customer profile concept to scope which connected accounts a request can reach: Ayrshare's Business/Enterprise plans use a Profile-Key header alongside the API key to operate on a specific user profile; PostGate uses profile groups as the tenant boundary, with group-bound keys that are permanently scoped to one group.

If your integration already thinks in terms of "one API key, one bearer header, per-customer profile scoping, one post call fanned out across connected accounts," the shape of your client code does not need to change — the base URL, credential, and a handful of field names do.

A few PostGate specifics are worth knowing before you port request bodies over. Every create-post request should carry a stable Idempotency-Key, which makes retries of the same logical request safe for 72 hours — useful if your current client retries on timeout without that protection. Errors come back in a single structured envelope rather than varying by endpoint, which simplifies centralized error handling. API keys carry an explicit scope — read, publish, or full — so you can issue a key to a background worker that can only publish, not manage connections or billing.

PostGate's pg_test_ keys run the entire lifecycle — validation, async jobs, target resolution, delivery logs, webhooks — against a sandbox adapter that never calls a real provider, which is a clean way to build and run CI against the integration before any of your migrated customers are cut over.

Posting: both APIs accept one request with post content and a list of target accounts, and fan delivery out asynchronously. Accounts: Ayrshare's user profiles become PostGate profile groups, each holding its own connected social profiles. Media: both accept direct URLs; PostGate additionally supports pre-uploading large or reused assets via POST /api/media and referencing the returned ID on the post, with resumable multipart upload for big files. Pagination: PostGate uses standard page/per_page query parameters on list endpoints.

Whatever your current client does with a post's response, carry the same discipline over: treat a create-post call as acceptance, not confirmation. Consume the post.published, post.partial, and post.failed webhooks, or poll the returned post ID, and read the targets array as the source of truth per destination — status, attempt count, error, platform ID, and permalink. A partial result is a normal terminal state, not a bug: it means at least one destination published and at least one failed, and you should preserve the successful permalinks while retrying or surfacing only the failed ones.

Start in sandbox. Point a non-production build at PostGate with a pg_test_ key, port your request bodies, and confirm the full lifecycle — draft, scheduled, queued, and immediate posts, plus webhook delivery — behaves the way your client expects before any real customer traffic touches it.

Reconnect accounts through PostGate's hosted connection flow rather than trying to transplant existing OAuth tokens — each platform's authorization has to be re-granted through the new app registration regardless of which API sits behind it. Run a parallel period next: for a subset of customers, publish through both Ayrshare and PostGate simultaneously (or immediately in sequence) and diff the resulting permalinks and delivery status before trusting PostGate as the sole path. Cut over by customer group or profile group rather than all at once, watching delivery logs and webhook payloads for that cohort before expanding to the next. Only decommission the old integration once every cohort has run a full billing or posting cycle cleanly on the new path.

Inventory every platform-specific option your current requests set — board IDs for Pinterest, visibility flags for LinkedIn, per-target body overrides — and confirm where each lives under PostGate's post.options.<platform> object. Decide your idempotency-key strategy up front so retries during the parallel-run period cannot double-publish. And budget real time for platform-side reconnection, since that step depends on each customer taking action, not on anything your migration code controls.