Douyin Laike × Feishu (Lark) Lead Sync

A medical aesthetics chain Delivered 2026.02 – 2026.03 Stable in long-term operation

Leads used to take a full day to get from the ad backend to the ops team; now they arrive within minutes. Along the way, a batch of 22 silent failures taught us a hard lesson — since then, any failure in this pipeline gets noticed, no exceptions.

The business problem

The company runs ads on Douyin (TikTok's Chinese sibling) to acquire customers, and the leads land in the Douyin Laike backend. But the ops team's workspace is Lark Base (Feishu's Airtable-style database). Every day meant manual export, paste, and cross-checking — slow, error-prone, and impossible to tie back to ad spend to calculate ROI.

The approach

A fully automated data pipeline: pull leads from the Douyin Open Platform API → decrypt → link to ad spend data → write into Lark Base → scheduled incremental sync + failure monitoring. From then on, the ops team only had to watch one interface: Feishu.

Platform-side leads Phone # encrypted Scheduled sync job Minute-level Decrypt + link ad data Restore source & spend Collab table Sales follow up Failure alerts Any step's failure alerts a human — no silent lost leads. Delay dropped from "days" to minutes
The whole pipeline does one thing: let sales see leads worth calling within minutes, and make sure any failure is always noticed.

Unglamorous but real gotchas

The hard part of these "data integration" projects is always hiding in the details:

  • Decrypting encrypted phone numbers — Douyin encrypts lead phone numbers, so you need to get the key handling and decryption flow exactly right
  • Two layers of IP whitelisting — the open platform and the app each have their own whitelist; missing one layer causes silent API failures
  • Feishu field type traps — date, formula, and select fields all have their own format constraints; get the type wrong and there's no error, just bad data
  • "Fake success" — the Feishu API can return success while the data actually never got written, so you have to read it back and verify
This project taught me an iron rule: "looks like it's running" is not the same as "is actually working." After launch, I found the scheduled job had silently failed 22 times with zero alerts. Since then, every automated task must have observable metrics and failure alerts — a silent success and a silent failure look identical from the outside.

The result

It's been running stably in the long term since launch. Lead delay from the ad backend to the ops workspace dropped from "days" to minutes, and for the first time, ad spend data and in-store conversion could be reconciled in a single table.

This kind of project isn't glamorous, but it's exactly what real business need actually looks like: not "bolt on some AI," but connect the data, eliminate the repetitive labor, and let people focus on the work that's actually worth their attention.

Related retrospective: "My cron job silently failed 22 times before I understood what 'looks like it's running' really means"