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.

They were supposed to stay in sync, which sounds perfectly reasonable until two files have had a few months to develop independent lives.

When I opened them again, the lists no longer matched. The Instagram document contained entries the YouTube one did not, and one of its rows still carried a YouTube tracking link. The calendar held yet another version of the week, although a row could mean planned, drafted, scheduled, attempted, or actually public depending on when I last remembered to update it.

One source library. Two upload documents. Several answers to what existed.

The same source library ended up with two separate upload playbooks.

Screenshots: Anton Rost. Source: original Pocket Orbit upload playbooks opened in Obsidian, 20 September 2026.

I blamed the documents first. Then I followed one post through the rest of the workflow and found the same drift in the calendar, the exports, and the upload state.

I could decide what to make. Getting the right version all the way to a public URL still depended on my memory.

I kept fixing the research because it was easier

The research system was genuinely useful. It started with phrases people were already searching around iPad notes, Apple Pencil workflows, lecture notes, handwriting, organisation, summaries, exports, and study methods.

I kept a knowledge base behind those phrases because I did not want a search term to turn straight into a confident answer I could not support. A query could be popular and still need better evidence, fall outside Pocket Orbit, or require review from somebody who actually spoke the language.

By then, the registry had grown into hundreds of search queries. A much smaller set had enough evidence to move into production.

Ready still only meant I could start making the thing.

So I kept returning to the registry. Cleaning another row felt manageable. Finishing, adapting, and publishing the work attached to it did not.

Then I counted the finished work

There were three completed carousels.

Each one had five slides: a hook based on the search query, three useful answer slides, and one action at the end. Pocket Orbit could appear once when it genuinely helped with the answer.

Those fifteen finished slides still required visual research, copy, real product screens, claim checks, layout, exports, and upload preparation.

Clearing the research check only put a topic at the start of production. It still needed a script, visuals, exports, and a version for each platform.

The registry kept growing. The smaller grid on the right is what actually made it live.

Screenshots: Anton Rost. Sources: Pocket Orbit query production registry in Obsidian and @antonships.app on TikTok, 20 September 2026.

Every file remembered a different version

One recording could become a TikTok edit, an Instagram caption, a YouTube title and description, sometimes a Facebook version, and a few notes about what I wanted to change later.

Updating one version did not update the others. Moving a date in the calendar did not prove the file was ready. A successful upload did not necessarily mean somebody else could see the post.

Planned, scheduled, attempted, and public were quietly becoming the same state.

The calendar looked organised because Tuesday had a row. It still could not tell me what had actually happened.

I was reusing the wrong thing

I had treated the final caption as the reusable unit. It should have been the real source underneath it.

That source might be a Pocket Orbit feature, a TikTok result, a paywall failure, or something I noticed while building after work. The event and its evidence should remain stable while the presentation changes for each destination.

On X, I can explain the reasoning. On TikTok, the useful visual has to arrive almost immediately. Instagram may use similar footage but still needs its own framing. YouTube needs another title, description, thumbnail, and link setup.

Copying one finished caption into every box was quick, but it flattened the idea into a version that fit nowhere particularly well.

The workflow I needed was simple enough to explain:

1. One real source
2. Versions for each platform
3. Review
4. Schedule
5. Check what really went live

I was still the only thing keeping those pieces connected.

That became Sendezeit

Sendezeit starts with something that actually happened, then keeps the destination versions, edits, approvals, calendar entries, and provider results attached to that source.

It does not fix the Pocket Orbit paywall or explain why somebody watched a TikTok and did not subscribe. Those questions still belong in the product, RevenueCat, and the analytics.

Sendezeit cuts out that weekly scavenger hunt. One source sits beside its X, TikTok, and YouTube versions. Each one keeps its own copy, media, review, schedule, and final publication result. I no longer have to remember which draft was final, reopen every platform to check it, or compare a calendar with a folder full of exports.

The replacement: one source, separate destination drafts, and the publishing state kept together.

Screenshot: Anton Rost. Source: live Sendezeit workspace, 20 September 2026.

You can run the same method in a spreadsheet: keep one source, write each platform version separately, review it, and record the public result beside the plan. I built Sendezeit because I was tired of maintaining those joins myself.

I had spent most of my time improving research because it was easy to organise. Meanwhile, I kept losing time at the other end, working out which version went where and whether it really went live. That gave me one clear requirement for the product: keep a reliable record of what I published.

Sendezeit is live now. X and YouTube have passed real-connection and provider-confirmed publishing checks. TikTok uses Direct Post when the account is eligible or an explicit draft handoff when it is not. Instagram and Facebook stay labelled coming soon while Meta review finishes.