For the US Market: Masking Recipient Phone Number and Address for 4PL Orders

Tentative launch timing: Mid-August 2026 Markets: US Scope: 4PL orders (TikTok-managed shipping) Audience: Apps that read order data from the Order APIs

Overview

TikTok Shop plans to mask the recipient phone number and detailed shipping address for 4PL orders in the US market. The change is tentatively scheduled for mid-August 2026. The exact effective date will be announced before rollout. The change will apply across all order statuses and affect data returned by the Order APIs. This update strengthens buyer data protection by limiting access to buyer contact details that are not needed to fulfill a 4PL order, where TikTok arranges last-mile delivery. If your app reads recipient data from the Order APIs for US sellers, review your integration before the effective date and update only the workflows that depend on unmasked recipient values.

What is changing

For 4PL orders in the US, the recipient_address object returns masked values for buyer-identifying fields in every order status. Today, these fields become visible once an order is ready for fulfillment (for example, AWAITING_SHIPMENT); after this change, they stay masked throughout the order lifecycle. This is a behavior change, not a schema change. The fields remain in the response, but their values are redacted. Coarse location data and the postal code remain available, so regional-level operations continue to work.

Fields that will be masked

Fields that remain available

Recipient data by order status

The table shows when phone_number and the detailed address fields are visible for 4PL orders, before and after this change.

Note: Orders in UNPAID, ON_HOLD, and CANCELLED already mask these fields today and are unchanged. The newly masked statuses are the active fulfillment statuses, where recipient data was previously visible.

How to identify affected orders

4PL orders use TikTok-managed shipping, where the seller obtains the shipping label from TikTok. In the Order APIs, identify these orders by the shipping_type field.

This change applies to US orders only. Orders fulfilled by TikTok (FBT) already mask these fields.

How to integrate

This change will apply automatically on the effective date. No API version upgrade or Partner Center declaration is required. Complete the readiness checklist before the effective date and update any workflow that depends on unmasked recipient values.

Step 1: Identify US 4PL orders

Filter for US orders where shipping_type is TIKTOK. Detailed recipient data is not required to fulfill these orders, because TikTok arranges last-mile delivery.

Step 2: Update your data handling

• Stop using phone_number, name, address_detail, address_line1, address_line2, and full_address to contact buyers or generate labels for these orders.
• Use postal_code and the district_info levels L0–L2 where you need regional routing or reporting.
• Treat masked fields as opaque. Do not parse or validate their contents.

Step 3: Test your integration

Validate that your app and downstream systems — label printing, CRM sync, analytics — handle masked recipient fields without errors for US 4PL orders.

Developer readiness checklist

Complete these checks before the effective date. Code changes are required only if your app or a downstream system depends on unmasked recipient values.

• [ ] For 4PL orders, do not parse, validate, or require masked recipient fields to import, review, or fulfill an order.
• [ ] Treat masked values as opaque. Do not depend on a specific placeholder, character count, or number of asterisks.
• [ ] Use the Recipient address update webhook (type = 3) as the address-change signal. Do not infer an address change by comparing protected field values across Order API pulls.
• [ ] Confirm that an existing order changing from unmasked to masked values does not trigger manual review, duplicate synchronization, or a customer-data update.
• [ ] Confirm that database, CRM, customer matching, label, warehouse, export, reporting, and notification workflows accept masked values.
• [ ] Do not display previously cached plaintext after TikTok Shop returns masked values.
• [ ] Test new and existing US TikTok Shipping orders. 3PL orders as the unaffected control group.

Integration patterns to avoid

Affected APIs

Timeline and enforcement

Impact if you do not adapt

Starting on the effective date, for US 4PL orders:

• Masked field values — phone_number, name, and the detailed address fields return redacted placeholders. Apps that use these values to contact buyers or print labels no longer receive usable data.
• Parsing failures — Apps with strict validation on these fields may error if they do not expect masked values.

FAQ

Q: How do I identify a 4PL order? A: 4PL orders use TikTok-managed shipping. In the Order APIs, shipping_type is TIKTOK. Seller-arranged (3PL) orders have shipping_type of SELLER and are not affected. Q: Does this affect 3PL or FBT orders? A: No. Only 4PL orders in the US are in scope. 3PL phone numbers remain visible, and FBT phone numbers are already masked. Q: Will the recipient_address fields be removed from the response? A: No. The fields remain in the response schema; only their values are masked. Keep your parsing structure and change only how you use the values. Q: What does a masked value look like? A: Masked fields return a redacted placeholder instead of the real value. Treat them as opaque and do not parse them. Q: Can I still fulfill 4PL orders without the phone number and detailed address? A: Yes. TikTok arranges last-mile delivery for 4PL orders, so detailed recipient contact data is not needed to ship them. Q: Does every app need to change its code? A: No. Every app that reads recipient data for US orders should complete the readiness checklist. Code changes are required only if the app or a downstream system depends on unmasked values. Q: How should my app detect a recipient address change? A: Use the Recipient address update webhook (type = 3) as the business signal. Scheduled Order API pulls can support general reconciliation, but your app must not infer an address change by comparing protected recipient field values.