---
name: meta-graph-app
description: >-
  The shared Meta App Dashboard registration mechanics behind every Meta Graph
  connector — the developer account, the business portfolio that claims the
  app, the app-creation wizard and its two irreversible choices, exact-match
  redirect URIs, Standard vs Advanced Access, the four review regimes (App
  Review, Business Verification, Access Verification / Tech Provider, Ongoing
  Review and Data Use Checkup), the App ID and Secret, `appsecret_proof` and
  rotation, Graph API versioning, and the common Graph error codes. Read this
  first for any Meta product, then the product skill (`facebook-oauth-app`,
  `meta-ads-oauth-app` or `instagram-oauth-app`). Use when asked to create a
  Meta or Facebook app, get a Meta App ID and App Secret, get through Meta App
  Review or Business Verification, or diagnose why only people with a role on
  the app can connect.
---

# Meta App Dashboard — shared OAuth2 registration mechanics

Everything that is the same for every Meta Graph connector: the developer account, the business portfolio, the app,
its redirect URIs, its **App ID and App Secret**, the review gates that decide whether anyone but you can use it,
and the versioning and rate-limit rules the credentials then live under. The product skills on top of this one add
only their own permission strings, hosts, token ladders and quirks.

Two things are worth internalising before you start, because they are what make Meta slower than most portals.

**The app is not the credential — the approvals are.** A perfectly configured app with a valid App ID and Secret can
authorize every user on Facebook and still be usable only by your own team, because permissions default to an access
level that excludes strangers. Getting past that is not one process but **four**: App Review, Business Verification,
Access Verification, and the ongoing reviews that can take it all away again. They run on different tracks, with
different owners and different failure symptoms. Budget weeks.

**Several choices here are permanent.** App type, and any use case you add, cannot be changed or removed afterwards.
Correcting either means a new app, a new App ID, and every existing customer re-authorizing. Read §3 before clicking.

## Inputs to collect before you start

Ask in one batch; never invent.

| Input | Notes |
| --- | --- |
| **App name**, contact email, icon, category | Shown on the consent screen; required before review (§3, §6) |
| **Which Meta product** the connector actually uses | Decides app type and use case — both irreversible (§3) |
| **Meta developer account** — whose personal Facebook account owns the app | (§2) |
| **Business portfolio** that will claim the app, and its verification status | Blocking for two of the four review regimes (§2, §6) |
| **Redirect URIs** — every callback host the platform serves | (§4) |
| **Permission set** — what the connector genuinely calls | Each one is a separate review submission (§5, §6) |
| **Privacy policy URL, terms URL, data deletion URL** | Required before submission (§6) |
| **A test account** you control, and a **second** one with no role on the app | (§10) |
| **Legal entity details** for Business Verification | A human decision — do not answer these (§6) |
| **New app or edit to an existing one?** | (§1) |

## Quick Start

1. Read **Platform state** (below) and the product skill's own Platform state — Meta changes this surface often.
2. Confirm a **new app** is justified; a new App ID orphans every existing customer connection (§1).
3. Register the developer account and decide which **business portfolio** claims the app (§2).
4. Create the app, choosing app type and use case deliberately — neither can be undone (§3).
5. Add **every** redirect URI exactly, then re-open the saved list and read what was actually stored (§4).
6. Request only the permissions the connector calls, and know each one's access level (§5).
7. Give yourself a role, make real calls, then run the review regimes in parallel (§6).
8. Capture the App ID and App Secret; decide about `appsecret_proof` before enabling anything (§7).
9. Pin an API version explicitly and calendar its expiry (§8).
10. Verify as a user with **no role on the app** — the only test that exercises the gates (§10), then hand off (§11).

## Platform state (verified 2026-09-20 — re-verify before trusting)

- **App types cannot be changed.** Meta: "App types cannot be changed. If your app needs products, permissions, or
  features that are unavailable to its current type you must create a new app with a different type instead."
- **Use cases cannot be removed.** "Use cases cannot be removed after you create your app. You can add compatible
  use cases to an existing app, however, once added, a use case cannot be removed."
- **Business apps have no app modes.** "Business apps do not have app modes and instead rely exclusively on access
  levels to determine who can grant them permissions." Development vs Live mode is a Consumer-app concept. If a
  ticket says "flip the app to Live mode" for a Business app, the ticket is describing a different surface (§5).
- **Access Verification / Tech Provider is live** and gates ~30 permissions across ads, Instagram, Pages, Threads and
  WhatsApp. It is, in Meta's words, "independent of App Review and permission access levels" — a fourth thing to
  clear, not a rename of one you already know (§6c).
- **Graph API versions expire on the two-year rule**: "A version will no longer be usable two years after the date
  that the subsequent version is released." Latest is **v26.0, released 29 July 2026**. Recent versions and expiries:
  v25.0 (18 Feb 2026 → 29 Jul 2028), v24.0 (8 Oct 2025 → 18 Feb 2028), v23.0 (29 May 2025 → 8 Oct 2027),
  v22.0 (21 Jan 2025 → 20 May 2027), v21.0 (2 Oct 2024 → 21 Jan 2027), v20.0 (21 May 2024 → 24 Sep 2026).
- **Individual products set their own, shorter clocks.** The two-year rule is the Graph API's. At least one Meta API
  built on the same host expires versions in about 90 days. Check the product skill before assuming two years (§8).
- **Meta issues no OAuth refresh tokens on any surface.** There is no `grant_type=refresh_token` anywhere in this
  platform. Each product has its own token-extension mechanism with its own endpoint, lifetime and terminal-expiry
  behaviour — read the product skill's token section, and plan re-authorization as routine operations, not as an
  incident (§7).
- **Meta's own docs are inconsistent in places**, including tier vocabulary and "current version" statements that
  disagree between pages. Where two Meta pages conflict, prefer the changelog and the reference pages over the guides,
  and say in your handoff which one you followed.

If the App Dashboard does not look like this, stop and report what you actually see rather than clicking on.

## 1. Decide: reuse the existing app, or register a new one

A new app means a **new App ID, and every existing customer connection is bound to the old one** — every customer
re-authorizes. On Meta that is worse than on most portals, because approvals do not travel: App Review is per app and
per permission, and a new app starts with none of it.

Reuse the existing app for: adding a redirect URI, adding a permission (which still needs its own App Review
submission), rotating a compromised secret, adding a login configuration, or diagnosing a failure.

Register a **new** app only when the user explicitly wants one: a first app for this connector, a replacement for a
compromised one, a deliberate split of deployment tiers, or a correction to an app type or use case that cannot be
undone (§3). One approval does carry across: **Access Verification is judged on the claiming business, not the app**,
so a second app under an already-verified business inherits Tech Provider status (§6c). Nothing else does.

Say which path you are taking, and why, before you touch anything.

## 2. Accounts: developer and business portfolio

Two distinct account objects, routinely conflated.

- **Meta developer account** — a personal Facebook account registered as a developer at
  `https://developers.facebook.com/docs/development/register`. Apps are owned by a person, not a company, until a
  business portfolio claims them.
- **Business portfolio** (Meta Business Manager, `business.facebook.com`) — required if the app "will access data
  that you don't own or manage," which is exactly what a multi-tenant connector does. At app creation you may defer
  it, but you will need one before Advanced Access. It is the entity that completes Business Verification, the entity
  Access Verification judges, and the entity whose "restricted" status silently un-verifies you (§6c). Connecting it
  up front avoids a re-submission.

**Hand control back to the user for anything only a human can do**: Facebook account creation, phone and email
verification, two-factor enrollment, accepting developer terms, and Business Verification document upload. Do not
retry a blocked step in a loop.

**If this session has no browser automation** — the usual case for a CLI or cloud run — do not pretend to click. Hand
the user an exact, ordered click path with the literal values to paste (the redirect URIs from §4 and the permission
list from §5), then continue once they report back with the App ID.

## 3. Create the app — and the two choices you cannot undo

Start at `https://developers.facebook.com/apps/creation/`. The wizard asks for app details, then **use cases**, then a
business portfolio, then shows the requirements for what you picked, then hands you the dashboard.

**Use cases** shape the dashboard and pre-add permissions and products. They are one of the two permanent choices:
adding the wrong one cannot be undone. Note also that a use case may pre-add permissions you do not need — prune
them, because requesting a permission you do not use is a review rejection, not a harmless extra (§5).

**App type** is the other. To choose it explicitly rather than have a use case choose for you, take the "Other"
branch: **Other** → **Next** → select **Business** or **Consumer** → **Next** → connect a business portfolio (now or
later) → **Create app**. The two types differ in more than name:

| | **Business** | **Consumer** |
| --- | --- | --- |
| Intended for | Apps that "help businesses, creators, and organizations manage their presence and advertise" | Apps giving individual users a personalized experience |
| App modes | **None** — access levels alone decide who can grant permissions | Development / Live modes apply |
| Access levels | Yes; auto-approved for Standard Access on everything available to the type | Yes |

Then **Add Product** in the left menu and **Set up** each product the connector needs. Products, permissions and
features available to you are constrained by the app type you can no longer change.

## 4. Redirect URIs

Where they are configured depends on the login product — the product skill names the exact panel. Add every URI and
save. The rules below are the same everywhere and are the single most common source of "but I registered it":

- **Matching is exact.** Meta's wording: "Make sure this exactly matches one of the base URIs in your list of valid
  oAuth URIs." No subdirectory matching, no trailing-slash forgiveness.
- **The dashboard may silently append a trailing slash.** Meta documents this: "The App Dashboard may have added a
  trailing slash to your URIs, so we recommend that you verify by checking the list." Re-open the saved list and read
  what is actually stored, character by character, before concluding anything else is wrong.
- **HTTPS only.** Multiple URIs are allowed; add them all.
- **The `redirect_uri` sent on the token exchange must be identical to the one sent on authorize.** A mismatch there
  fails *after* the user has already consented, which presents as a token-endpoint bug rather than a config error.

For this platform the callback list is one URI per data center. Confirm the current list with the platform owner
rather than assuming:

```
https://api.unified.to/oauth/code          # us (default)
https://api-eu.unified.to/oauth/code       # eu
https://api-au.unified.to/oauth/code       # au
https://api-dev.unified.to/oauth/code      # dev
```

## 5. Permissions and access levels

Every Meta permission carries an **access level**, and this is the mechanism behind the complaint that shows up in
every Meta integration post-mortem — *it works for us and for nobody else*.

- **Standard Access**: "Permissions with Standard Access can only be requested from app users who have a role on the
  requesting app." Business, Consumer and Gaming apps "are automatically approved for Standard Access for all
  permissions and features available to their app type," so this is where you start, free, for everything.
- **Advanced Access**: "Permissions with Advanced Access can be requested from any app user, and features with
  Advanced Access are active for all app users." This is what a multi-tenant connector needs. It "must be approved on
  an individual permission and feature basis through the App Review process," and "Business Verification is required
  to get Advanced Access."

Two consequences people get wrong:

- **Flipping a Consumer app to Live mode does not grant anything.** Live mode makes the app visible and lets it
  request permissions from non-role users; only permissions already approved through App Review will actually be
  granted. For Business apps there is no mode to flip at all (§3).
- **Request only what the connector calls.** Meta: "The most common reason an app is rejected during Meta App Review
  is for requesting advanced access to a permission or feature the app doesn't need or doesn't use to function
  properly. Do not request permissions or features your app doesn't need or won't use." Each permission is reviewed
  individually against a screencast of it being used, so an unused request is a rejection, not a rounding error.

The exact permission strings, and which of them your connector needs, belong to the product skill.

## 6. The four review regimes

Independent tracks, different owners, different failure symptoms. Run them in parallel; clearing one clears none of
the others.

### 6a. App Review → Advanced Access

Path: **App Review → Permissions and Features** → **Request advanced access** per permission. Then **App Review →
Requests** → **Edit** each item → **Complete App Settings** (app icon, category, privacy policy URL, data deletion
information) → for each permission, the **How this app uses…** panel → **Submit for Review**.

What the submission asks for:

- Complete app settings, including **privacy policy URL, terms URL and data deletion instructions**.
- Per permission: a description of how the app uses it, plus a **screencast showing the end-to-end user experience**
  for that specific permission. Screencast UI must be in **English**.
- **Test credentials** and step-by-step instructions, for each platform the app runs on, so a reviewer can log in and
  exercise the integration. A reviewer who cannot reproduce the flow rejects it.
- An agreement that you will comply with the allowed usage of each permission.

**Order matters.** Build first, add your own account as an app role, exercise the integration for real, and only then
submit. Some permissions additionally require a successful API call before Advanced Access can even be requested —
which you can only make while restricted to app-role users. A cold app gets bounced.

**Do not answer on the user's behalf**: compliance attestations, data-handling claims, volume or user-count
projections, or anything in the form that makes a legal claim. Draft them, hand them over, and say so.

### 6b. Business Verification

"A process that allows us to gather information about you and your Business so we can verify your identity as a
business entity." Meta: "Apps that request advanced access for permissions and apps that allow other Businesses to
access their own data must be connected to a Business that has completed Business Verification." Without it, "app
users from other Businesses will be unable to grant these apps permissions and all features will be inactive."

The stated exception — "If your app will only be used by app users who have a role on the app itself you do not need
to complete verification" — is fine for a prototype and useless for a connector. It needs legal-entity documents and
a business address or phone: **a human decision, not yours.** It is also the hard prerequisite for 6c.

### 6c. Access Verification → Tech Provider status

The gate most Meta write-ups miss entirely, and the one whose failure looks like something else.

"Tech providers are businesses that have a legitimate need to access business data owned by other businesses in
order to provide services or functionality to those businesses." Any business that has created or claimed an app
used by other businesses and needs any of ~30 listed permissions "must be verified as a Tech Provider before other
businesses can use the app." Access verification "is independent of App Review and permission access levels."

**How the check runs, which is why you will never see it in your own testing.** When a call arrives, Meta first asks
whether the person who granted the permission **has a role on the app**. If yes, the call proceeds untouched. If no,
Meta checks the claiming business's Tech Provider status, and if it is unverified returns:

> Error code: `100` — `Unsupported get request. Object with ID <OBJECT_ID> does not exist, cannot be loaded due to
> missing permissions, or does not support this operation.`

An error that reads like a bad object ID. You have a role, so you are exempt; only customers hit it.

**Mechanics.** Business admins are emailed when an app admin requests Advanced Access for any covered permission; the
form is also at **App Dashboard → Basics → Verifications → Access verification**. A business admin must "categorize
and describe how the business uses other businesses' data to provide a service for those businesses." Decision in
**approximately 5 days**. Businesses that already claim such apps get **60 days** from the notification email before
the checks begin applying. Prerequisites: Business Verification complete, and no restrictions on the business account.

**It can lapse.** A verified Tech Provider becomes unverified if the business's verification status reverts, the app
becomes disconnected from the business that created or claimed it, or the business account becomes restricted — and
returns automatically once the condition is reversed. So a live, previously working app can lose access with no
deploy and no notice.

### 6d. Ongoing Review and Data Use Checkup

Approval is not permanent. Apps with Advanced Access "are required to undergo Ongoing Review to retain access," and
"if we are unable to access your app for testing and you do not reply to the required action in the requested time
frame, your app may be deactivated." On top of that, **Data Use Checkup** is an annual assessment of "whether a
developer's continued use of and access to specific data via Meta APIs is in compliance"; developers who do not
certify in the allotted window risk losing platform access. A **Data Protection Assessment** may also apply
depending on the data the app holds.

Put the Ongoing Review and Data Use Checkup dates on a calendar at handoff. Losing access this way is the most
avoidable outage on this platform.

## 7. Capture the credentials

For most Meta products the credentials are at **App Dashboard → App Settings → Basic**:

- **App ID** → your OAuth `client_id`
- **App Secret** → your OAuth `client_secret`

Some product surfaces display a *second, separate* pair for their own login flow; where that is true the product
skill says so, and handing over the wrong pair produces an error that reads like a redirect-URI problem. Record which
product surface the app is built on, next to the credentials.

Also record, because the run is not reproducible without them: the claiming business portfolio; the access level of
each permission; the pinned API version and its expiry; and the status of each of the four review regimes.

**`appsecret_proof` and "Require App Secret."** Meta supports signing calls with `appsecret_proof` — "a sha256 hash
of your access token, using your app secret as the key" — to prove a call comes from your server rather than from a
stolen token. Turning on **App Settings → Advanced → Security → Require App Secret** makes it mandatory; every call
without the parameter then fails. **Do not enable it unless the client already computes the proof**, and verify which
secret keys the HMAC for your product surface before flipping it.

**Rotation.** Rotating the app secret invalidates the old one immediately: existing access tokens keep working until
they expire, but every code exchange and every token extension fails until the new secret is deployed. Never rotate
without explicit go-ahead and a cutover plan.

**Token lifetimes and extension are product-specific.** There is no OAuth refresh token anywhere on this platform;
what replaces it differs per surface. Read the product skill's token section and treat re-authorization as a
scheduled operation.

## 8. API versions

Pin a version explicitly in every path. Unversioned calls fall back to whatever version is set on the app dashboard's
**Settings → Advanced → Upgrade API Version** card, so they drift under you; on some Meta APIs unversioned calls are
rejected outright.

The Graph API rule: "Each version is guaranteed to operate for at least two years. A version will no longer be usable
two years after the date that the subsequent version is released" — dated from the *next* release, not from yours.
See **Platform state** for the current table.

What happens at expiry is the part that bites: "once a version is no longer usable, any calls made to it will be
defaulted to the next oldest, usable version." Calls do not cleanly fail; they silently answer from a different
version, so behaviour changes without an error. Calendar the upgrade rather than waiting for a symptom.

**Individual Meta APIs override this with shorter clocks and different expiry behaviour.** Check the product skill
before assuming two years.

## 9. Rate limits

Meta returns throttling as an HTTP 400 with an error code in the body, not as a 429. A platform that keys retry logic
on status codes alone will misdiagnose every one of these.

**Per app — platform rate limits.** Read the `X-App-Usage` header: `call_count`, `total_cputime` and `total_time`,
each a percentage of the allowance over a rolling hour. For apps the allowance is "200 * Number of Users" calls per
hour, where that is unique daily active users — "not a per User limit but a limit on calls made by your app."

**Per business use case — BUC limits**, which is where most product APIs actually live. Read
`X-Business-Use-Case-Usage`: `call_count`, `total_cputime`, `total_time`, `business-id`, `type` (one of
`ads_insights`, `ads_management`, `custom_audience`, `instagram`, `leadgen`, `messenger`, `pages`),
`estimated_time_to_regain_access` in minutes, and `ads_api_access_tier`. Per-product allowances and any additional
headers belong to the product skill.

**When limited, stop.** Meta: "When the limit has been reached, stop making API calls. Continuing to make calls will
continue to increase your call count, which will increase the time before calls will be successful again."

## 10. Verify end-to-end

Authorizing with the account that owns the app proves almost nothing. That account has a role, so it bypasses both
the Standard/Advanced Access check (§5) and the Tech Provider check (§6c) — the two things most likely to be wrong.

1. Run the full authorize → callback → code exchange round trip with your own account, to prove the redirect URIs and
   the exchange work at all.
2. Extend the token by whatever mechanism the product uses, confirm the connector **stored the new value**, and make
   a read call with the stored token.
3. Make one real read call against the product's host, with the pinned version.
4. Now repeat the whole thing as a user with **no role on the app**. Before Advanced Access this correctly fails;
   before Tech Provider verification it fails as `(#100)`. Those two failures are the proof that §6 is unfinished,
   and this is the only test that surfaces either.
5. Re-open the saved redirect URI list and compare it character for character with what the client sends.

| Symptom | Cause |
| --- | --- |
| `(#1)` *An unknown error occurred* | Usually transient; retry with backoff before investigating |
| `(#4)` *Application request limit reached* | App-level platform or load limit — check `X-App-Usage` (§9) |
| `(#10)` *Application does not have permission for this action* | Permission not approved in App Review, or not requested at authorize time (§5, §6a) |
| `(#17)` *User request limit reached* | Per-user rate limit (§9) |
| `(#100)` *Invalid parameter* | A malformed request — field name, value or object ID |
| `(#100)` *object does not exist, cannot be loaded due to missing permissions* — for customers only, never for you | Business not verified as a **Tech Provider**; the check is skipped for app-role users (§6c) |
| `(#102)` *Session key invalid or no longer valid* | Stale session; the user must re-authorize |
| `(#190)` *Invalid OAuth 2.0 Access Token* | Token expired, revoked, password changed, or never extended — read the subcode (§7) |
| `(#200)` *Permission error* | The permission was never granted for this object, or the user lacks the required role on the asset — customer-side as often as app-side (§5) |
| `(#80000)` / `(#80004)` / `(#80003)` / `(#80002)` / `(#80005)` / `(#80006)`, subcode `2446079` | Business-use-case rate limits — the product skill says which bucket is which (§9) |
| `(#32)` / `(#80001)` | Page-level rate limits, by token type (§9) |
| Only your own team can connect; strangers fail at consent | Permission is at Standard, not Advanced, Access (§5, §6a) |
| Consent succeeds, token exchange fails | `redirect_uri` differs between authorize and exchange, or the code was reused or has expired (§4) |
| Redirect mismatch after consent | URI not registered exactly, or the dashboard appended a trailing slash (§4) |
| Every call fails a signature check | "Require App Secret" is on but the client does not send `appsecret_proof` (§7) |
| Calls behave differently on a date nobody deployed | The pinned API version expired and calls defaulted to another version (§8) |
| A previously working app loses access with no deploy | Business Verification reverted, the app was disconnected from its business, or the business was restricted (§6c) |

## 11. Hand off — never commit the secret

- **Do not** write the App Secret into source control, a test, a fixture, a committed `.env`, a ticket, a PR body or
  a chat channel. Values go to the user, for their secret store or console. Report it once, say plainly that it is
  now in the transcript and can be rotated, then move on.
- If a code change is needed (a redirect host, a permission, a re-pinned version, a token schedule), keep it
  secret-free and say what the human must set out of band.
- Close with: app name and **App ID**; where the secret was delivered; app type and use cases; the claiming business
  portfolio; the exact permission strings and each one's access level; the status of all four review regimes; the
  pinned API version and its expiry; the Ongoing Review and Data Use Checkup dates; and anything left for the user
  to do. The product skill adds its own items to this list.

## Stop and ask

Hand back to a human rather than guessing when: Business Verification or Access Verification asks for legal-entity
documents, ownership, addresses, or a description of how the business uses other businesses' data; App Review asks
for compliance attestations, data-handling claims or volume projections; the app type or a use case would have to
change, which is impossible and means a new app and a re-authorization of every customer; someone proposes
requesting a permission the connector does not call; a customer cannot connect for reasons on their side; the
platform has no re-authorization story for tokens that expire; or the App Dashboard does not match the
**Platform state** section above.

## Other Meta surfaces you might arrive with

Everything in this file applies to all of them. What differs is the product's host, permission strings, login
product, token ladder and version clock.

| Surface | Skill | What it adds on top of this file |
| --- | --- | --- |
| **Marketing API** (Meta Ads / Facebook Ads) | `meta-ads-oauth-app` | Business app type, Facebook Login for Business configurations, `ads_read` / `ads_management` / `business_management`, the Limited→Full access tier, a 90-day version clock, per-ad-account and insights throttles |
| **Instagram Platform** | `instagram-oauth-app` | The Instagram-Login vs Facebook-Login-for-Business product split, `instagram_business_*` permissions, `graph.instagram.com`, a *separate* Instagram App ID and Secret, and a three-stage token ladder |
| **Facebook Pages** | `facebook-oauth-app` | `pages_*` permissions (several of them on the Access Verification list, §6c) and **Page access tokens**, derived from a user token rather than issued at authorize time |
| **Messenger Platform** | none yet | Page-scoped messaging permissions, its own BUC rate-limit bucket (`messenger`, error `#80006`), and webhook subscriptions as a first-class part of setup |
| **WhatsApp Business Platform** | none yet | `whatsapp_business_management` (also on the Access Verification list), per-WABA request budgets rather than per-app ones, and its own onboarding on top of Business Verification |
| **Threads** | none yet | `threads_*` permissions (five of them on the Access Verification list) and an impression-based rate-limit formula |

If you arrive with a surface that has no skill, this file plus that product's own docs is the whole job — and
consider writing the product skill afterwards.

## References

All verified to return HTTP 200 on 2026-09-20. Product-specific references live in the product skills.

- Register as a developer — https://developers.facebook.com/docs/development/register
- Create an app — https://developers.facebook.com/docs/development/create-an-app/
- Other app types (the explicit Business/Consumer path) — https://developers.facebook.com/docs/development/create-an-app/other-app-types
- App types — https://developers.facebook.com/docs/development/create-an-app/app-dashboard/app-types
- App creation wizard — https://developers.facebook.com/apps/creation/
- App roles — https://developers.facebook.com/docs/development/build-and-test/app-roles
- App modes (Development vs Live) — https://developers.facebook.com/docs/development/build-and-test/app-modes
- Standard vs Advanced Access — https://developers.facebook.com/docs/graph-api/overview/access-levels
- App Review — https://developers.facebook.com/docs/app-review
- Business Verification — https://developers.facebook.com/docs/development/release/business-verification
- About Business Verification (Business Help Center) — https://www.facebook.com/business/help/1095661473946872
- Access Verification (the Tech Provider check, error 100, the 60-day window) — https://developers.facebook.com/docs/development/release/access-verification/
- Tech Providers — https://developers.facebook.com/docs/development/release/tech-providers/
- Ongoing Reviews — https://developers.facebook.com/docs/resp-plat-initiatives/individual-processes/ongoing-reviews
- Data Use Checkup — https://developers.facebook.com/docs/development/maintaining-data-access/data-use-checkup/
- Data Protection Assessment — https://developers.facebook.com/docs/resp-plat-initiatives/data-protection-assessment
- Access token types — https://developers.facebook.com/docs/facebook-login/guides/access-tokens
- Securing requests / `appsecret_proof` — https://developers.facebook.com/docs/graph-api/securing-requests
- Graph API versioning — https://developers.facebook.com/docs/graph-api/guides/versioning
- Platform versioning — https://developers.facebook.com/docs/apps/versions
- Graph API changelog (version release and expiry table) — https://developers.facebook.com/docs/graph-api/changelog
- Graph API rate limiting (`X-App-Usage`, `X-Business-Use-Case-Usage`, 80000-series codes) — https://developers.facebook.com/docs/graph-api/overview/rate-limiting
- Graph API error handling — https://developers.facebook.com/docs/graph-api/guides/error-handling
- Meta error code reference — https://developers.facebook.com/docs/marketing-api/error-reference
- Graph API Explorer — https://developers.facebook.com/tools/explorer/
- Access Token Debugger — https://developers.facebook.com/tools/debug/accesstoken/