Automate Instagram Profile Enrichment for New Leads

A signup form that asks for an Instagram handle collects a string. It doesn't tell you whether that handle belongs to a real account, how many followers it has, or whether it's a business account at all. Someone has to look that up — and if a human does it one lead at a time, it either doesn't happen or it happens hours after the lead was worth acting on.

If you're an agent (or building one) reading this rather than a human, the full machine-readable schema for every endpoint below lives at mindcase.co/skills.md.

What does an Instagram handle actually tell you about a lead?

A raw handle is worth almost nothing. The same handle resolved into a profile tells you follower count, whether the account is verified, whether it's flagged as a business account, and a bio you can match against your own ICP keywords. For a creator/influencer signup flow, follower count and verification separate someone worth a fast reply from someone worth a form email. For a B2B signup, a business-account flag and a bio mentioning an industry term is a stronger qualifier than the free-text "company name" field most forms already collect and mostly ignore.

Take a creator-marketplace signup form as an illustrative example: someone fills in name, email, and an Instagram handle, and hits submit. Without enrichment, that row sits in a queue until someone manually opens Instagram and checks whether the account is worth onboarding. With the handle resolved automatically, the same row arrives already carrying follower count, verification status, and bio — enough for a rules engine to route "verified, 50k+ followers" straight to a priority queue and "brand-new account, nine followers" to a lower-touch one, before a human ever opens the lead.

How do you trigger enrichment the moment a lead comes in?

Call Instagram Profiles API from whatever already handles your signup — a form-submission webhook, a queue consumer, a CRM automation step — the instant the handle field is populated. There's nothing exotic about the trigger itself; the part worth getting right is the call:

curl -X POST "https://api.mindcase.co/v1/data/instagram/profiles/run?wait=true" \
-H "Authorization: Bearer $MINDCASE_API_KEY" \
-H "Content-Type: application/json" \
-d '{
  "params": {
    "usernames": ["new_lead_handle"]
  }
}'

# $0.002 per profile returned

A single call returns 25 fields — followers, verified, businessAccount, businessCategory, bio, bioLinks, and more — enough to write directly into a CRM record without a second lookup.

How do you filter out low-quality matches before they hit your CRM?

Don't write every result straight into your CRM. The cheap mistake is treating "the API returned a profile" as "this is a real lead" — a one-week-old account with nine followers is a technically valid response and a useless one. Gate the write instead of the call: require at least one real signal (verified, a populated businessCategory, or a follower count above whatever floor makes sense for your funnel) before the record counts as enriched, and route anything that fails the gate to a manual queue instead of silently discarding it. Checking that gate inside the same loop that parses the response — not as a separate cleanup pass afterward — means you never pay to enrich a lead twice.

The gate itself should match the funnel, not a fixed rule copied from somewhere else. A creator marketplace might require verified OR followers above a five-figure floor; a local-business directory might instead require businessAccount: true and a non-empty businessCategory, since follower count says nothing about whether a shop is real. Write the gate as an explicit, named rule in your own code — not a magic number buried in an if statement — so the next person who reads it knows why a lead got routed where it did.

What can't you get this way?

Two cases.

A private account returns a thin profile. Follower count, bio, and verification status are public metadata and still come back; post history and highlight reels don't, because that content genuinely isn't public. That's the platform's own privacy boundary, not a gap in what Mindcase returns.

A handle that doesn't exist returns nothing to enrich. A typo'd or already-deleted handle isn't a data problem to fix — it's a data-entry problem in whatever form collected it, and the right move is flagging it back to the lead-capture step, not retrying the lookup.

Which endpoint should you use for which job?

FAQ