Meta for Developers explained: Apps, Products, and where credentials actually live

developers.facebook.com is the technical side of the same integration Business Settings manages the business side of — App ID, App Secret, webhook config, and the two very different kinds of access token.

Beginner

4 min read

What this site is for, in one sentence

If Business Settings (previous lesson) is "who owns this and what's allowed," developers.facebook.com — "Meta for Developers" — is "the actual code-facing credentials and configuration": App ID, App Secret, access tokens, webhook URLs, API version.

The landing page: My Apps

developers.facebook.com/apps lists every App a Business Portfolio has created. This is a genuinely overloaded word worth pinning down immediately:

A Meta "App" is not the product being built. It's a registration/credential container Meta requires for any integration with its Graph API — WhatsApp Cloud API included. Whatever name is chosen for the App during setup isn't a customer-facing product name; it's the Meta-side technical registration that a backend authenticates through. A Business Portfolio can own multiple Apps; a single App can, in principle, serve multiple products at once.

Inside one App — the App Dashboard

Clicking into an App opens its own dashboard, roughly:

App Settings → Basic

App ID and App Secret — the core credential pair. The App Secret is also what verifies incoming webhook signatures — treat it with the same care as an access token, never commit it to source control.
Display name, category, contact email, privacy policy URL — the App's own "about" info, mostly irrelevant for a server-to-server integration (it matters more for consumer-facing apps requesting things like Facebook Login).

Products

The list of Meta products this App has "added" — WhatsApp being the relevant one here. Other products exist (Facebook Login, Instagram Graph API, Marketing API) — this is where a future integration (say, Instagram DMs) would get added, to the same App, rather than requiring a new one.

WhatsApp product page (once added) — the one actually used day to day

API Setup / Getting Started — shows a test number, a temporary token, and a "send a test message" panel used during initial setup.
Configuration — this is where the webhook URL and verify token are set, not in Business Settings. Also where the specific webhook fields to subscribe to are chosen (messages, message_template_status_update, etc.) — directly relevant to receiving inbound messages, covered in a later lesson.
Phone Numbers — add/manage numbers from the App's perspective (the same underlying data WhatsApp Manager shows from the Business Settings side — two different UIs into it).

App Roles

Administrators, Developers, Testers — separate from Business Settings' "People" list. A person needs an App role to see/edit the App's technical config, and separately needs Business Portfolio access to manage business-level assets (WABA, billing). These commonly overlap for the same people in practice, but are technically distinct permission systems.

App Review

Where Meta reviews requested permissions/scopes before they work in production for Apps that need broader access. For a server-to-server WhatsApp integration, the relevant permissions are typically grantable without a full consumer-app review flow once the WABA itself is set up — but if a specific permission ever shows as "needs App Review," this is the section that handles it.

Access tokens — where they actually come from

Two different kinds:

Temporary token   - generated right on the WhatsApp product's "API Setup"
                     page. 24-hour expiry. Tied to whoever's logged in
                     when it's generated. Fine for an initial test send,
                     useless for production.
Permanent token   - generated via a System User in Business Settings
                     (not from the App dashboard directly) — pick which
                     assets (this App, this WABA) the System User has
                     permission to act on, then generate a token scoped
                     to those permissions. Typically requires
                     second-admin approval. This is the credential that
                     belongs in a real deployment's environment
                     variables.

The temporary token is a genuine trap for a first-time integrator — it works perfectly during testing, then mysteriously stops working a day later in what looks like a production incident but is actually just expiry. Production code should always run on a System User's permanent token.

A separate tool worth knowing exists: the Graph API Explorer

developers.facebook.com/tools/explorer — a browser-based tool for manually firing API calls against a token, useful for debugging ("does this token actually have permission to send from this phone number?") without writing any code. Faster than a round-trip through an application's own logs for a one-off check.