zhyper API documentation

One API for publishing to social platforms. Connect accounts, schedule content, receive events.

Start here

• Quickstart — from nothing to a working profile
• Authentication — API keys and panel sessions
• Test mode — build end to end without touching a real platform

Publishing

• Connecting accounts — OAuth, credentials and the redirect allowlist
• Posts — one post, many targets, and what each status means
• Media — uploading images, video and documents
• Queues — recurring schedules instead of timestamps
• Accounts — listing, health, moving and disconnecting
• Platform capabilities — what each platform accepts, read from the same source the validator uses

Advertising

• Ads — campaigns, ad sets and ads on Meta, and why what you read lags what you create

Messaging

• SMS — outbound sends, segments and what they cost, and the 10DLC registrations US traffic needs

CRM

• Contacts — people, tags, channels and custom field values

Reference

• Webhooks — receiving and verifying events
• Billing and balance — prepaid balance, X pricing, and what a drained balance does (and does not) stop
• Errors — the error envelope and what to branch on
• Rate limits and idempotency
• API reference — generated from the OpenAPI document

Zernio compatibility

Names beginning with Zernio, and a handful of duplicated fields, are not leakage. They are a deliberate, supported transition surface for integrations moving from Zernio, and they are declared here so that meeting one in the API reference is not a surprise. Measured 2026-08-31, this is where you will actually meet it:

• A second copy of the rows on four list endpoints. GET /v1/profiles answers with data and profiles; GET /v1/accounts with data and accounts (Accounts); GET /v1/posts with data and posts (Posts); GET /v1/api-keys with data and apiKeys. Account groups do the same with groups. The alias is a narrower projection with different field names — _id rather than id, and so on — so the two are not interchangeable. Build against data.
• GET /v1/posts extras: the sortBy aliases (scheduled-desc and friends, mutually exclusive with sort), the page parameter and the pagination object, and source, which defaults to zernio.
• A whole endpoint family: /v1/queue/slots (Queues), POST /v1/posts/bulk-upload, and GET /v1/connect/{platform}, which is a Zernio-shaped subset over this API's own OAuth state.
• Field aliases inside request bodies: a post target's platformSpecificData is an alias for options (send one, never both), and WhatsApp template components accept Zernio lowercase values next to Meta's canonical uppercase ones.
• Whole response shapes on Google Business. Most of the 51 Zernio* schemas in the document are Google Business media, reviews, attributes, place actions and services, which answer in the shape Zernio published rather than a zhyper-native one.
• A role name: billing_admin is Zernio's "Billing Manager" (Authentication).

Nothing in that list is deprecated today and nothing is scheduled for removal. Prefer the canonical field or endpoint when you have a choice, and expect the compatibility one to keep working when you do not.

About these docs

The TypeScript samples on these pages are not written here. Each one is extracted at build time from a real source file in apps/docs/examples/, and those files are type-checked against the SDK and executed against the API in test mode by the test suite. So a TypeScript sample cannot quietly drift from the behaviour it describes: if the API changes, the sample stops compiling or the test fails.

Two limits are worth stating, because a guarantee you cannot see the edge of is not a guarantee:

• Every TypeScript sample now runs, but two of them stop where a real platform round-trip would begin — completing an OAuth callback, and connecting with Bluesky credentials. For those two, what is proven is the request the sample sends and how the API answers it, not the handshake with the provider. The provider side is covered by other tests.
• The JSON response bodies and curl snippets are hand-written, because the build only embeds TypeScript. Two of them — the error envelope and the pagination envelope on Errors and Rate limits and idempotency — are checked field by field against real responses. The rest are kept in step by review, so when an exact field list matters, do not settle for the snippet. The API reference is generated and carries each operation's description, its parameters and the top-level fields of its JSON request body — but not response shapes and not nested fields. For those, read the OpenAPI document itself; it is public and Quickstart has the two URLs.

The API reference is generated from apps/api/openapi.json, the same document the SDK is generated from.