---
name: tiktok-oauth-app
description: Registers an app in the TikTok for Developers portal to obtain OAuth2 credentials — the client key (TikTok's name for the client ID) and client secret — for Login Kit, the Display API and the Content Posting API, including sandbox testing, per-scope app review, exact-match redirect URIs, and a safe credential handoff. Use when asked to get TikTok OAuth credentials, create a TikTok developer app, add or get approval for a TikTok scope, rotate a TikTok client secret, or fix a TikTok authorization error. This covers the consumer TikTok app only — TikTok ads/marketing credentials live in the separate TikTok API for Business portal and TikTok Shop credentials in the separate TikTok Shop Partner Center; use the skill for those portals instead. For any other vendor's developer portal, use that vendor's skill instead.
---

# TikTok OAuth2 App Registration

Get a working TikTok OAuth2 client — a developer account, an app, redirect URIs, an approved scope set, a client key
and a client secret — for a platform that connects many customers' TikTok accounts.

Three things about TikTok are expensive to get wrong, and all three cost a review cycle rather than a retry:

1. **There are three unrelated TikTok developer portals.** Registering in the wrong one produces credentials that
   will never authenticate against the API you meant. Read §0 before you click anything.
2. **Scopes are approved one by one by human reviewers**, and the app review asks for a demo *video* showing each
   requested scope in an end-to-end flow. Adding a scope later means another review. Decide the whole scope set up
   front (§5).
3. **Redirect URIs are exact-match, HTTPS-only, and must carry no query string or fragment**, with a hard cap of 10
   per app — and after the app is live, any change goes back through review (§4, §6).

A fourth thing that is not registration at all but breaks connectors anyway: TikTok calls the client ID a
**`client_key`**, scopes in the authorize URL are **comma-separated** rather than space-separated, and refresh tokens
**rotate**. §7 covers those.

## Inputs to collect before you start

Ask in one batch. Never invent.

| Input | Notes |
| --- | --- |
| **Which TikTok product** | Consumer app (this skill), ads/marketing, or Shop — settle this first (§0) |
| **App name, icon, category, description** | Icon 1024×1024 px JPEG/JPG/PNG, max 5 MB; shown on the consent screen |
| **Website URL, Terms of Service URL, Privacy Policy URL** | Mandatory for apps created after 2024-09-09; must be live, public pages (§3) |
| **Organization** | Who owns the app — strongly recommended over a personal account (§2) |
| **Redirect URIs** | Every callback host, exact (§4) |
| **Scope set** | The complete list, including anything wanted within the next few months (§5) |
| **Test TikTok accounts** | Up to 10 sandbox target users, with someone able to log into each (§2, §6) |
| **Demo recording owner** | Who will record the end-to-end walkthrough video for review (§6) |
| **New app or edit to an existing one** | Determines whether customers must re-authorize (§1) |

## Quick Start

1. Confirm you want the **consumer TikTok for Developers app**, not ads or Shop (§0).
2. Confirm a **new app** is needed — a new client key orphans every existing connection (§1).
3. Sign in or sign up at the developer portal, and create/join an organization (§2).
4. Register the app, fill in the basics, add products, verify the URL properties (§3).
5. Add **every** redirect URI, exactly (§4).
6. Add the complete scope set, matching what the connector actually calls (§5).
7. Build a **sandbox**, add target users, and prove the flow works before submitting (§6).
8. Submit for **app review** with a demo video per product/scope, and wait (§6).
9. Capture the client key and client secret; note the token lifetimes (§7, §8).
10. Verify a real authorize → callback → refresh round trip (§9), then hand off (§10).

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

**The portal split is the single most important fact here.** TikTok runs three separate developer platforms with
separate accounts, separate apps, separate credentials, separate review queues and different credential names. They
are not interchangeable, and credentials from one will not work against another:

| Product | Portal | Credential names | What it covers |
| --- | --- | --- | --- |
| **Consumer TikTok app** — *this skill* | `https://developers.tiktok.com/` | **client key** / **client secret** | Login Kit, Display API (profile + videos), Content Posting API, Research API, Data Portability |
| **Ads / marketing** | `https://business-api.tiktok.com/portal` | **App ID** / **Secret** | Marketing API: campaigns, ad groups, ads, reporting against TikTok Ads Manager |
| **Commerce** | `https://partner.tiktokshop.com/` (US: `https://partner.us.tiktokshop.com/`) | **App Key** / **App Secret** (+ Service ID) | TikTok Shop orders, products, fulfilment |

If someone asks for "TikTok OAuth credentials" without saying which, **ask**. The tell: if the connector reads
campaigns, ad accounts or ad reporting, it is the Business portal; if it reads orders, products or shops, it is
Partner Center; if it reads a creator's profile, videos, or posts videos, it is this one. The Business portal also
requires a **verified company-domain email** to register — personal and temporary email addresses are rejected — so
a run that starts with a Gmail address is already in the wrong place if the target was ads.

Current state of the consumer portal:

- **Apps are registered through "Connect an app"** on the Manage apps page, owned by an **organization** you select
  at creation. Client key and client secret are generated automatically at that point.
- **Apps created after 2024-09-09 must supply Terms of Service, Privacy Policy and a Web or Desktop URL**, and must
  pass **URL ownership verification** (DNS record for a domain, or a URL-prefix property) before submission.
- **Sandbox mode exists and is mandatory for first-time approval.** Up to **5 sandboxes per app**, each shareable
  with up to **10 target user accounts**. Sandboxes do not cover the Content Posting API for public videos, nor the
  Data Portability API.
- **App review takes "several days to two weeks"** after submission, per TikTok's own FAQ. While the app is
  **In review** no further changes can be made; you can **Recall** to withdraw. Statuses are Draft → In review →
  Live / Not approved.
- **Once live, any subsequent change must be re-submitted and re-approved** before it appears in the live release.
  That includes adding a scope, adding a redirect URI, or changing the app name or icon.
- **`user.info.basic` is added by default for every app with Login Kit.** Everything else is requested and reviewed.
- **Token lifetimes**: access token 86,400 s (24 h); refresh token 31,536,000 s (365 days) from initial issuance.
  Refresh tokens **may rotate** on every refresh.
- **Rate limit**: `/v2/user/info/`, `/v2/video/list/` and `/v2/video/query/` are each limited to **600 requests**
  on a **one-minute sliding window**; over the limit returns HTTP `429` with error code `rate_limit_exceeded`.

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

## 0. Pick the right portal first

Do this before anything else, because every later step is portal-specific.

- **This skill covers the consumer TikTok for Developers app** at `https://developers.tiktok.com/` — Login Kit for
  authorization, the Display API for a creator's profile and videos, and the Content Posting API for publishing.
- **Ads / marketing** → `https://business-api.tiktok.com/portal`. Register as a developer first (company-domain
  email required), then create the app under My Apps. Different auth flow, different credential names, different
  review.
- **TikTok Shop** → `https://partner.tiktokshop.com/` (separate US instance). You choose Custom App (your own or
  named sellers) vs Public App (listed on the TikTok Shop App Store), and apply for API permissions per app.

State plainly in your opening summary which portal you are working in. If the user turns out to want a different
one, stop — do not half-register in this portal "to have something".

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

A new app means a **new client key**, and every existing customer connection is bound to the old one — every
customer would have to re-authorize. On top of that a new app starts at zero approved scopes and must go through
app review again, which is days to weeks with no credentials usable against real accounts in the meantime.

Reuse the existing app for: adding a redirect URI, adding a scope, rotating a compromised secret, or diagnosing an
authorization failure. Note that the first two still require a re-review (§6) — reuse is cheaper, not free.

Register a **new** app only when the user explicitly wants one: a replacement for a compromised app, a separate app
for a separate product or brand, or a deliberate split between environments. Say which path you are taking first.

## 2. Account: sign in or sign up

- **Sign up**: `https://developers.tiktok.com/signup` — sign-in is with a TikTok account (or email/phone).
- **Sign in**: `https://developers.tiktok.com/login`
- **Create or join an organization**, then select it as the app owner at creation. TikTok describes an organization
  as highly recommended but not strictly required; for anything a company ships it is the right answer — a personal
  account means one individual's TikTok login is the single point of failure for the credentials.
- **Test accounts**: you will need real TikTok accounts to add as sandbox target users (§6). Whoever owns each
  account must log in themselves and accept the Developer Terms of Service; you cannot add an account you do not
  control. Results can take up to an hour to appear.

Hand control back to the user for anything only they can do: email/phone verification, CAPTCHA, 2FA, accepting the
Developer Terms of Service and Developer Data Sharing Agreement, and logging in each target user. 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 and
do not invent what a screen said. Hand the user an exact, ordered click path with the literal values to paste — the
redirect URIs from §4 and the scope strings from §5 — and continue once they report back with the client key.

## 3. Create the app

Portal path: **profile icon → Manage apps → Connect an app → select the owning organization → confirm.** The client
key and client secret are generated at this point.

Then fill in, in this order:

1. **Basic information** — app icon (1024×1024 px, JPEG/JPG/PNG, ≤ 5 MB), app name, category, and description. The
   description is shown to users on the authorization page, so write it for them, not for the reviewer. Reviewers
   reject generic or placeholder names and icons, names that imply TikTok is the publisher, and anything that reads
   as "internal tool" or "still in development".
2. **URLs** — Terms of Service, Privacy Policy, and Web or Desktop URL. These must be live, public, fully built
   pages on the app's real website. A landing page or a login wall is a documented rejection reason, and the ToS and
   Privacy Policy links must be visibly reachable from the site itself.
3. **Platforms** — declare Web, Android, iOS and/or Desktop. Each carries its own requirements (package name and
   signature for Android, Bundle ID for iOS, store URLs for published mobile apps). A server-side integration is
   **Web**.
4. **Add products** — click *Add products* and add what you need: **Login Kit** (required for OAuth at all), plus
   **Display API** and/or **Content Posting API**. Redirect URIs are configured per-product under Login Kit.
5. **URL properties** — verify domain ownership (recommended: a signature string in the domain's DNS records) or a
   URL prefix. Verifying a domain covers every path under it and its subdomains; a URL prefix covers only URLs with
   that exact prefix. This is a mandatory config step for apps created after the cutoff, and the Content Posting
   API's pull-from-URL transfer will only accept media from a verified property.

## 4. Redirect URIs

Register **every** callback host your platform serves. For Unified.to these are one 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
```

The documented rules, all of which bite at connect time rather than at save time:

- **Maximum 10 redirect URIs per app.** Four data centers plus a couple of test hosts already uses most of that.
- **Each URI must be under 512 characters.**
- **HTTPS only.** Plain HTTP is rejected, including for localhost.
- **Absolute paths with no query string and no fragment.** `…/callback/?id=1` and `…/callback/#100` are both
  non-compliant. Anything your platform needs to carry through the flow goes in the `state` parameter instead.
- **The `redirect_uri` you send must match a registered value exactly.** There is no subdirectory matching and no
  trailing-slash forgiveness — `…/oauth/code` and `…/oauth/code/` are different URIs. TikTok's own examples carry a
  trailing slash; Unified.to's callbacks do not. Register the form your platform actually sends.
- Mobile platforms have extra format requirements: Android needs an App Link or Deep Link, iOS a Universal Link with
  the Associated Domain capability. Irrelevant for a server-side connector, but the form will ask if you declared
  those platforms.

Adding a redirect URI to a **live** app is a change that goes back through review (§6). Get the full list in before
the first submission.

## 5. Scopes

TikTok scopes are **comma-separated** in the authorize URL — not space-separated like most OAuth2 providers. A
space-delimited scope string is a silent, confusing failure mode.

`user.info.basic` is added by default for any app with Login Kit. Everything else is added under **Add Scopes** on
the app page and **reviewed individually**. The scopes relevant to a creator-data connector:

| Scope | Grants |
| --- | --- |
| `user.info.basic` | Open ID, avatar, display name. Default with Login Kit. |
| `user.info.profile` | Bio, profile link, username, verification status |
| `user.info.stats` | Follower / following / likes / video counts |
| `video.list` | Read the user's public videos |
| `video.upload` | Upload a video to the user's drafts for them to finish posting |
| `video.publish` | Post content directly to the user's profile |

Other scope families exist and are not what a general connector wants: `research.*` (vetted-researcher programme),
`portability.*` (EEA/UK data-export flows), and `local.*` (local services / vouchers). Do not request them to "cover
future needs" — an unjustifiable scope on the form is a rejection for the whole submission.

Three things about scopes that are easy to get wrong:

- **Approval is not access.** Being approved for a scope only lets you *ask*. Each user must also grant it, and
  TikTok makes some scopes individually toggleable on the consent screen — a user can grant one and deny another.
  Your code must tolerate a token with fewer scopes than you requested, and the APIs reject fields whose scope was
  not granted rather than returning them empty.
- **Request only what the product demonstrably uses.** "Request only necessary permissions" is an explicit review
  criterion, and every requested scope must be visible in the demo video.
- **Direct posting is separately gated.** Even with `video.publish` approved, content posted by an **unaudited**
  client is restricted to private viewing. Lifting that requires a further audit of your compliance with TikTok's
  terms. Treat public posting as a second project, not a checkbox.

### Product fact — Unified.to's TikTok connector

**As of 2026-09-20, Unified.to's TikTok connector requests:**

- **Login / identity**: `user.info.basic` only. The Display API exposes no email address, so the connection identity
  is TikTok's `open_id` with no email attached.
- **Profile reads**: `user.info.basic`, `user.info.profile`, `user.info.stats`.
- **Post reads**: `video.list`.
- **No publishing scopes** — `video.publish` and `video.upload` are not requested; the connector is read-only for
  TikTok, and creating posts is out of scope for it.

Auth quirks the same configuration records: the client ID parameter is named **`client_key`** (not `client_id`) on
both the authorize and token requests; the token exchange is an **`application/x-www-form-urlencoded` POST** with
`client_key` and `client_secret` in the body; the access token is sent as a **bearer** header; and the connector has
**no shared Unified.to-provided TikTok credentials** — every workspace must supply its own client key and secret,
which is exactly why this registration has to happen per customer or per partner.

Confirm the current scope set and these quirks with the connector's owner before submitting for review — a scope
added to the connector after this date will not be on an app approved against this list.

## 6. App review — plan for it, do not discover it

This is the section that decides the timeline. Nothing below can be skipped by being clever.

**Sandbox first, and for a first-time app, sandbox is required.** Toggle to Sandbox mode next to the app name →
*Create Sandbox* → name it (optionally cloning an existing config) → configure products and apply. Up to **5
sandboxes per app**. Share it with up to **10 target users**: each person goes to Sandbox settings, clicks *Add
account*, logs into their own TikTok account and accepts the Developer Terms of Service; allow up to an hour for it
to show up. Sandboxes do **not** cover the Content Posting API for public videos or the Data Portability API. When
the sandbox works, switch to Production mode → *Draft* → *Import* and pick the sandbox — this **overwrites** the
draft's existing configuration, so import before hand-editing the draft, not after.

**What the submission asks for:**

- A **detailed written explanation of how each product and each scope is used** in your app or website. Write one
  paragraph per scope, naming the screen or feature it powers.
- **1 to 5 demo videos, max 50 MB each**, showing the complete end-to-end flow with *every* selected product and
  scope clearly demonstrated. For a first-time app the video must show the integration running in the **sandbox**.
  The domain shown in the video must match the website URL you submitted. Mobile apps must include the app opening.
- If a product or scope is not actually used, **remove it before submitting** rather than leaving it on the form.

**Timeline and statuses.** Review takes **several days to two weeks**. While **In review** the app is frozen — no
config changes; use **Recall** to withdraw if you need to fix something. Outcomes are **Live** or **Not approved**
(with reviewer comments; fix and resubmit). TikTok's guidance is that beta, incomplete, internal or test versions
will generally not be approved; an unreleased product can request an integration assessment, with no guarantee.

**After it goes live, every change is another review.** Adding a scope, adding a redirect URI, renaming the app,
changing the icon — the change does not appear in the live release until re-approved. This is the reason §4 and §5
insist on getting the complete list in before the first submission.

**Stop and ask rather than answering for the user**: anything in the review form that is a business or legal claim —
what the company does, how data is retained, compliance attestations, expected volumes, partnership status. Those
are the user's words to write, not yours.

## 7. Capture the credentials

From the app page in the developer portal, on the app's basic information: **Client key** and **Client secret**.

Capture and record:

- **Client key** — TikTok's name for the OAuth2 `client_id`. It is sent as the parameter `client_key`; a client
  library that hardcodes `client_id` will fail with an unhelpful error.
- **Client secret** — sent in the token request body, not as a Basic auth header.
- **Endpoints**: authorize `https://www.tiktok.com/v2/auth/authorize/`, token
  `https://open.tiktokapis.com/v2/oauth/token/`, API base `https://open.tiktokapis.com/v2`. The **trailing slashes
  are part of the paths** on TikTok's v2 endpoints — keep them.
- **Authorize parameters**: `client_key`, `scope` (comma-separated), `response_type=code`, `redirect_uri`, `state`.
  Optional `disable_auto_auth` (0 = skip the consent page for a valid session, 1 = always show it).
- **Token exchange**: `POST` with `Content-Type: application/x-www-form-urlencoded` carrying `client_key`,
  `client_secret`, `code`, `grant_type=authorization_code`, `redirect_uri`. `code_verifier` is required for the
  mobile and desktop flows (PKCE), not for the web flow.
- **Whether this is the sandbox or the production app**, and the app's status (Draft / In review / Live).

**On `state`.** TikTok's own guidance is to generate a random alphanumeric anti-CSRF token, store it in a cookie
with a ~60 second expiry, and verify it on the callback. Because redirect URIs cannot carry a query string (§4),
`state` is also the only place to put per-connection context.

Rotating the client secret invalidates the old one. Existing access tokens survive until they expire (up to 24 h),
but every new authorization and every refresh fails until the new secret is deployed. Never rotate without explicit
go-ahead and a cutover plan.

Report the secret once so the user can paste it into their secret store, say plainly that it is now in the
transcript and can be rotated, then move on.

## 8. Token lifetimes and refresh

| | Value | Consequence |
| --- | --- | --- |
| **Access token** | 86,400 s — **24 hours** | Every connection refreshes daily. There is no long-lived access token. |
| **Refresh token** | 31,536,000 s — **365 days**, documented as "after the initial issuance" | A connection that is never re-authorized eventually dies. |
| **Rotation** | The refresh response **may return a different `refresh_token`** | You must persist the new value whenever it differs. |

Refresh is a `POST` to the token endpoint with `client_key`, `client_secret`, `grant_type=refresh_token` and
`refresh_token`, form-encoded.

Two failure modes fall out of this table:

- **A client that ignores the returned refresh token** works on the first refresh and fails on a later one. Test the
  *second* refresh, using the token the first refresh returned (§9).
- **A client that assumes the 365-day window slides** may be wrong. TikTok documents the refresh token as valid for
  365 days **after initial issuance**; the docs do not state whether refreshing resets that clock. Treat annual
  re-authorization as the safe assumption, make sure a connection can be re-authorized without data loss, and
  confirm the behaviour with TikTok support if the answer matters to the product.

**Rate limits** to design against: `/v2/user/info/`, `/v2/video/list/` and `/v2/video/query/` are each capped at
**600 requests on a one-minute sliding window**, returning HTTP `429` with `rate_limit_exceeded` above that. The
documentation does not state whether that ceiling is per app or per user access token — assume the stricter reading
(per app) until you have measured it. Higher limits are requested through TikTok's support page.

## 9. Verify end-to-end

Sandbox success is necessary, not sufficient — a sandbox has target users and relaxed gating that production does
not. Verify in this order:

1. **In the sandbox**, with a target user account, run the real authorize → callback → token exchange through your
   platform's connect flow. Confirm the scopes actually granted match the scopes requested.
2. **After the app is Live**, repeat with a TikTok account that is *not* a target user and not the developer.
3. Confirm the token response carries a **refresh token** alongside the access token.
4. Force a **refresh**, then force a **second** refresh using the refresh token returned by the first. That is what
   catches a client that ignores rotation.
5. Make one real read call per approved scope, to confirm the scope grant does what you expect — a granted-but-
   unused scope on the review form is also a rejection risk on the next submission.

| Symptom | Cause |
| --- | --- |
| Authorization page errors immediately, or callback carries `error` / `error_description` | `redirect_uri` does not match a registered value exactly, or the user is not eligible for third-party authorization (§4) |
| "Invalid client" / unrecognised client at token exchange | Sent `client_id` instead of `client_key`, or sandbox credentials against production (§7) |
| Scope errors, or the authorize page shows fewer permissions than asked for | Scope string was space-separated instead of comma-separated, or the scope is not approved for this app (§5) |
| Authorize works but an API field comes back missing | The user toggled that scope off at consent; the API rejects fields whose scope was not granted (§5) |
| Works for the developer's own account, fails for everyone else | Still in sandbox — target users only; the app is not Live (§6) |
| Everything worked yesterday, all calls 401 today | Access token expired at 24 h and the refresh did not run (§8) |
| First refresh fine, a later one fails | Client is not persisting the rotated refresh token (§8) |
| Connection dies after a long quiet period | Refresh token hit the 365-day limit; customer must re-authorize (§8) |
| HTTP `429` with `rate_limit_exceeded` | 600 requests/minute per Display endpoint (§8) |
| Posted videos are visible only to the poster | Unaudited client restriction on the Content Posting API (§5) |
| Credentials simply do not authenticate against the API you are calling | Wrong portal — ads or Shop credentials against the consumer API, or vice versa (§0) |

## 10. Hand off — never commit the secret

- **Do not** write the client 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.
- If a code change is needed (a callback host, a scope, comma-delimited scope joining, rotation-aware refresh
  storage), keep it secret-free and say what the human must set out of band.
- Close with: which **portal** the app lives in and the app name; the owning **organization**; the **client key**;
  where the secret was delivered; the authorize, token and API base URLs; the **exact scope strings** requested and
  which are approved; the app's **status** (Draft / In review / Live) and, if in review, when it was submitted; the
  sandbox name and target users used for testing; the token lifetimes and the rotation requirement; and anything
  left for the user to do.

## Stop and ask

Hand back to a human rather than guessing when:

- It is unclear **which TikTok portal** the user actually needs (§0) — registering in the wrong one wastes a review
  cycle and produces credentials that never work.
- The review form asks for **business, legal or compliance claims**: what the company does, data retention,
  attestations, volume projections, partnership status.
- The product needs a **website, Terms of Service or Privacy Policy that does not exist yet** — review rejects
  landing pages and login walls, and you cannot write the company's legal pages.
- A **demo video** is needed: someone has to record a real end-to-end walkthrough, and it must match the submitted
  domain.
- The request is to add a scope or redirect URI to a **live** app — that is a re-review, with days to weeks of lead
  time, and the user needs to know before you submit.
- **Public direct posting** is wanted: that needs the separate unaudited-client audit (§5).
- The app is **In review** and someone wants a change — recalling the submission restarts the clock.
- Registering the app would mean **logging in as a person who is not in this conversation**, or adding a target user
  account you do not control.
- The portal does not match the **Platform state** section above.

## References

Verified 2026-09-20; every link resolved.

- TikTok for Developers home — https://developers.tiktok.com/
- Sign up — https://developers.tiktok.com/signup
- Sign in — https://developers.tiktok.com/login
- Register your app — https://developers.tiktok.com/doc/getting-started-create-an-app
- App review guidelines — https://developers.tiktok.com/docs/en/app-review-guidelines
- App review FAQ (turnaround, re-review after going live) — https://developers.tiktok.com/docs/en/getting-started-faq
- Add a sandbox — https://developers.tiktok.com/docs/en/add-a-sandbox
- Introducing sandbox mode (blog) — https://developers.tiktok.com/blog/introducing-sandbox
- Scopes overview — https://developers.tiktok.com/docs/en/scopes-overview
- Scopes reference (exact strings) — https://developers.tiktok.com/doc/tiktok-api-scopes
- Login Kit overview — https://developers.tiktok.com/doc/login-kit-overview
- Login Kit for Web (authorize URL, redirect URI rules, state) — https://developers.tiktok.com/doc/login-kit-web
- Login Kit for Desktop (PKCE flow) — https://developers.tiktok.com/doc/login-kit-desktop
- Manage user access tokens — https://developers.tiktok.com/doc/login-kit-manage-user-access-tokens
- User access token management (lifetimes, refresh, rotation) — https://developers.tiktok.com/doc/oauth-user-access-token-management
- Display API overview — https://developers.tiktok.com/doc/display-api-overview
- Content Posting API — get started (unaudited client restriction) — https://developers.tiktok.com/doc/content-posting-api-get-started
- Content Posting API — media transfer / URL ownership verification — https://developers.tiktok.com/doc/content-posting-api-media-transfer-guide
- Rate limits — https://developers.tiktok.com/doc/tiktok-api-v2-rate-limit
- Developer guidelines — https://developers.tiktok.com/docs/en/our-guidelines-developer-guidelines
- Developer changelog — https://developers.tiktok.com/docs/en/changelog
- Products overview — https://developers.tiktok.com/doc/overview
- **Ads/marketing portal** — https://business-api.tiktok.com/portal
- Register as a developer (Business API) — https://business-api.tiktok.com/portal/docs/register-as-a-developer/v1.3
- Create a developer app (Business API) — https://business-api.tiktok.com/portal/docs/create-a-developer-app/v1.3
- **TikTok Shop Partner Center** — https://partner.tiktokshop.com/
- Create an app (TikTok Shop) — https://partner.tiktokshop.com/docv2/page/create-your-app