Link in Bio Scraper and Newsletter Detector

🔗 What can Link in Bio Scraper and Newsletter Detector do?

Follows a creator's link-in-bio page and website. One flat row with every outbound link, other social profiles, the link-in-bio service, the creator's own website, newsletter status and platform, what they sell, brand deal and discount code signals, and manager contact. Each classification carries its evidence URL, so a weak call is visible rather than silent.

📦 What you get	⚙️ Features and integrations
📰 Newsletter status, four classes, each with its evidence URL 🛍️ What they sell, course, coaching, digital product, merch, membership 🔗 Every outbound link, other social profiles, own website 📧 Manager and business email with the page it came from 🧾 59 flat fields, snake_case, the suite's shared row	🌐 Linktree, Stan Store, linkin.bio, and the creator's own site 🖥️ Headless render for pages that return an empty shell, opt in 🤖 AI check on your own key, opt in, never ours 🏢 Agency match against 143 agencies, opt in ⬇️ Export to JSON, CSV, Excel, HTML or XML

Bought by newsletter and email platforms selling to creators, course and membership tools, brand partnership teams checking what a creator already sells, and talent teams looking for the manager email.

🚫 This is not a link-in-bio page builder or a mass page crawler. It reads the pages a creator owns, starting from the bio link, and returns one classified row. Pages that are not the creator's (an affiliate storefront, a brand's site) are listed in outbound_links_json and never used as evidence.

💡 Why use Link in Bio Scraper and Newsletter Detector?

If you sell	Read these fields
Newsletter or email platforms	newsletter_status, newsletter_platform, newsletter_evidence_url
Course, coaching, or membership tools	sells_course, sells_coaching, sells_membership
Commerce, merch, or digital product tools	sells_digital_product, sells_merch, discount_codes_visible
Brand partnerships	brand_deals_visible, outbound_links_json, own_website
Talent representation	manager_email, manager_source_url, agency_name
Anything, as a disqualifier	row_status, newsletter_check_method, link_in_bio_platform

🧭 Four classes, and an evidence URL on every one

newsletter_status	Means
has_newsletter	A Substack, beehiiv, Ghost, or Buttondown publication of the creator's; or an email platform link or an owned page that names a newsletter, a weekly email, an email list, or a Subscribe navigation item.
email_capture_only	An email platform form or an email input with list wording, but no newsletter named.
none	Nothing found on readable owned pages.
unknown_fetch_failed	No bio link page rendered readable text. Turn on render_unreadable_pages for these.

A signal counts only from a page judged to belong to the creator: the link-in-bio page, a domain sharing a name token with the handle or display name, a newsletter platform page whose identity shares a token, or a single non affiliate bio link. newsletter_evidence_url is the page or link that decided it.

Sells flags come from link text and owned page text (course, coaching, digital product, merch, membership) plus affiliate and ambassador wording (brand_deals_visible) and discount code wording (discount_codes_visible). Manager contact is an email labeled management, mgmt, managed by, manager, or booking in the bio, on a link page, or on the website, with manager_source_url.

📏 Accuracy

The pre-research rule classifier measured 5 errors in 30 (17%) on a hand spot check. The same 30 rows on this build measured 0 errors in 30 on 2026-09-21, and two runs over them on 2026-09-22 returned the same status, platform, and evidence URL on every row. Three of the 30 drove rule 7 (cadence wording, footer only headings, email platform paths named /newsletter), so they are in sample; before that rule the build measured 3 errors in 30 (10%). Residual errors run in both directions, which is why every row carries its evidence URL.

📋 What data can Link in Bio Scraper and Newsletter Detector extract?

59 fields per row, the same 59 in the same order on every actor in this suite. The ones this actor fills:

Field	What it holds
link_in_bio_platform	linktr.ee, stan.store, linkin.bio, and so on, when the bio link is a link-in-bio service
outbound_links_json, other_social_profiles_json, own_website	Every outbound link on the pages read (capped at 100), the other social profiles found, and the creator's own site
website_is_host_page	true when the only site found sits on a hosting platform (a podcast host such as Buzzsprout or RSS.com, a newsletter platform, a link-in-bio or tip page). own_website then holds the creator's page on that host with its path, for example https://buzzsprout.com/2219693, or null when only the host's home page was found. false when own_website is a site off any host, or no site was found. A host page is not a website of the creator's own; filter on this before counting website holders.
newsletter_status, newsletter_platform, newsletter_url	The class, the platform (substack, beehiiv, kit, and so on), and the newsletter's own URL when exposed
newsletter_evidence_url, newsletter_check_method	The page or link that decided the status, and whether rules, rules_plus_ai, or browser decided it
sells_course, sells_coaching, sells_digital_product, sells_merch, sells_membership	What is sold on an owned page
brand_deals_visible, discount_codes_visible	Affiliate or ambassador wording, and a promo code on an owned page
business_email, business_email_source, manager_name, manager_email, manager_source_url	Public contact, and where it was found
website_email, website_email_source_url	Filled by the website scan add-on
agency_name, agency_domain, agency_match_method	Filled by the agency match add-on
segment_tier	A: no newsletter, an email, and something for sale. B1: no newsletter, an email, nothing for sale. B2: no newsletter, something for sale, no email. C: a newsletter and an email, whether or not the creator sells anything. unclassified: any other combination, an error row, or unknown_fetch_failed. No newsletter means none or email_capture_only; an email means business_email or website_email; for sale means any sells_ column is true. Every row carries a tier, and it is not charged.
source_url, read_at, row_status, error_reason, billable_events_json	Where the row came from, when, whether it is usable, and what it cost

⚠️ false and null are not the same thing, and an empty cell is not a failed read. A column this actor does not own is null, never missing. On a boolean, false means the page was read and the signal was not there; null means nothing read it. On an Influencer Profile Scraper row, verified: false is a profile without the mark and verified: null is a profile that could not be read. Read row_status before any other column; the paragraph below says how.

Every actor in this suite writes the same 59 flat columns, in the same order, and fills the ones it owns. A column an actor does not own is null, never missing. Nested data lives only in columns ending _json, as a JSON string, so a Clay column reads one cell.

Group	Columns	Filled by
Identity	creator_id, creator_id_method, creator_id_confidence, platform, handle, profile_url, display_name	Influencer Finder, Influencer Profile Scraper
Discovery	search_keyword, niche, similar_creators, similar_creators_method	Influencer Finder; search_keyword and niche also carried over by the Influencer Profile Scraper, Link in Bio Scraper and Newsletter Detector, and Influencer Change Monitor when an input item names them
Profile	followers, following, post_count, engagement_rate, engagement_method, verified, bio, bio_link, location_text, country_guess, country_guess_method	Influencer Profile Scraper
Contact	business_email, business_email_source, website_email, website_email_source_url, manager_name, manager_email, manager_source_url, agency_name, agency_domain, agency_match_method	Influencer Profile Scraper, Link in Bio Scraper and Newsletter Detector, Influencer Talent Agency Lookup
Links	link_in_bio_platform, outbound_links_json, other_social_profiles_json, own_website, website_is_host_page	Link in Bio Scraper and Newsletter Detector; other_social_profiles_json also by the Influencer Profile Scraper
Newsletter	newsletter_status, newsletter_platform, newsletter_url, newsletter_evidence_url, newsletter_check_method	Link in Bio Scraper and Newsletter Detector
Sells	sells_course, sells_coaching, sells_digital_product, sells_merch, sells_membership, brand_deals_visible, discount_codes_visible	Link in Bio Scraper and Newsletter Detector
Change	change_type, change_from, change_to, previous_run_at	Influencer Change Monitor
Segment	segment_tier	Link in Bio Scraper and Newsletter Detector
Run	source_url, read_at, row_status, error_reason, billable_events_json	All six

The Influencer Lead List Builder runs the Influencer Finder, the Influencer Profile Scraper, and the Link in Bio Scraper and Newsletter Detector in one run and fills what they fill. The Influencer Change Monitor and the Influencer Talent Agency Lookup read the profile (and the Influencer Change Monitor reads the link page too when check_links is on), so their rows carry the identity, profile, contact, and link columns as well.

Read row_status first. ok is a normal row. error carries the reason in error_reason (not_found: user banned, private, blocked: bot detection page) and charges nothing. partial means the page was read but a step after it failed, and the reason says which.

The creator ID. creator_id is cr_ plus 16 hex characters of the SHA-1 of platform:handle of the creator's primary profile, so the same creator gets the same ID in every actor and every run. When one run sees the same creator on two platforms, the rows share the ID and each row says how it was linked: bio_link_match (0.9, one profile links to the other), website_match (0.8, same own website), handle_match (0.5, same handle on two platforms, which collides on common words). A lone row is seed_handle at 1.

Country scope. This actor applies no country filter. A row started from a handle carries country_guess and country_guess_method from the profile read (the platform's region field, the location text, the bio, or a flag emoji); a row started from a bare bio_links entry has no profile read, so both are null.

🛠️ How to check a creator's link in bio page for a newsletter

1. Open the Input tab and put creator handles or profile URLs in handles, or link-in-bio and website URLs in bio_links, one per line.
2. Turn on render_unreadable_pages if your list carries Stan Store, linkin.bio, or Typeform pages; a plain fetch returns an empty shell on those.
3. Turn on scan_website_for_email and match_agencies if you want the add-ons.
4. Click Start. One row per creator lands in the dataset as each wave finishes.
5. Read row_status first, then newsletter_status with newsletter_evidence_url next to it.
6. Export from the Output tab, or pull the rows through the API.

🧪 Using it in Clay

Add an Enrichment > Apify column, pick this actor, and map your handle column to handles or your bio link column to bio_links. Every input is accepted as a string, which is what Clay sends. Filter on newsletter_status before filtering on anything else; an unknown_fetch_failed row carries no information about the creator and must not be scored as no newsletter.

🎯 Best input

Pass creator handles where you have them. A handle lets the actor match the creator's own site by name. A bare website link works, but a site named differently from the creator can read one class lower, for example email_capture_only instead of has_newsletter.

📚 Batch or single

One handle or one bio link is one run; a list is a batch. Both shapes reach the same code path, and so does the shape the platform produces when Clay sends a top level array against an object schema. Input is deduplicated before any fetch. Rows are held until the last creator is read, then delivered together, because the shared address rule (see Known limits) judges an address against every creator in the run. A run that is aborted, migrated, or less than 60 seconds from its timeout delivers every row it already resolved at that point. A row that throws becomes an error row with the reason and the run continues.

Concurrency (batch_size) is creators in flight, default 3, capped at 10. Renders run one at a time whatever the setting.

💵 How much does it cost to check a link in bio page?

Pay per event. Every run is charged one actor-start event ($0.002) to cover the run overhead; every other event is charged for output, never for input. The run stops at the maximum cost per run you set in Apify, or at max_charge_usd, whichever comes first: it delivers every row already charged and charges nothing more.

Event	Fires when	Price
actor-start	Once per run, on start.	$0.002
links-checked	Once per creator whose bio link or link-in-bio page was fetched and classified. A creator with no bio link returns newsletter_status none and does not charge this event.	$0.008
browser-render	Once per page rendered in the headless browser because the plain fetch returned no readable content, and the rendered page came back readable: 120 characters of visible text or 3 links off the page's host, and no block page. A render that returns the same empty shell is not charged, and a charged render always reaches the classifier (a link grid with little text, such as a Linkin.bio page, counts as readable by its links). Only when render_unreadable_pages is on.	$0.004
website-scan	Once per creator whose own website was scanned for an email. Only when scan_website_for_email is on.	$0.005
agency-match	Once per row where a manager or business email domain matched the bundled agency list and an agency name came back.	$0.003
instagram-bio-fetch	Once per Instagram profile row when the bio, bio link, and following were not on the embed widget or the datacenter API and the profile page was read over the residential proxy and came back readable. Only when escalate_on_block is on; uncheck it to avoid the charge and accept empty bio fields on about half of Instagram rows. Never on the embed or datacenter reads, never on another platform, never on a blocked page, never on an error row.	$0.010

Free Apify plan users get 140 results per calendar month, reset monthly. Upgrade to any paid Apify plan for unlimited use: https://apify.com/pricing?fpr=mamba

💳 What you are billed for. links-checked fires once per creator whose bio link page was fetched and classified; a creator with no bio link returns none and does not charge it. browser-render, website-scan, and agency-match fire only when their option is on and only when they produced something. The profile read that finds the bio link is not charged here (links-checked covers it), but an Instagram handle whose bio needs the residential page is charged instagram-bio-fetch. Set max_residential_reads to cap that event per run. Start from bio_links to skip the profile read altogether.

Apify bills its own platform usage on top of the event prices.

How a render runs: the page is polled once a second until it is readable, returned 1.5 seconds after that, and given up at 25 seconds; a session whose document never arrives or whose proxy tunnel drops a script gets one retry on a fresh session inside a 40 second budget. Renders run one at a time. Stan Store pages carry their content in the HTML and read at domcontentloaded (5 to 18 seconds over the proxy, measured 2026-09-22); Linkin.bio fills its link grid 1 to 2 seconds after that. At 1 GB the worst case (both attempts spent) costs about $0.0033 of compute; a typical render costs $0.0009 to $0.0015, so the $0.004 price covers it.

⌨️ Input

Everything is on the Input tab. The options worth explaining:

Field	What it does
handles	Handles or profile URLs. The profile is read for the bio link first; that read is part of the links-checked event. At most 200 per run.
bio_links	Link-in-bio or website URLs to start from directly, skipping the profile read. When one input item carries both a handle and bio links, the links are read as that creator's links and the actor returns one row for that creator, not one row per link; to get one row per link, pass the links in bio_links alone. At most 200 per run.
platforms	Default TikTok and Instagram. Where a bare @handle in handles is looked up; a full profile URL carries its own platform and ignores it. It does not filter bio_links: a link given without a platform is read whatever this field says.
render_unreadable_pages	Off by default. Stan Store, linkin.bio, and Typeform shells return an empty page to a plain fetch and are classified unknown_fetch_failed (157 of 1,034 creators in the pre-research). On, those pages are rendered in a headless browser and charged per render.
ai_check, ai_provider, ai_api_key	Off by default. With your own Anthropic or OpenAI key, a model reads the rule classifier's evidence and page text and rules on each row; newsletter_check_method becomes rules_plus_ai. The key is never stored, logged, or written to a row, and no Mamba Labs key is ever used.
scan_website_for_email	Off by default. For creators with their own website (not a link-in-bio page), reads the home, contact, and about pages and the footer for an email and records where it was found in website_email_source_url. Charged per creator scanned.
match_agencies	Matches the domain of a manager or business email against the bundled talent agency list (143 agencies from 13 public directories, 93 with a public contact). Charged per matched row.
escalate_on_block	On by default. A profile fetch that returns a bot detection page is retried once over the residential proxy, and on Instagram the bio page is fetched over residential when the datacenter API does not answer; a readable page charges instagram-bio-fetch ($0.010). Off: no instagram-bio-fetch is ever charged, and the Instagram bio link stays empty on about half of the rows, which leaves those rows with no page to follow. Ignored for bio_links.
max_residential_reads	Integer, minimum 0, default 0, which means no cap. Caps how many Instagram profile pages one run reads over the residential proxy, the read that charges instagram-bio-fetch, so it caps what the run can charge for instagram-bio-fetch at the cap times $0.010. Once the cap is reached the run stops escalating for the rest of the run: later Instagram rows still return, with what the embed widget and the datacenter API returned, and error_reason reads escalation_skipped on each row that would have escalated. Only acts when escalate_on_block is on.
max_download_mb	Integer, 1 to 200, default 25. The largest page or file the actor downloads from a creator's links, in megabytes. A link whose Content-Length is over the limit is not downloaded; a link with no Content-Length is read up to the limit, then stopped and discarded. The row keeps every other field, error_reason reads file_too_large, and the rest of the batch is not affected.
max_charge_usd	Optional. Your own cap for this run, in USD. The run stops before any charge that would take it past this amount, delivers every row already charged, and drops the rest. Leave it empty to rely only on the maximum cost per run you set in Apify, which the actor also honors.

Invalid input fails fast and says why. Give handles, bio_links, or both, each an array of 1 to 200 entries. When the input has neither, an empty array, a value that is not an array, or more than 200 entries in either field, the run ends before anything is charged: status Failed, exit code 2, and a status message that names the field and the accepted shape. For example:

• Invalid input (handles): the array is empty; pass an array of 1 to 200 handles or profile URLs, or bio_links instead
• Invalid input (handles): 201 entries, over the limit of 200 per run; split the list into runs of 200 or fewer
• Invalid input (bio_links): got a number; pass an array of 1 to 200 link-in-bio or website URLs, or handles instead

Exit code 2 is only ever an input refusal. Any other failure is a fault on our side; report it with the run link.

📤 Output

Exports to JSON, CSV, Excel, HTML or XML. One flat, snake_case row per creator per platform, 59 columns, with null rather than a missing key. No nested objects, so it drops straight into Clay, a spreadsheet or a warehouse table without a flattening step. Nested data lives only in columns ending _json, as a JSON string, so a Clay column reads one cell.

This row started from a bare bio_links entry, so platform is null and creator_id_method is bio_link_only; a row started from a handle carries the platform and profile columns too. The row below is trimmed to the columns this actor fills.

{
  "creator_id": "cr_1f22152aa4fd5c19",
  "creator_id_method": "bio_link_only",
  "creator_id_confidence": 0.3,
  "platform": null,
  "handle": "lifewithnancy1",
  "bio_link": "https://stan.store/lifewithnancy1",
  "business_email": "coachnancybookings@gmail.com",
  "business_email_source": "link_page",
  "manager_email": null,
  "link_in_bio_platform": "stan.store",
  "outbound_links_json": "[{\"url\":\"https://www.instagram.com/lifewithnancy1\",\"from\":\"https://stan.store/lifewithnancy1\"},{\"url\":\"https://www.tiktok.com/@lifewithnancy1\",\"from\":\"https://stan.store/lifewithnancy1\"},{\"url\":\"https://www.youtube.com/@LifewithNancy1-cn9te\",\"from\":\"https://stan.store/lifewithnancy1\"}]",
  "other_social_profiles_json": "[\"https://www.instagram.com/lifewithnancy1\",\"https://www.tiktok.com/@lifewithnancy1\",\"https://www.youtube.com/@LifewithNancy1-cn9te\"]",
  "own_website": null,
  "newsletter_status": "none",
  "newsletter_platform": null,
  "newsletter_url": null,
  "newsletter_evidence_url": "https://stan.store/lifewithnancy1",
  "newsletter_check_method": "browser",
  "sells_course": false,
  "sells_coaching": false,
  "sells_digital_product": false,
  "sells_merch": false,
  "sells_membership": false,
  "brand_deals_visible": false,
  "discount_codes_visible": false,
  "source_url": "https://stan.store/lifewithnancy1",
  "read_at": "2026-09-22T08:22:28.675Z",
  "row_status": "ok",
  "error_reason": null,
  "billable_events_json": "[{\"event\":\"browser-render\",\"count\":1},{\"event\":\"links-checked\",\"count\":1}]"
}

💡 Tips

• Pass handles where you have them, not bare links. See Best input above.
• Turn render_unreadable_pages on for a list with Stan Store or linkin.bio pages, and read newsletter_check_method to see which rows the browser decided.
• Read newsletter_evidence_url on every has_newsletter row you act on. A weak call is visible there, not silent.
• Bring your own Anthropic or OpenAI key with ai_check when a rule verdict alone is not enough for your list; newsletter_check_method then reads rules_plus_ai.

⚠️ Known limits

Business email coverage. Business email coverage is partial. The actor fills business_email only when a creator publishes one: in a bio, a link-in-bio page, or a YouTube channel description. YouTube keeps its business email button behind a sign-in and a CAPTCHA, which the actor does not bypass; in testing, 2 of 5 channels published an address in their description instead. Empty business_email means no public address was found, not that none exists.

An unreadable page is unknown_fetch_failed, not none. Stan Store, linkin.bio, and Typeform shells return an empty page to a plain fetch (157 of 1,034 creators in the pre-research). With render_unreadable_pages off, those rows say unknown_fetch_failed and carry no information about the newsletter.

A linked file over max_download_mb is skipped, not read. Show pages link audiobook zips and episode archives; on 2026-09-28 a 607 MB zip on archive.org crashed a whole batch. The actor now reads a link's Content-Length first and does not download a file over the limit (25 MB by default); a link that sends no Content-Length is stopped at the limit and the partial file discarded. The row comes back with every other field filled and error_reason reading file_too_large. Raise max_download_mb (up to 200) only if a creator's real page is that large.

A podcast Apple refuses is retried, then labeled. A podcast profile is read from Apple's public lookup, which refuses reads (HTTP 403) when too many arrive at once: on 2026-09-28, parallel runs made up to 2,450 reads in one minute and 666 reads were refused. A refused read is retried after 2, 4, 8, and 16 seconds. A read still refused after the fourth retry returns its row with row_status error and error_reason source_blocked, charges nothing, and the run continues; no other source is tried. Rerun those rows later, or with fewer runs in parallel: the same 666 reads, rerun at about 8 reads per second, were refused 0 times.

A signal counts only from a page judged to belong to the creator. A site named differently from the creator can read one class lower, for example email_capture_only instead of has_newsletter; pass the handle so the site can be matched by name.

The rule classifier is not perfect. The pre-research version measured 5 errors in 30; this build measured 0 in the same 30, three of which drove rule 7 and are in sample. Residual errors run in both directions, which is why every row carries its evidence URL.

A hosting platform is never the creator's website. 44 hosting domains are on a list in the actor (Buzzsprout, RSS.com, Libsyn, Podbean, Spreaker, Acast, Substack, beehiiv, Linktree, Stan Store, and more). A host's home page is never stored in own_website and never scanned for an email. A creator page on a host (a show page with a path, or the creator's own subdomain) is stored with its path, scanned on its own and below its path, never the host's root, and marked website_is_host_page. An address at a hosting domain is kept only when it identifies one show: a per show relay with a plus tag, such as podcasts+N@anchor.fm in one podcast's feed, or a local part that matches the creator's own page, such as chefcarla@substack.com for chefcarla.substack.com. A staff name (rob@libsyn.com), a functional alias (feeds@soundcloud.com), a generic mailbox (info, support, and 13 more), and any address on 3 or more creators in the run belong to the host, not the creator, and are dropped. error_reason then reads host_email_rejected, on a row whose row_status stays ok.

An address shared by unrelated creators is removed. An address on 3 or more creators in one run stays only on the creators it belongs to. A no reply address (noreply, do-not-reply, and similar) and an address at a platform (Apple, Spotify, Blogger, ThriveCart, and others) belong to nobody and are removed from every row. Otherwise a creator keeps the address when one of its own sites is on the address's domain, or its name or handle contains the address's owner (the domain name, or the part before the @ for free mail such as Gmail); creators that share a name, a handle, or a site count as one. A network or agency inbox on unrelated creators is removed from all of them, for example a distributor's address on 45 unrelated shows. A removed address leaves its column and source column null, and error_reason reads shared_email_rejected on a row whose row_status stays ok. The rule sees the creators in this run only: an address shared with creators from your earlier runs is not counted.

A podcast directory is never the creator's. Directories and players such as Podcast Index, Podchaser, Listen Notes, Player FM, Castbox, and Goodpods list other people's shows. A directory page is never stored in own_website, never scanned, and never read for a newsletter, a product, or an email, and an address at a directory domain is never returned (error_reason reads directory_email_rejected).

The agency list is partial by construction. 143 agencies from 13 public directories; a creator represented by an agency outside the list returns no match, never a guess.

Not X, not Facebook pages, not LinkedIn. A bio link to one of those is listed in outbound_links_json and not read.

What is never done. No login. No CAPTCHA solving. No LinkedIn fetch. No message to anyone. No key of ours is used on your run; the AI check runs only on the key you supply, and the key is never logged or written to a row.

What this actor shares

This run contributes the records it finds to a shared creator and agency pool that all users of this actor read from. What one run finds, the next run can read.

The toggle is contribute_to_shared_pool. It is a boolean input and it is on by default. Turn it off and the run still reads the pool and writes nothing to it.

What this actor contributes. The manager contacts it finds, the agency it matched them to, and any manager email domain the pool has not seen before, as a candidate agency for a later run to confirm.

Only public data that is already in your own output. Every field written to the pool is a field this run returned to you, read from a page the platform or the creator publishes to anyone without a login. Nothing from your Apify account, your input list, your API keys, or your own notes is sent. A contribution never deletes anything from the pool.

What a contribution is labeled with. The actor ID, the run ID, the pool key issued to the actor build, and a hash of the calling IP address, used for the rate limit and nothing else. Your Apify account and your user ID are not recorded.

Contributing is free. No event is charged for a write to the pool. If the pool is unreachable the run finishes as normal, the rows are dropped, and the run log says so.

❓ FAQ

What is a row with no handle and run_outcome= in error_reason? It is the run's summary row. A run that delivers no creator row at all writes exactly one row that says why, so you never get an empty dataset with no explanation. row_status is partial when every source answered and nothing matched (run_outcome=no_results), and error when a platform refused the request (run_outcome=blocked) or did not answer before the run's time ran out (run_outcome=timed_out). A blocked run is never reported as zero results: error_reason names the hosts reached, the hosts that refused, the hosts that timed out, and the run ID and build. The summary row carries no billable event and is never charged.

What happens when a platform is slow or refuses the run? Every request is capped by the time left in the run, and the actor stops starting new creators 90 seconds before the run's timeout so it can write what it has. A slow or refusing platform returns that creator's labeled error row and the run carries on with the rest. The run exits successfully with the rows it found, and the status message says when it stopped early.

I passed one handle and three links and got one row. Where are the other two? When one input item carries both a handle and bio links, the links are read as that creator's links and the actor returns one row for that creator. To get one row per link, pass the links in bio_links alone.

What is the difference between none and unknown_fetch_failed? none means readable owned pages were checked and nothing was found. unknown_fetch_failed means no bio link page rendered readable text, so nothing is known. Only none is about the creator.

Why was a render not charged? A render that returns the same empty shell as the plain fetch is not charged. Only a render that came back readable (120 characters of visible text or 3 links off the page's host, and no block page) fires browser-render, and a charged render always reaches the classifier.

Does the AI check use a Mamba Labs key? No. It runs only on the key you supply, and the key is never stored, logged, or written to a row.

Why is own_website a Buzzsprout page, and why does error_reason say host_email_rejected? The only site the creator links is their show page on a podcast host, so own_website holds that page and website_is_host_page is true. host_email_rejected means an address at the host was found and dropped, because it belongs to the host (a staff name, an alias such as feeds@, a generic mailbox such as support@, or one address on 3 or more creators in the run), not the creator. A per show relay address at a host is kept.

Is the profile read charged here? No. The profile read that finds the bio link is not charged here (links-checked covers it), but an Instagram handle whose bio needs the residential page is charged instagram-bio-fetch.

🧩 Want other GTM data?

Mamba Labs builds a fleet of GTM enrichment actors that share one flat, Clay-ready output convention, so their rows join on company_domain or creator_id with no cleaning step:

🕵️ Agent Accessibility Auditor	🤖 AI Tooling Detector
📡 GTM Signals Aggregator	🚀 Prospect Engine
📝 Publishing Frequency Tracker	🦋 Bluesky Brand Presence Mapper
⏩ Sequencer Lead Push	🔄 Company Change Event Feed
📇 Company Contact Details Extractor	🧭 Company Discovery List Builder
🏢 Company Firmographic Enricher	🪪 Company Identity Resolver
🌐 Company Social Presence Mapper	🏷️ Contact Classifier
📈 Influencer Change Monitor	🔎 Influencer Finder
🧾 Influencer Lead List Builder	👤 Influencer Profile Scraper
📬 Domain Deliverability Checker	🔗 Domain to LinkedIn URL Resolver
🛒 Ecommerce Platform Profiler	✉️ Work Email Waterfall
🎪 Event Presence Index	⚖️ Expert Witness Directory
💵 Company Funding Record	💰 Funding and Press Signal Scanner
🐙 GitHub Organization Signal Scanner	🧑‍💼 GTM Hiring Signal Scraper
📋 Job Posting Monitor	🧱 Tech Stack Signal Detector
🎯 ICP Fit Scorer	🔑 Job Board Keyword Signal Scanner
🏛️ Legal Entity Resolver	💼 LinkedIn Company Page Mapper
💬 LinkedIn Post Tracker	📢 Meta Ad Library Monitor
📸 Meta Brand Presence Mapper	📮 Outbound Stack Detector
📄 Page Finder and Extractor	🧑 People Finder & Email Verifier
📌 Pinterest Brand Presence Mapper	🏆 Government Contract Award Monitor
📅 Reporting Window Finder	👽 Reddit Brand Presence Mapper
⭐ Trustpilot Reputation Enricher	🤝 Influencer Talent Agency Lookup
👥 Team Page People Extractor	🎵 TikTok Brand Presence Mapper
📊 Website Traffic Rank Estimator	🏅 Workplace Program Detector
✖️ X Brand Presence Mapper	▶️ YouTube Channel Stats Extractor

Every actor in the suite takes a domain, a company, or a creator and returns one flat row, so they stack in the same Clay table without reshaping anything.

🛠️ Need something custom built for you or your team? Tell us what you are trying to find and we will build it. Talk to Mamba Labs.

🆘 Support

Issues, field requests and bug reports: open an issue on the actor's Issues tab. Mamba Labs reads every one.

ℹ️ Sourcing and legal. Every field comes from pages the platforms and the creators publish to anyone without a login, read directly or through a proxy, with no login, no CAPTCHA solving, and no LinkedIn fetch. The row records what was public at read_at. Nothing is assessed or scored; a class, a flag, or a match method says what was read and where. You are responsible for how you use the output, including under applicable data protection and platform terms.

Built by Mamba Labs.