Webhook Egress IP Update

Tag: Action required ·

• Change type: no change to the webhook contract
• Effective date: 2026.8.30
• What changed: new egress (source) IP ranges are being added to the infrastructure that delivers TikTok Shop webhooks.
• Who must act: apps whose webhook endpoint only accepts inbound traffic from an allowlist of TikTok Shop source IPs.
• If you do nothing: webhooks sent from the new IPs are dropped by your own firewall, so you silently miss events — no error is returned to you.
• Not affected: payloads, event types, headers, signature verification, retry behavior, and all webhook subscription APIs are unchanged.

Summary

TikTok Shop is adding new egress IP ranges to the infrastructure that sends webhook notifications to your endpoint. All previously published egress IPs remain valid — the entries below are additions, not replacements. If your webhook endpoint sits behind a firewall, WAF, security group, load balancer, API gateway, or reverse proxy that filters inbound traffic by source IP, add the new ranges before the effective date. This is a network configuration change; no application code change is required.

Impact

Newly added egress IP ranges

Full webhook egress IP allowlist after this update

Use this as the complete list when configuring your allowlist. Entries marked New are the additions introduced by this update.

Allowlist by CIDR wherever a CIDR block is published. Do not allowlist only the individual addresses you have observed in your traffic logs — any address inside a published range may be used. Webhook traffic for a shop is sent from the region serving that shop's market, so if your app serves shops in several markets, allowlist every region you operate in. When in doubt, allowlist the full list above.

Is this a breaking change?

Not a breaking change to the webhook contract, but action is required for apps that filter by source IP.

• Payload and contract: unchanged. No webhook field, event type, header or signature scheme is added, removed or modified.
• Authorization: unchanged. No new permission scope, no re-authorization.
• Delivery: impacted for IP-allowlisting apps. Requests from the new ranges are blocked by your own infrastructure rather than rejected by TikTok Shop, so there is no error signal on either side — only missing events.

Developer action items

• If your endpoint accepts webhook traffic from any IP (no firewall, WAF or gateway allowlist): no action is required.
• If you enforce an inbound source-IP allowlist: add every range in the full allowlist table to your firewall, WAF, security group, load balancer, API gateway and reverse proxy rules before the effective date. Add CIDR blocks as CIDR, not as individual addresses.
• If your network rules are managed by a cloud provider or hosting vendor: forward this notice to whoever owns those rules — the change sits at the network layer, not in your application code.
• After updating: verify delivery instead of assuming success. Confirm that you still receive events for every market you serve, and check your firewall drop logs for denied requests from the new ranges.
• Recommended hardening: treat webhook signature verification as your primary authenticity check and IP allowlisting as defense in depth. Signature verification is unaffected by infrastructure IP changes.

Questions or delivery issues after updating your allowlist: contact TikTok Shop developer support at support-us@tiktok.com.