Fiitx can deduplicate TikTok Shop creator candidates, verify platform invitation status, and prepare a review list separating eligible, already invited and unconfirmed creators. After approval it uses that list without adding unapproved replacements. Platform responses determine delivery success; account permissions and platform restrictions still apply.
Synthetic fixtures processed by Fiitx's existing calculation modules. These are not client records, delivery footage or measured time savings; only the rules listed below are verified.
Example verified:
| Creator handle | Verified status | Next action | Delivery status |
|---|---|---|---|
| demo_alpha | Eligible | Await approval | Not sent |
| demo_beta | Already invited | Exclude | Not sent |
| demo_unknown | Unconfirmed | Manual review | Not sent |
People changed, sheets changed, someone sent invites by hand in the back office. The local record only covers part of the history, so deduping against it alone guarantees repeats.
Category, follower count and average order value are partly platform filters and partly human judgement. When the two disagree, the shortlist contains people who do not actually qualify.
An operator wants to see the list before it goes out, but by the time they come back the run has drifted — the list has been recomputed, or people were topped up to fill the quota.
Category, creator tier and metric thresholds are fixed as parameters, so every round runs the same way and nothing deforms when someone else takes over.
The second one is the one that matters — confirming 'not yet invited' inside the platform's own filter. Only what is still findable there counts as genuinely un-invited; a local ledger cannot cover it.
The preview carries the criteria each creator matched and the dedupe evidence, so you can see why these people and not others.
Once approved, the list is pinned. If someone becomes unavailable the round simply sends one fewer. It will never quietly add the next candidate, because that means sending to someone you never reviewed.
Actual results are written back to the ledger, which is what makes the first dedupe pass accurate next round.
Where an open API exists it is used. Where it does not, a real browser carries your existing signed-in session and takes the same path a person would. Both routes pass through the same approval gate.
Qualification is a parameter and filtering is finished before the preview, so the list you see is the list that goes out. Combined with never topping up after approval, the list cannot be silently swapped.
A cap you set. It will not relax criteria to fill that cap — it would rather send fewer this round than send to someone who does not qualify.