Authentication

Every request to the OmniPost API is authenticated with a bearer API key scoped to a single workspace.

Header format

Pass your key in the Authorization header using the Bearer scheme on every request.

Authorization: Bearer op_live_TjK83nQpXz1LwYh9m5vRtC7bNsFdAeUq

Requests without a valid Authorization header return 401 missing_api_key. Requests with a malformed or revoked key return 401 invalid_api_key. See Errors for the full list of error codes.

Live vs. sandbox keys

Keys are always prefixed with their mode, so the mode of a request is unambiguous from the key alone — you never need to pass a separate flag to tell OmniPost whether to hit real platforms.

The sandbox field on POST /v1/uploadis optional and inferred from the key prefix — you only need it if you're calling the API from a shared client and want to be explicit. If you pass "sandbox": false with a sandbox key, the request is rejected with 403 sandbox_key_not_allowed.

Rotation and revocation

Generate, rename, and revoke keys from Settings → API Keys in your workspace dashboard. The number of active keys per workspace is capped by your plan — see Rate Limits.

• Key values are shown in full only once, at creation time. OmniPost stores a salted hash, not the raw key.
• Revoking a key takes effect immediately — in-flight requests already authenticated are allowed to finish, but new requests with the revoked key get 401 invalid_api_key.
• Revoking a key never affects connected social accounts or existing posts — it only removes that credential's ability to make new requests.
• There is no automatic expiry. Rotate keys on a schedule that matches your own security policy.

Rotating a key without downtime

Create the replacement key first, deploy it, then revoke the old one — this avoids a gap where no valid key is configured.

# 1. Create a new key from the dashboard, deploy OMNIPOST_API_KEY=<new key>
# 2. Confirm the new key works
curl https://api.omnipost.dev/v1/accounts \
  -H "Authorization: Bearer $NEW_OMNIPOST_API_KEY"

# 3. Revoke the old key from Settings → API Keys once traffic has shifted

Security best practices

• Never expose keys in client-side code. Both op_live_ and op_sandbox_ keys can create real posts and manage connected accounts — treat them like a database credential, not a publishable frontend token. Route requests through your own backend.
• Use environment variables, not source control, to store keys. Add .env to .gitignore.
• Scope keys per environment.Use a sandbox key in local development and CI, and a separate live key per production deployment, so a leaked staging credential can't touch real accounts.
• Rotate immediately on suspected leak — committed to a public repo, logged in plaintext, or shared over an insecure channel. Revoking is instantaneous and does not affect connected accounts.
• Verify webhook signatures rather than trusting the payload — see Webhooks.