Building a social media integration is one thing.
Getting the social network to actually approve it for production is another.
Over the past several months, I have been building VidSyndicate, a social media publishing and video distribution platform. One of the goals behind the project is to give businesses a single application for managing content across networks such as Facebook, Instagram, LinkedIn, YouTube, Pinterest, TikTok, and others.
From a development standpoint, connecting an API is often the easy part.
The difficult part can be getting through the platform's review process.
Recently, we reached two major milestones:
- YouTube Live was approved
- TikTok's draft/inbox publishing workflow was approved
Neither approval was a simple "submit the app and wait" process.
There were multiple rounds of development, documentation, demonstrations, policy changes, scope explanations, branding updates, and reviewer feedback before we got there.
As the developer behind both Custom PHP Design and VidSyndicate, the experience reinforced something I have been seeing for years:
Social media API integration requires more than knowing how to make an HTTP request.
It requires understanding the platform, OAuth, permissions, security, application architecture, compliance, and increasingly, how to communicate your implementation to an auditor.
Building YouTube Live Into VidSyndicate
The YouTube integration started with normal video publishing, but I wanted VidSyndicate to go considerably further.
I wanted users to be able to create and manage a YouTube livestream directly through VidSyndicate.
That meant integrating with Google's OAuth system, the YouTube Data API, and YouTube's live streaming functionality.
The completed workflow allows VidSyndicate to handle much of the livestream lifecycle from inside the application.
That includes creating the broadcast, creating and connecting the stream, monitoring its status, displaying live information, and ending the broadcast.
Behind the scenes, the actual streaming infrastructure was another engineering project entirely.
VidSyndicate uses cloud infrastructure and FFmpeg-based processing to handle the video stream. I eventually moved toward isolated AWS ECS tasks for livestream workloads rather than treating streaming like a normal web request.
That part was challenging.
But getting the OAuth permissions approved was a different kind of challenge.
The Code Worked Before the Review Was Finished
This is something businesses need to understand when developing social media integrations.
Working code does not automatically mean you have a production-ready integration.
You can successfully authenticate against an API.
You can successfully create a broadcast.
You can successfully upload a video.
You can successfully receive data.
And your application can still fail the platform review.
Google needed to understand exactly why VidSyndicate requested its YouTube permissions and how those permissions were being used.
For youtube.upload, the purpose is fairly straightforward: users authorize VidSyndicate to upload videos they have selected.
The live streaming functionality requires broader capabilities.
VidSyndicate needs to create and manage broadcasts and streams, connect them, monitor their state, interact with live functionality, and manage the broadcast lifecycle.
Explaining that clearly became part of getting the application approved.
Then Comes the Screencast
A social platform reviewer doesn't have the same context the developer has.
I had spent months working on VidSyndicate. I knew exactly what every button did and why every API request existed.
The reviewer doesn't.
That means the demonstration itself becomes part of the engineering process.
For the YouTube review, we had to make sure the demonstration clearly showed the authorization process and the actual functionality associated with the requested permissions.
The review material walked through the process from beginning to end:
- Connect the YouTube account.
- Display the requested Google/YouTube permissions.
- Create a livestream.
- Start the streaming infrastructure.
- Verify the broadcast through YouTube.
- Monitor the live broadcast.
- Demonstrate the application's live functionality.
- End the stream.
The privacy policy also had to clearly explain how Google and YouTube user data was accessed and used.
Even small details mattered.
At one point, Google's feedback required the OAuth consent experience to make the services being requested clearer. That meant revisiting the consent flow and the supporting demonstration rather than simply saying, "The API works."
Eventually the functionality, branding requirements, privacy disclosures, and requested scopes moved through the verification process.
TikTok Was Its Own Adventure
TikTok presented a completely different review experience.
VidSyndicate supports a TikTok workflow where a video can be sent to TikTok and delivered through TikTok's inbox/draft-style publishing experience.
The user completes the final publishing process inside TikTok.
From an application-design perspective, it is a useful middle ground.
VidSyndicate can prepare and transfer the content while TikTok retains the final publishing interaction.
Getting that functionality approved still required going back and forth through TikTok's review process multiple times.
And this wasn't my first experience dealing with TikTok review.
We had gone through TikTok audit attempts before. Each submission teaches you a little more about what the reviewer expects to see.
Sometimes the Rejection Isn't About Your API Code
One of the TikTok review issues is a good example of why social integration work can become frustrating.
The underlying integration could work correctly while something seemingly minor prevented approval.
Branding was one of those issues.
The application icon needed to properly match the product branding.
That meant making sure the icon, application identity, and website presentation were consistent enough for the reviewer.
From a programmer's perspective, changing an icon has absolutely nothing to do with whether an OAuth callback or publishing API works.
From the platform's perspective, however, identity and branding are part of determining whether users understand which application they are authorizing.
So you fix it.
Then you submit again.
Submit, Wait, Fix, Demonstrate, Repeat
That became a recurring pattern during development:
text
Build the integration
↓
Test it
↓
Submit for review
↓
Wait
↓
Receive reviewer feedback
↓
Determine what the reviewer actually needs
↓
Update the application or documentation
↓
Record another demonstration when necessary
↓
Resubmit
↓
Repeat
