Data sourcing & compliance
How LinkDigest reads public posts
What the reader does on each platform, what it keeps, and what happens when a platform says no — written from the code on 9 November 2026. Where a route uses a residential exit or a cookie, this page says so. We have no data agreement with any of these platforms: a route can close at any time, and /platforms shows when each one last read a post in full.
The short version
Five rules the code keeps
- Public posts only, one link at a time. A profile, live room or collection link is refused.
- No platform login. A customer’s cookies or password are never asked for and never accepted.
- No captcha is answered. When a platform walls or refuses, the read stops with a named error_code and costs nothing.
- Media is deleted before the request returns. Text is what we keep.
- Comments are only the first few the post’s public share page serves with it — never the whole thread.
Per platform
How each platform is opened
| Douyin (抖音) | Douyin's embed player (open.douyin.com/player/video) — the page Douyin publishes for other sites to show a post — opened in a headless Chromium with an empty cookie jar; the page requests the post itself. When the player does not return the post, the read ends as platform_refused, not charged, with the upload and extension routes. Until 9 November 2026 the engine then tried Douyin's web API with a registered visitor session (ttwid), a generated browser fingerprint (s_v_web_id, UIFID) and residential exits; Douyin's security layer had refused it since 9 October 2026, and we switched it off as a way around that layer. No Douyin cookie and no exit is used now. |
| Xiaohongshu (RedNote, 小红书) | The note's public share page, the one a logged-out phone is shown. When the note does not come back to our own address — usually Xiaohongshu's captcha or login screen — the same public note page on rednote.com is requested through residential exits for at most 40 seconds (a link without its share token, only when a wall stopped it). An exit that met the wall is rested for 10 minutes, and reads leave any one address at least 2 seconds apart. When Xiaohongshu says the note itself cannot be viewed, no exit is tried. The captcha is never answered: if every exit is walled, the read stops and says so. |
| Bilibili (B站) | Bilibili's embed player (player.bilibili.com) in a headless Chromium with an empty cookie jar. Bilibili answers our cloud address with -412 “request was banned”, so the player page is opened through a residential exit first (up to two), then from our own address; the stream is downloaded directly, through that exit only if the direct download is refused. |
| Weibo (微博) | The post's page on m.weibo.cn in a headless browser. Weibo itself gives a logged-out browser a guest visitor session; nothing is kept after the read. A post only signed-in followers can see (关注可见) is refused. |
| Photo posts through Instagram's embed page (/embed/captioned/) in a headless browser, which shows only a carousel's first slide; reels and video posts through yt-dlp. | |
| YouTube | Google's Gemini model reads the video on Google's side, through OpenRouter. The watch page is fetched for the description and date with one cookie: the consent choice, set to “reject all”. |
| TikTok, X, podcasts, WeChat articles, web pages | Public pages and the platforms' own public endpoints: yt-dlp, oEmbed, X's embed syndication endpoint, 小宇宙's public episode page, Apple Podcasts' feed. No login. |
Post pages are requested with an ordinary desktop Chrome User-Agent or from a real headless Chromium, because most platforms show public posts only to browsers. Our own side lookups — search-box suggestions, the free link resolver, wiki APIs and webhooks — name LinkDigest in their User-Agent, for example LinkDigest/1.0 (+https://linkdigest.dev). Search-box suggestions are at most 12 requests a topic, cached for a day, and a refusal is skipped, never retried in disguise.
When a platform says no
A named answer, never a charge
| platform_refused | 503 + Retry-After | The platform's security layer refused automated reads. Not your link, not charged. how_to_read_now names the routes that still work (upload the saved file, or the extension), and a key's link (Douyin excepted) is kept for up to seven days and read once the platform allows it. |
| not_served | 422 | The platform would not serve this one post through the surface we read, without saying it is gone (Douyin's player: core_dep). Final for that link, not charged. |
| 422 (no code) | 422 | Removed, private, login-walled, or not a post: a profile page, live room, music page or collection is refused with what to paste instead. Not charged. |
| media_too_long | 402 | Longer than the plan reads. Nothing was read, nothing charged. |
Credits are written only when a read finishes, so a refused read leaves nothing to refund. Field-level detail is in the docs.
Your own browser
Upload and the extension
Upload (/app/upload): the file you saved from the app is turned into 16 kHz audio and a few frames on your own device; only those reach us. The extension has no access to any page until you press its button, then records only what that tab plays — its sound and a frame every few seconds, up to 10 minutes. Its “Digest the notes on this page” button collects up to 50 note links the page is showing you (it scrolls a few screens only if you ask), clicks nothing and never touches your login. A recording’s digest belongs to your account alone: it is not cached for anyone else.
Retention
What is stored, and for how long
- Video, audio, images: never stored. A temporary folder per read, deleted before the request returns.
- Digest text: cached by link for 30 days (1 hour for a result that read too little), and served to anyone who asks for the same public link.
- Public library: a complete read of a public post made in the console or without a key — never an API, MCP or batch read — with at least 3 key points becomes a page at /d/… for up to 365 days: the key points with their checked quotes, the hook, the top comments, on-screen highlights and a 300-character transcript excerpt, with the original linked. To have one taken down, tell us at /app/feedback.
- Your account: email, a hash of each API key, and a record of each read (the link, the time, the credits) until you ask for deletion; batches 7 days; a link waiting for a platform up to 7 days; page-view counts with no visitor identifier 180 days; IP addresses a few hours, for rate limits.
Deletion: email privacy@linkdigest.dev and the account, its keys, reads, events, batches, watches, feedback and radar runs are erased. Cached digests of public links carry no identity and remain. The full list is on /privacy; acceptable use is on /terms.
Volume
Built to read links, not to harvest
One engine instance reads a handful of posts at a time (two as of 9 November 2026). Each account is held to 60 API requests an hour (300 on Studio), batches to 200 links at most, and a 24-hour ceiling on model spend across all accounts stops new reads when it is reached. Content goes to model providers through OpenRouter (speech, vision, text), searches through a web search API, payments through Stripe, mail through Resend; everything runs on AWS.
Questions
Asked before integrating
Does LinkDigest use cookies or log in to platforms?
No reader signs in to any platform, and LinkDigest never asks for or accepts a customer's cookies or password. Readers start from an empty cookie jar; a page may set its own visitor cookies while it loads, as it does for any browser. One exception, named: YouTube's consent cookie set to “reject all”. (A Douyin fallback that sent a registered visitor session and a generated fingerprint was switched off on 9 November 2026.)
Does LinkDigest use proxies?
Yes, residential exits from a paid provider, for two things only: the Bilibili player and its stream, and a Xiaohongshu note that does not come back to our own address. Douyin used them too, in a fallback switched off on 9 November 2026. Everything else is read directly from our servers on AWS. A captcha is never answered through an exit or anywhere else.
Can I get a creator's whole account, or a platform's data in bulk?
No. Each read is one post from one link; a profile link is refused. The search API returns at most 10 posts a query, from what a web search API has indexed (YouTube: its public search) — never Xiaohongshu's or Douyin's own search. A batch holds 10 links on the free plan, 50 on Dev and 200 on Studio. We do not sell data sets of posts.
Is the media stored?
No. Video, audio and images are written to a temporary folder while a read runs and deleted before the request returns. What is kept is text: the transcript, on-screen text, image descriptions and the digest built from them.
中文版：数据来源与合规.