Single Checks and Bulk-Only Sources in Avatar Lookup

Two questions decide how an avatar lookup fits into your workflow, and they are easy to answer in the wrong order. The first is which platforms you can ask about one identifier at a time. The second is what an answer actually licenses you to conclude. Getting the first one wrong produces a workflow that cannot be built; getting the second one wrong produces a workflow that is built on a misreading.

Not every source is available for a single check

Single checks cover WhatsApp, Gmail, Yandex and Mail.ru. Telegram, Viber, LINE, Zalo and MAX are bulk-only sources: they are supported, but only through a file task, not through a one-identifier-at-a-time lookup.

This distinction matters early, because it decides the shape of the feature you are building. An interactive use — a contact card in a CRM, a support agent looking at one record, a form that enriches an address as it is typed — can only be built on the single-check sources. If the platform you care about is bulk-only, the product around it has to be a batch job: collect identifiers, submit a file, process the result later.

Bulk tasks cover the whole supported set: WhatsApp, Telegram, Viber, LINE, Zalo, MAX, Gmail, Yandex and Mail.ru. A file can carry up to 100,000 entries and must stay under 10 MB, in CSV, TXT or XLSX.

One platform is worth naming explicitly because people ask about it: LinkedIn is not supported, in either mode.

Three results, and only one of them is a "no"

An avatar result distinguishes three states: an avatar is available, there is no avatar, or the outcome is undetermined.

Only the first is a positive finding. The other two are frequently collapsed into "this account does not exist", and that reading is wrong in both cases. No avatar means exactly what it says — the account has no public profile photo to retrieve. Plenty of real, active accounts never set one. Undetermined means the lookup did not reach a conclusion at all; it is not a negative result, and it is not a quieter way of saying no.

If your pipeline writes both of these into the same column as "not found", you have converted two different non-answers into a false statement about account existence — and you have lost the ability to tell later which rows deserve a retry.

What an avatar does not establish

An obtained avatar is a public image associated with an identifier at the time of the lookup. It is not identity verification, not KYC, not facial recognition, and not proof that the person shown in the image controls the account. Retrieving an image also does not grant ownership of it or a right to reuse it however you like; whatever licence applies to that image applied before you looked it up and still applies afterwards.

The same caution applies to appearance attributes such as presented gender, age range, hair colour or skin-tone features. Where these are returned, they are algorithmic estimates derived from an image. They are auxiliary references only — not demographic fact about a real person — and they should not drive high-impact decisions, screening, tracking, or any form of profiling that the person has not agreed to.

Choosing the mode before writing the integration

In practice the decision collapses to one question: does your use case need an answer while someone is waiting?

If yes, and the platform is one of the four single-check sources, an interactive lookup works. If yes but the platform is bulk-only, the honest answer is that the interactive version cannot be built — and it is much cheaper to discover that before the integration than after it. If no, a file task is the better fit anyway, because it handles volumes an interactive path never will.