Free first

Why free rows and providers that only bill a found result are tried before paid ones, and how a guessed answer affects what a fallback walk pays.

When a job has more than one way to get the same answer, looot tries the ones that cost you nothing before the ones that charge, without changing which provider your fallback walk would otherwise have preferred.

Free rows lead their bucket

A row priced at a known $0 (a stated free price; an unpriced row does not count) is moved ahead of the paid rows in its own rank bucket, for the job:<id> pick and for the fallback plan. It never passes an own-key row, a cheaper $0 row, or a row of another bucket, so a free row that is currently failing still sits behind a working paid one. A direct run keeps the endpoint you asked for first; the free rows only lead the rest of its fallback plan.

A provider that only bills on a hit moves up too

Separately, a provider whose price model only charges when it returns a counted result (never on a miss) moves ahead of the paid rows just before it in the walk whose hold, for this input, would be at least as large as its own. It never passes another free row, an own-key or $0 row, a cheaper paid row, or a row from another bucket.

Together these two moves can only lower the route’s hold, never raise it, and they never change which row prefer: "cheapest" picks as the cheapest. Each attempt is still charged at its own price; nothing here changes what an attempt costs.

What still bills on a miss

Not every provider is free on a miss. A row whose price model bills a flat rate on every answer, or bills the volume you requested, charges whether or not it found anything. Such a provider bills a “not found” answer too, and a fallback walk pays for it before it moves on to the next provider. Run job:people.email.find with fallback and read route.summary to see each attempt’s own charge.

Guessed answers

Some providers do not look an email up; they guess it from a known pattern for the domain (first.last@domain.com, for example). That answer is a weak result, not a hit:

{ "outcome": "weak", "route": { "attempts": [{ "verdict": "guessed", "reason": "guessed an address from the domain's email format; verify it before use" }] } }

Unlike an ordinary weak hit, a guess does not stop a fallback walk. You asked fallback for a found address, so the walk keeps going under the same rules (maxAttempts, maxCostUsd, the error bound, stopAtFirstMiss for a later miss). If a later provider hits, that hit is served and route.summary reads something like:

zerobounce: guessed ($0.01). hunter: found ($0.0245). Charged $0.0345.

If no later provider hits, the guess itself is served as the result, outcome: "weak", verdict: "guessed".

Price consequence. When a guessing provider ranks ahead of a provider that looks the address up and that finder later hits, you pay for both: the guess plus the finder. Without fallback, a run on a guessing endpoint is one attempt, charged, weak, “guessed”. Verify a guessed email before you use it.