Icypeas verify FOUND not billed

Medium Severity

Hosted pricing for icypeas_verify_email only treats statuses containing DEBITED as billable, so a terminal FOUND result is charged zero credits even though the inline comment and icypeas-hosting.test.ts expect 0.1 credit per completed verification.

 

^{Reviewed by Cursor Bugbot for commit b7a8a4a. Configure here.}

Icypeas verify fails enrichment mapping

Medium Severity

After polling, icypeas_verify_email sets success to false for terminal statuses that are not FOUND or DEBITED. The email-verification cascade treats NOT_FOUND and DEBITED_NOT_FOUND as definitive invalid results in mapOutput, but runEnrichment never calls mapOutput when response.success is false, so those verdicts are skipped unless a later provider fills the cell.

 

^{Reviewed by Cursor Bugbot for commit b7a8a4a. Configure here.}

success: false for terminal non-found statuses breaks the cascade

postProcess returns { success: false, output: mapItem(item) } for NOT_FOUND and DEBITED_NOT_FOUND. The enrichment cascade runner in enrichments/run.ts checks response.success first — if false, it looks for output.status === 404; otherwise it throws. Since the Icypeas string 'NOT_FOUND' never equals the number 404, the runner throws "icypeas_verify_email failed", counts Icypeas as an infrastructure error, and falls through to Enrow without ever calling the cascade's mapOutput.

Concrete failure: the cascade's mapOutput maps NOT_FOUND → { status: 'invalid', deliverable: false }, but that code path is unreachable. The waterfall always continues to Enrow; if Enrow also fails (rate-limit, timeout), the cell returns blank instead of invalid. Every other async-poll tool in this PR returns success: true from postProcess and lets mapOutput do the filtering — icypeas_verify_email and icypeas_find_email should do the same.

Same success: false cascade-runner mismatch as in icypeas_verify_email

postProcess returns { success: false } for NOT_FOUND, BAD_INPUT, INSUFFICIENT_FUNDS, and ABORTED. The cascade runner treats any success: false with a non-404 output.status as a hard error. For work-email the end result is the same (mapOutput returns null for a null email either way), but the error counter is inflated. Return success: true for all terminal statuses, matching the pattern used by every other async-poll tool in this PR.

Billing function throws when status is falsy

getCost throws 'cannot determine cost — status is missing' if output.status is falsy. In normal operation postProcess always returns a terminal status, so this is unreachable in practice. But if the hosting layer ever evaluates cost on the initial transformResponse result (before postProcess runs), output.status will be null and the throw propagates as an unhandled billing error. Consider returning 0 when status is absent, matching the defensive posture of the other providers.

API key embedded in URL query string (?apiId=...) for all Datagma endpoints

Every Datagma tool appends url.searchParams.set('apiId', params.apiKey). This is Datagma's documented auth scheme and can't be changed client-side, but the hosted API key appears verbatim in every request URL and will be captured by server-side access logs at Datagma and any intermediary. A note in the DATAGMA_API_KEY_PREFIX doc comment that this API uses URL-parameter auth would help operators understand the risk when rotating a compromised key.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!