TikTok Hub

Fix the whole catalog at once

The dashboard scans every listing and derives its issues: missing brand, missing size chart, missing attributes, no highlights, unanswered compliance questions, a rejected audit. It rolls those into a health grade you can sort and filter by. That is diagnosis, and it is cheap. The useful half is that the fixes run across the whole catalog at once.

Brand resolution is the clearest example. It reads the first token of each title, matches it against TikTok's own brand directory, and queues the fix for every listing missing one. Two details make it usable: lookups are cached per token, so forty listings starting with the same word cost one lookup, and anything already in the change queue is skipped, so a second run adds nothing twice. That matters because the honest outcome of a bulk pass is that you run it again next week.

Five fixes per listing, each fail-closed

Per listing, fix all runs brand, highlights, attributes, size chart, and compliance. Each sub-fix is fail-closed on its own and reports why it skipped: a size chart is only picked from templates that already exist, compliance is answered from the operator's stored policy, and every suggested attribute is re-validated against TikTok's enumerated values for that category before it survives. One refusing leaves the others running. Images are left out on purpose, because nothing here can source a real product photo, and a placeholder would do more harm than the gap.

Every write goes through one gate

Bulk is where a small mistake becomes a large one, so nothing applies directly. Every fix lands in a change queue you preview first, and there is one way for the system to alter the live shop: a single guard that performs the action after every check passes, and only when dry run is off.

The guards run in a fixed order: a fail-closed preflight, then locked SKUs, then the margin floor, then idempotency, and they run before the dry-run gate, so a dry run still reports what would have been rejected. A bulk action added later inherits every guard, because there is no second door.

Scope guards as well as value guards

The obvious checks are about values: is this price sane, is this discount within bounds. The checks that prevent the expensive mistakes are about scope. This shop is US-local only, and the marketplace exposes a parallel set of cross-border endpoints that look almost identical. Calling the wrong family would push changes into markets the business does not operate in. So the boundary is enforced in the tool: local endpoints only, cross-border unreachable. Blast radius is capped by construction.

Flash promotions, where the risk concentrates

Routine repricing moves one number. A flash promotion moves hundreds at once, on a timer, usually while nobody is watching. So the affected set is resolved and shown before anything is scheduled, every deal price is floor-checked per variant, and the batch runs through the same gate as a single edit.

One failure the marketplace imposes is worth naming: it rejects a deal price if that SKU sold lower in the last thirty days, without saying what that price was. The tool reads the rejection, works out a floor percentage that clears it, and offers to re-run without the blocked items, because a bare failure message is no help at eleven at night.

What this pattern is for

Most internal tools eventually write somewhere that matters: a storefront, a ledger, a customer record, a payroll run. The moment they do it in bulk, the engineering question becomes what stops the tool from doing damage. The answer that keeps working: a single choke point every write must pass, a dry run in front of it, a review queue between intent and action, and an explicit restriction on scope. None of that is specific to TikTok or to pricing. It is the shape I give any tool before it is allowed near production.