A lead generation API stops being a growth tool and starts being infrastructure the first time a sales rep asks why half the "matched" contacts never made it into sequence. The hard part is not getting a response from an endpoint. The hard part is getting usable records with clear status codes, predictable credit burn, and enough observability to explain what happened when a batch underperforms.
In practice, a production lead generation API needs a contract your team can operate against. That means request fields that map cleanly to CRM identifiers, synchronous and async modes that are explicit about completion state, and error semantics that separate bad input from no-match, rate-limit, and downstream provider failure. A raw payload with domains and an idempotency key belongs in a code block later. It does not explain whether a 200 means enrichment succeeded, a job was accepted, or partial results were returned with verification still pending.
Waterfall routing changes the economics. A high match rate can still produce poor output if the API spends credits on low-confidence providers, returns unverified emails, or hides which source won each field. Teams that run this in production usually care more about verified contact coverage, duplicate suppression, retry safety, and per-record audit trails than headline match numbers. RichAPI is useful here only if it exposes enough detail to tune those trade-offs instead of masking them behind a single success flag.
Agent access adds another layer. If an MCP-style agent can call the lead generation API directly, it needs narrow scopes, record caps, idempotent writes, and approval gates before it can trigger expensive enrichment or push data into CRM. Otherwise one bad prompt, or one loop in the orchestration layer, turns into burned credits, duplicate records, and a cleanup project nobody planned for.