> ## Documentation Index
> Fetch the complete documentation index at: https://docs.data.avina.io/llms.txt
> Use this file to discover all available pages before exploring further.

# The data network

> Where results come from, how Avina chooses which data sources to query, and what that means for coverage.

No single data provider is best at everything. One has detailed company records, another indexes job listings, a third finds companies on the open web that no database has categorized. Teams that need broad coverage end up buying, integrating and reconciling several.

The Data API puts those sources behind one request. You describe what you want. Avina decides which sources to query and checks what comes back.

## What is in the network

> [card] Company databases
>
> Structured facts about a company, often called firmographics (Descriptive facts about a company, such as industry, size, location and revenue. The company equivalent of demographics.): industry, location, employee count, revenue, company type, funding and founding year.

> [card] Job and hiring data
>
> Open job listings and recent hires, by title and date. Powers "is hiring" and "just hired" requirements.

> [card] Technology data
>
> Which products and vendors a company uses, and when the technology was detected.

> [card] AI web search
>
> Live research across the public web for requirements no database has a column for.

> [card] People and contact data
>
> Who works where, in what role, with work emails and phone numbers on request.

> [card] Verification
>
> Email verification, and evidence checks that confirm a claim before it reaches you.

Results are normalized into one schema, so a company looks the same whichever provider found it. Provider names are not part of the response.

## How sources are chosen

Before a search retrieves anything, Avina looks at what the request contains and picks the sources that can answer it.

| Request | Where the search starts | Why |
| - | - | - |
| "US software companies with 50 to 200 employees" | A company database | Every requirement is a structured field that a provider can filter on directly. |
| "B2B companies hiring a dental assistant" | Job listings | The hiring requirement is a structured condition that a job-listings provider can filter on. |
| "Manufacturers of industrial heat pumps" | AI web search | No database categorizes companies this specifically, so the search starts from the public web. |
| "Series B fintechs that announced a banking partnership this year" | AI web search | The announcement is an event, and events need research. |

Two rules apply to every search:

* When data providers run out of candidates, the search continues with AI web search.
* Every candidate is checked against all of your requirements, whichever source found it.

> [!TIP]
>
> Anything you can express as a [structured filter](https://docs.data.avina.io/guides/structured-filters.md) is checked against data records rather than researched, which costs less than a free-text criterion.

## Deduplication

The same company can come back from several providers under slightly different names. Avina merges candidates into one record per company website domain before checking them and before counting them.

* A company appears once in a search's results.
* `limit` counts distinct companies, not provider rows.
* Twenty matching job listings at one employer still produce one result.

## What the network cannot know

Some requirements cannot be answered from public or licensed data, whichever provider you ask. Avina tells you so instead of guessing.

| You ask for | What happens |
| - | - |
| Activity on your own website or product | Listed under `unsupported_criteria`. Public data cannot see it. |
| Private intent: "planning to switch vendors next quarter" | Listed under `unsupported_criteria`, unless it has been announced publicly. |
| Subjective quality: "has a strong engineering culture" | Listed under `unsupported_criteria`. Rephrase as something checkable, such as "publishes an engineering blog". |
| Every company on earth that matches | Not promised. A search returns verified matches up to your `limit`, not a census. |

## Compared with going direct

Going straight to one provider is a reasonable choice when its data already answers your question. The Data API is the better fit when a request needs more than one kind of data, or when you do not want to build and maintain the integrations.

| | One provider, direct | Avina Data API |
| - | - | - |
| Integrations to build and maintain | One per provider | One |
| Query language | Each provider's own | Plain language or one filter format |
| Requirements spanning several data types | You join and reconcile | Checked together, per company |
| Proof for each result | Varies | Evidence for every requirement |
| Billing | One contract per provider | One credit balance, provider cost plus 5% |

The trade-off is the 5% platform fee. For a request that one provider can fully answer, calling that provider directly at the same rate costs slightly less. See [Pricing](https://docs.data.avina.io/concepts/pricing.md).

## Next steps

> [card] [Pricing](https://docs.data.avina.io/concepts/pricing.md)
>
> How provider cost becomes credits.

> [card] [How it works](https://docs.data.avina.io/concepts/how-it-works.md)
>
> The full search pipeline.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.