Social media API approval: OAuth, review, and publishing

A practical guide to separating account access, provider review, media processing, and the result your user actually receives.

Google OAuth verification and Meta app review were in different states on 27 September 2026. Neither screen establishes YouTube API audit approval or a successful public post. Screenshots by Anton Rost.

A connected account is the beginning of a publishing job, not evidence that the job can be completed. The callback may succeed while the application still lacks provider approval, the selected destination lacks a capability, or an uploaded video remains private.

While building Sendezeit, I realised that “ready” could mean three different things: an account was connected, the app had provider approval, or a post was actually live. I needed to stop treating those as the same milestone. A more useful approach was to follow the work from authorization to the result the user actually receives, checking what each stage proves before moving to the next.

The phrase social media approval workflow sometimes describes teammates signing off on content. Here it means the provider-side authorization and review needed to deliver that content; it is not a description of a team-approval feature in Sendezeit.

The checks below follow the publishing job in order. They start with the connection, then move through the destination, submission, unfinished provider work, and the evidence needed to describe a result honestly.

1. A reliable publishing path starts with the connection

Before checking a post, make the authorization path unambiguous. The public application URL is where the user works, the OAuth redirect URI receives the browser after consent, and a webhook endpoint receives later provider events without that browser session. These addresses serve different purposes.

Register the production redirect accurately rather than assuming that a development callback, alternate hostname, or different path will be accepted. The OAuth security best-current-practice document calls for exact redirect matching, with a specific exception for localhost ports in native applications. It also addresses PKCE and protection against authorization-code attacks. RFC 9700.

Tie the authorization flow to an expiring server-side record containing the provider, initiating user, and allowed return path. Validate the callback against that record and prevent reuse. Apply the provider's documented PKCE requirements rather than copying one adapter's parameters into every other adapter.

For example, X's OAuth 2.0 authorization-code flow uses PKCE, and its offline.access scope enables refresh-token access. A connection that works now does not by itself establish that the application can keep working after the access token expires. X authorization documentation.

Keep token exchange and confidential client credentials on the server, protect stored tokens, and keep them out of logs. Test expiry, revocation, and disconnection alongside the successful path. Once access is established, the next check is where that access can actually be used.

2. Access must lead to a specific destination and capability

The person granting consent may manage several Pages or channels. Discover the destinations permitted by the grant and make the selected destination visible before submission. Otherwise, a successful connection can hide uncertainty about where the post will go.

Record the stable provider identifier, relevant granted permissions, and capability restrictions for that destination. Test the account type and login route you intend to support: one working professional account is not evidence of support for every account type.

A connection screen should therefore answer both “Which account is this?” and “What can the application do with it?” Leaving the second question unanswered pushes the discovery of restrictions into the publishing flow, after the user has already prepared their content.

With a destination and usable capability identified, the application can record a publishing attempt without confusing that attempt with its eventual result.

3. Submission records the attempt, not necessarily publication

Create the local attempt before making the external write. Link it to the reviewed content version, destination, media, and requested visibility, then retain the provider's response and identifiers when they arrive. This gives later status checks a specific job to reconcile.

In the Sendezeit code checked for this article, a submission returns accepted or published. Subsequent provider checks use processing, published, needs_action, or failed. The content lifecycle is a separate layer, with states such as scheduled and publishing.

Those names are implementation labels, not interchangeable proofs. An identifier may establish that a provider knows about the job without establishing that an ordinary viewer can see the content. The YouTube adapter's processing-complete result, in particular, is not an independent public-visibility check.

Keep requested visibility, reported provider status, and verified audience access as separate observations. Public, unlisted, and private are not one successful-upload category: an unlisted video can be accessible by link without being publicly discoverable. The next step is to determine what remains unfinished for the particular provider.

4. The remaining work depends on the provider and mode

TikTok's Upload Content flow makes this visible through SEND_TO_USER_INBOX. That status leaves the creator with a native step to complete; PUBLISH_COMPLETE is a later outcome. Publicly available post identifiers also depend on the documented public-viewership and moderation conditions. TikTok status reference.

An inbox handoff should not silently replace direct publishing because the two modes leave the user with different work. Provider approval matters here too: unaudited TikTok Direct Post clients are restricted to private viewing. Implementing the adapter does not remove that restriction. TikTok Direct Post setup.

The capture below establishes an earlier stage, not either completed outcome. It shows an unconnected preview and a disabled draft button. Its caption needs to respect that boundary just as the product's status message does.

This 27 September capture shows an unconnected preview with a disabled draft button, not a delivered draft. Screenshots by Anton Rost.

YouTube has a different sequence. The upload response may arrive before video processing finishes, so processing status must be checked separately. YouTube video implementation guide.

Google OAuth verification also differs from the YouTube API compliance audit. YouTube documents private-viewing restrictions for uploads from unverified API projects created after 28 July 2020, with an audit required to lift them. The verified consent-screen capture at the start of this article is not evidence that this audit passed. YouTube upload reference.

These intermediate stages make a missing response especially important to handle carefully. The absence of a result in the application is not always evidence that the provider did nothing.

5. An uncertain outcome needs reconciliation before a retry

A timeout can leave the provider's write completed while the application lacks its response. Repeating every failed-looking request risks creating duplicate posts, so preserve the uncertain attempt instead of immediately treating it as a failed publication.

Use a stable local attempt identity, without assuming that every provider honours a client-supplied idempotency key. Reconcile through the documented status endpoint, returned identifiers, or destination checks before deciding whether another write is safe.

Webhooks and polling can provide overlapping evidence about the same attempt. Follow the provider's signature, event, and replay rules rather than applying a universal signature recipe. Processing the same evidence twice should not create another publication or count another success.

If reconciliation is impossible, explain the uncertainty and offer a controlled next step. “Needs checking” is more useful than a confident success badge attached to a possible duplicate. Once individual attempts can be tracked this way, the release decision still needs a broader check: whether the path is available to the customers who will use it.

6. A founder's successful test is not the release decision

A provider may allow a founder or administrator to do something an ordinary external account cannot. Working code and a successful test therefore need to sit alongside production configuration, provider approval, and account-specific evidence.

The September captures show different dashboard states, not a completed availability audit. I use these five questions to keep that distinction visible:

This is a checklist, not a claim that every Sendezeit destination passes all five checks. Name the account type, requested mode, observed result, and date in the release record. That prevents an old administrator test from becoming a broad promise about current customer access.

Prepare the reviewer journey from the real product: a stable entry point, reproducible credentials where requested, reasons for each permission, and a recording of the supported path. Privacy, retention, disconnection, and deletion information should match the application.

A release record built around these checks gives the interface a sounder basis for its final message. It can describe the stage reached without borrowing certainty from an earlier milestone.

7. Tell the user which part of the job actually finished

Before showing success, check the destination and content version, processing status, actual visibility, and any remaining native step. Retain the result identifier or URL where available, together with the verification time. A URL alone is not a visibility test.

If authorization is all that completed, say connected. If the provider accepted an upload, say accepted or processing. If the creator must finish in the native app, make that step explicit. Reserve a public-access claim for evidence of public access.

Following the job in this order prevents the earliest green checkmark from standing in for the last. A social publishing platform should save the user from decoding several provider dashboards without hiding the differences between them.

I am building Sendezeit around that separation. This guide describes the implementation and review approach, not a guarantee that every provider is approved for every account or publishing mode.

Implementation checked and linked documentation reviewed on 3 October 2026. Screenshots record 27 September 2026; provider requirements and account access can change.