Disconnecting shops

A TikTok Shop connection is the relationship between a local customer account in your system and a TikTok Shop seller authorization. This guide covers the disconnect stage of the lifecycle. Read it together with:

• Connecting shops
• Reauthorize shops
• Seller deauthorization webhook

Lifecycle overview:

Connect shop -> Store tokens and shop identifiers -> Refresh or reauthorize before expiration -> Disconnect locally or handle TikTok-side deauthorization -> Reconnect if access is needed again

Use this page for two different scenarios:

Do not treat these scenarios as the same event. A customer can disconnect a shop in your product without revoking the app authorization in TikTok Shop. A seller can also revoke authorization in TikTok Shop without clicking anything in your product.

The current OpenAPI reference does not list a public endpoint for a developer to revoke a seller's authorization or invalidate the seller's token on the platform side. The authorization APIs listed in the current reference include authorized-shop lookup and related authorization utilities, but not a revoke or unlink endpoint. Therefore:

• Deleting access_token and refresh_token from your system is a local disconnect action. It prevents your application from continuing to use the connection.
• Local deletion does not necessarily remove the authorization record from TikTok Shop.
• If the customer wants to revoke the app authorization in TikTok Shop, direct them to the TikTok Shop authorization management area for their account.
• If TikTok Shop later provides a revoke or unlink endpoint, add that endpoint to this guide and call it before deleting local credentials.

In this use case, the customer asks to disconnect one or more TikTok Shops from your application or connector. Image Recommended flow:

1. Authenticate the customer and confirm which TikTok Shop connection should be disconnected.
2. Identify the local connection record by your customer identifier and the TikTok Shop identifier, such as shop_id, shop_cipher, or the composite key used by your data model.
3. Mark the connection as disconnecting or inactive so background jobs stop using it.
4. Stop scheduled sync jobs, webhook processing, retries, queue consumers, and API polling for that shop.
5. Delete or deactivate the stored access_token, refresh_token, token expiration timestamps, and token-derived secrets from secret storage, caches, logs, and job payloads.
6. Delete, anonymize, or retain customer and shop data according to your documented data retention policy and applicable law.
7. Show the customer that the shop is disconnected in your product.
8. If the customer wants to connect the shop again later, route them through the Seller authorization flow as a new authorization. Do not reuse old tokens.

TikTok-side deauthorization happens when the seller revokes your app authorization in TikTok Shop or the authorization is no longer valid. Your system should listen for the SELLER_DEAUTHORIZATION webhook and treat it as the primary signal that access has ended. When SELLER_DEAUTHORIZATION is received:

1. Validate the webhook request and event type.
2. Map the event to the local customer and shop connection using the identifiers in the payload, such as shop_id or the shop mapping you store locally. Refer to the Seller deauthorization webhook page for the exact payload.
3. Mark the connection as deauthorized or inactive.
4. Stop API calls, scheduled jobs, retries, and webhook-driven processing for that shop.
5. Delete or deactivate stored credentials and token-derived secrets.
6. Notify the customer that the TikTok Shop authorization was revoked and provide a reconnect action if access is still required.

Your listener should be idempotent. If the same deauthorization event is delivered more than once, update the same connection state instead of creating duplicate disconnect records.

You can configure the webhook in Partner Center or by API. Partner Center path:

Partner Center
  -> App & Service
  -> Select your app or service
  -> Webhooks / Event subscriptions
  -> Add or update SELLER_DEAUTHORIZATION

Console labels may vary by Partner Center version. The important part is that the event topic is SELLER_DEAUTHORIZATION and the callback URL is your HTTPS webhook listener. API configuration uses Update Shop Webhook:

PUT https://open-api.tiktokglobalshop.com/event/202309/webhooks?app_key={app_key}&timestamp={timestamp}&sign={sign}&shop_cipher={shop_cipher}
Content-Type: application/json
x-tts-access-token: {access_token}

{
  "address": "https://example.com/tiktok-shop/webhooks",
  "event_type": "SELLER_DEAUTHORIZATION"
}

Notes:

• address is the HTTPS endpoint that receives the webhook event.
• event_type must be SELLER_DEAUTHORIZATION.
• x-tts-access-token is required by the webhook configuration API.
• shop_cipher is optional in the OpenAPI schema, but cross-border shops may require the correct value to avoid incorrect responses. Follow the endpoint reference for the shop and market you are configuring.
• Use Get Shop Webhooks to verify existing webhook configuration.
• Use DELETE /event/202309/webhooks only if you intentionally want to remove a webhook event subscription. Do not delete the deauthorization webhook as part of ordinary shop disconnect logic unless you no longer need to receive the event for that shop.

Clean up data based on the scenario and the legal basis for retaining it.

At minimum, deactivate local API access immediately after disconnect or deauthorization so your system stops using the credentials. For stored customer data:

• Follow your published privacy policy, seller agreement, applicable law, and TikTok Shop platform requirements.
• For GDPR-covered personal data, apply data minimization and erasure obligations where applicable. See the European Commission's data protection overview.
• Define an internal deletion SLA before launch. A practical default is to delete or anonymize data that is no longer needed within 30 days after disconnect, unless a shorter period is required by law, platform policy, or your agreement with the customer.
• If you must retain limited records for tax, invoicing, fraud prevention, security, or legal defense, retain only the minimum fields needed and block them from operational API use.

If the customer wants to reconnect the shop, use the same Seller authorization flow as a first-time connection:

1. Send the customer to the appropriate Seller authorization entry point.
2. Receive a new authorization code at your callback URL.
3. Exchange the code for a new access_token and refresh_token.
4. Call Get Authorized Shops to refresh shop identifiers, including shop_id and shop_cipher.
5. Store the new token response, granted_scopes, and shop metadata against the local customer connection.
6. Restart only the jobs and integrations that the customer has enabled.

Never reactivate a disconnected connection by reusing old tokens.

For lower cross-page jumping, the shop connection docs can be organized as one lifecycle guide:

Until the lifecycle guide is consolidated, keep cross-links between the three pages so developers can move from connect to reauthorize to disconnect without guessing which page owns each state transition.