← All guides
api

What I Learned Waiting on API Approvals from Meta, LinkedIn and TikTok

7 min read

You submitted the app review. You filled out the use case form. You recorded the screen capture. You waited.

Then you waited some more.

If you are building a SaaS product or an AI tool that touches social data, what I learned waiting on API approvals from Meta, LinkedIn and TikTok is probably the most useful thing you can read before you write a single line of integration code. Not because I have a trick to skip the queue. But because most founders burn weeks on the wrong assumptions, and I have burned them too.

The real problem is not the wait, it is what you build while you wait

Every platform has a review process. Meta's Marketing API review can take anywhere from a few days to several weeks depending on the permissions you request. LinkedIn's Partner Program is invitation only for the most useful endpoints, meaning you may get back a polite no regardless of your use case. TikTok's API access for anything beyond basic display requires a business verification and a detailed data handling questionnaire that trips up founders who did not read the policy before building.

The mistake I see most often: founders build the full integration before access is granted. They wire up the OAuth flow, build the dashboard, ship the frontend, and then submit for review. When the review comes back asking for changes, or asking for a different permission tier, or just rejecting the use case, there is real rework to do. Sometimes the product concept has to change.

Here is what I do instead.

Submit first, then build to the scope you are actually approved for

Before writing integration code, I submit the review request with mock screens and a clear use case document. This tells me two things fast: which permissions the platform will realistically grant, and how long the queue actually is for that specific use case. The answer shapes what I build, not the other way around.

For Meta, the permission scope matters enormously. Read access to Pages is relatively easy to get. Writing posts on behalf of users, or accessing ad data, requires business verification and often a legal entity in a recognized market. I have seen founders from smaller markets get stuck here not because their product is wrong but because the verification flow assumes a US or EU incorporated entity.

For LinkedIn, if you are not already a recognized Marketing Partner, the Member Data Portability API and the Community Management API are the ones worth applying for. The Share on LinkedIn endpoint is the easy one. Plan your MVP around what you can get, not what you wish existed.

For TikTok, the Content Posting API is available to most developers after basic review. The Research API, which lets you query public content, has a separate and stricter process. If your product depends on the Research API, build a manual fallback first. Run the product with a human in the loop while you wait. This also forces you to talk to early customers, which is never a bad thing.

If you are at this stage right now and need a technical partner who has already been through these processes, send me a message at ledianshera.com. I will tell you in one call what is realistic for your use case.

Who this applies to, and who it does not

This is for you if... This is not for you if...
You are building a SaaS tool that reads or writes social content on behalf of users You just want to show social feeds on your own site (there are simpler embed paths)
You have a real business use case and a legal entity You are in early ideation with no product yet
You can wait 2 to 8 weeks for approval while building the rest of the product You need the integration live next week
You want to understand the tradeoffs before committing engineering time You have already built and just need someone to fix a bug

I work with founders and small product teams who are technical enough to know what an API is but who do not have a dedicated engineer to navigate platform compliance alongside shipping features. That is the gap I fill.

What I actually saw happen during these approvals

I have submitted and managed API access requests across Meta, LinkedIn and TikTok as part of building products under AlbTech Solutions. The pattern is consistent.

Meta's review team reads your use case document carefully. If your description of data usage is vague, they will ask for clarification, and that adds weeks. The screen recording they require must show a real or realistic UI. I always build a clickable prototype before submitting, even if the backend is not wired yet. It removes one of the most common rejection reasons.

LinkedIn is the strictest. Their Partner Program is genuinely selective. If your product does not fit one of their defined partner categories, you will hit a wall regardless of how good the integration is. I have learned to scope the product differently in cases like this, building on top of what is available rather than what would be ideal.

TikTok moves faster than the other two on basic access, but their documentation has gaps. I have found that reading the raw API responses directly, not just the docs, tells you more about actual rate limits and field availability. Plan for fields to change without notice. Build defensively.

A realistic timeline if you are starting today

Week 1: Submit all three reviews simultaneously. Do not wait for one before submitting another. Weeks 1 to 3: Build the product core that does not depend on approved access. Auth flows, user settings, billing, onboarding. Weeks 3 to 6: Use sandbox or limited access to build and test the integration layer. Weeks 6 to 8 and beyond: Approved permissions arrive in waves. Build to each one as it clears.

This is not a worst case scenario. This is what a well managed process looks like.

The objection I hear most often

"We cannot afford to spend 6 weeks waiting before we have a working product."

I understand this. But the framing is wrong. You are not waiting for 6 weeks. You are building for 6 weeks while the review runs in parallel. The review timeline is fixed. Your engineering time is the variable. If you structure the work the way I described above, you arrive at approval day with a nearly complete product. If you do not structure it this way, you arrive at approval day realizing you built for permissions you did not get.

The cost is not the wait. The cost is the rework that comes from ignoring the wait.

For founders building on tighter budgets, the startup MVP development track at AlbTech Solutions is designed for exactly this situation: ship the core product fast, wire up external APIs once you have real access, and do not over engineer the integration before you know what the platform will let you do.

What happens when you reach out

If you are building a product that touches Meta, LinkedIn or TikTok APIs and you want a technical partner who has been through the approval process, here is what I offer.

Send me a message at ledianshera.com with a two paragraph description of what you are building and which platforms you need access to. I will respond within one business day. If it is a fit, we do a 30 minute call where I tell you exactly which permissions are realistic, what the review will ask for, and how to structure the build so the wait does not cost you.

No proposal decks. No discovery process that takes three weeks. One call and a clear answer.

Frequently asked

How long does Meta API approval actually take?
It depends on the permissions you request. Basic Page read access can clear in a few days. Permissions involving ad data or user content on behalf of others can take three to six weeks, sometimes longer if the review team asks for clarification on your use case documentation. Submitting a complete, detailed use case document with a working UI recording is the single biggest thing you can do to avoid back and forth.
Can a founder outside the US or EU get approved for Meta or LinkedIn APIs?
Yes, but it is harder. Meta's business verification process assumes a recognized legal entity, and founders from smaller or less common markets sometimes hit friction here. LinkedIn's Partner Program is selective globally, not just by region. I have navigated this for products built in and for European markets. The key is having a properly registered entity and a clearly documented, legitimate use case before you submit.
What does working with you on an API integration actually look like?
We start with a 30 minute call where I review your use case and tell you which permissions are realistic and what the review will likely ask for. From there, I can take on the full integration build, the review submission, or just the technical architecture depending on what your team already has in place. I work with small product teams and solo founders who need a senior technical hand without a full time hire.
What if the platform rejects our API application?
Rejection is not always final. Most rejections come with a reason, and the most common one is a vague use case description rather than a disqualifying product. I have resubmitted applications successfully after tightening the documentation. If a permission is genuinely unavailable for your use case, I can help you scope the product to what is achievable rather than blocking the whole build on a single endpoint.
Should we build the integration before or after we get API access?
Submit for review first, then build the product core that does not depend on approved access. Build the integration layer in sandbox mode while you wait. This way you arrive at approval with a nearly finished product instead of starting the integration clock after approval. Most of the rework I see comes from founders who did it in the wrong order.

Need a builder who ships?

I help founders and teams design and ship real software, fast. Full stack, AI, and everything around it.

Work with me