Getting a Meta App Approved: App Review and Webhooks, Done Right the First Time

Creating an app on Meta's developer platform takes five minutes. Getting it approved to actually do anything beyond testing with your own accounts is the part that takes real preparation, and it's where most first-time integrations lose weeks they didn't budget for.

Advanced access needs two things

Most permissions you need, sending WhatsApp messages at scale, reading Instagram messages, managing Lead Ads, are classified as advanced access. Advanced access requires a verified Business Manager (covered in the previous video) and the app in Live Mode, not Development Mode. Meta won't even let you submit an advanced access request while the app is still in Development Mode, and Live Mode comes with its own stricter rate limits that don't matter until a reviewer is actually watching.

Reviewers approve what they can watch working, not your roadmap

Meta's reviewers want a working demo, a clear use case description, and screen recordings showing the actual feature in action, not a description of what it will eventually do. Submitting a review for a permission your app doesn't yet visibly use is the fastest way to get rejected, and it's the mistake nearly everyone makes on their first submission because it feels efficient to request everything you'll eventually need in one pass.

WhatsApp and Instagram permissions are reviewed on separate tracks, even inside the same app. If you need both messaging and content-publishing permissions, that's two separate review cycles, not one combined submission. Get one feature working end to end, record it, submit it, then start the next one.

Webhooks: the handshake, then the part everyone forgets

Most of what an integration needs to react to, an incoming message, a comment, a lead form submission, arrives as a webhook event, not something you poll for. Registering one means Meta verifying your callback URL with a handshake: a GET request carrying a mode field, a verify token you chose, and a random challenge string. Your endpoint must check the mode and token match, then respond with exactly that challenge string. Get it wrong, even by a stray character, and the webhook is never sent a single real event.

Verification is only step one. After that handshake succeeds, you still have to explicitly subscribe to the specific fields you want delivered, most importantly "messages" for anything conversational. Skipping this second step is a quiet trap: the handshake succeeds, everything looks green in the dashboard, and then nothing ever arrives.

A webhook endpoint also has to respond fast, generally within a few seconds, or Meta retries the delivery, which can double-process the same event. This is one of the most common silent bugs in a Meta integration: everything works in testing, and then in production a slow database write causes a timeout, Meta retries, and a customer sees the same automated reply sent twice. Building idempotency in from day one, checking a message ID against what's already been processed, prevents this.

When a submission gets rejected

The most common real causes, beyond requesting a permission you don't yet use: a demo that doesn't clearly show it's the same flow a real user would hit, a privacy policy that doesn't specifically mention the data the permission accesses, or a use case description too vague for a reviewer to tell what the app actually does. There's also a cooldown before resubmitting the same permission, so treat the first submission as the one to get right.

Why this matters if you don't want to own this process

App Review done permission by permission with a real working demo each time, and webhooks verified with retry-safe handling, is what makes an app actually ready to run unattended. LeadOro has been through this review process on real client apps enough times to know exactly what a demo needs to show to pass on the first attempt, not the third.