✦ Partner API
How to recover from a revoked MultiPost API token in a multi-tenant SaaS
Quick answer
When MultiPost returns 401, pause publishing only for that tenant and do not retry the same bearer token. Ask the customer to generate a replacement personal token, store it server-side, validate it with GET /api/v1/me, refresh GET /api/v1/accounts and resume only after the expected platform-and-handle targets are present.
How do you recover when a MultiPost API token returns 401 in a multi-tenant SaaS?
Stop publishing for that tenant, mark the MultiPost connection as needing attention and ask the customer to generate a replacement personal token. A 401 unauthorized response means the bearer token is missing, invalid or revoked; retrying the same secret will not repair it.
Keep every other tenant active. The token identifies one MultiPost user, so an authentication failure must not disable a shared worker or cause it to fall back to another customer's credential.
What is the fast way to relink the customer with MultiPost?
Ask the customer to create a new token in MultiPost settings, replace the tenant's server-side secret and validate it with GET /api/v1/me. Then refresh accounts through MultiPost accounts before re-enabling publishing.
The Partner API requires Pro or Agency. If the new token validates butcanPublish is false, direct the customer to plans and billing rather than treating the response as another token failure.
How should the replacement token be stored without crossing tenant boundaries?
Store one token per tenant in server-side secret storage and never expose it to browser code, logs or analytics events. MultiPost displays a newly generated token once and stores only its hash, so your product must save the replacement securely when the customer submits it.
The architecture guide for social publishing without provider OAuth storage explains why the personal MultiPost token remains inside the tenant boundary.
Which checks should pass before queued publishing resumes?
Confirm that /api/v1/me succeeds, the plan can publish and/api/v1/accounts returns the expected platform-and-handle targets. Remove stale saved selections rather than silently substituting the first account on a platform.
For an account-selection UI, follow the guide to build a picker with stable usernames and avatars. Resume with one controlled request before releasing a larger queue.
How does MultiPost make revoked-token recovery predictable?
MultiPost rejects revoked credentials immediately and scopes successful calls to the replacement token's owner. Your SaaS completes the runbook by pausing only that tenant, validating identity and accounts, and requiring an explicit relink before publishing resumes.
Frequently asked questions
What causes a MultiPost 401 response?
The bearer token is missing, invalid or revoked, so the request cannot be tied to a MultiPost user.
Will retrying the same revoked token work?
No. Revocation takes effect immediately and the customer must provide a newly generated token.
Where should the replacement token be stored?
Store it in server-side secret storage under the correct tenant and never expose it to browser code or logs.
What should be checked before publishing resumes?
Validate /api/v1/me, plan eligibility, remaining usage and the expected accounts from /api/v1/accounts.
✦ Start free
Pause one tenant, relink deliberately and resume with verified targets.
MultiPost keeps authentication user-scoped while your SaaS controls secure replacement and recovery.