Before an agent sends a real request, check the outcome, canonical contract, limits, privacy, delivery evidence, payment boundary, and recovery path. This is a production decision aid—not a vendor score or a promise that every API is safe.
agent integrationAPI due diligenceproduction readinessdelivery evidencespend policyrecovery
The rule
Evidence before authorization.
An agent API is ready for a production call only when the caller can identify the intended result, bind the request to a canonical route, enforce its own limits, and verify delivery. Payment authorizes a request; it is not identity authentication. A directory entry, ranking, crawler result, or HTTP 402 challenge is discovery evidence—not proof of delivery.
Eight checks before productionRecord a yes, no, or open question
#
Check
Evidence to keep
Stop if
1
Outcome What exact result is needed?
Input, output and failure boundary written in plain language.
The route is selected because its name sounds close.
2
Canonical route Which endpoint owns the result?
First-party catalog, OpenAPI operation or intent response with a stable URL.
A reseller, search result or redirect is the only source of truth.
3
Contract What does the live request declare?
Method, schema, version, price, network, recipient, timeout and response shape.
Terms are inferred from a stale screenshot or generic marketing page.
4
Data boundary What may leave the caller?
Allowed fields, source rights, processing location, retention and deletion behavior.
The route needs credentials or private data that the policy does not allow.
5
Execution limits How does the caller fail closed?
Maximum amount, payload, latency, retries, concurrency and idempotency policy.
A retry could duplicate a paid side effect or exceed the spend cap.
6
Delivery proof What proves the job completed?
Expected fields, artifact URL or hash, receipt, status and settlement evidence.
Only a 200, a payment receipt or a 402 challenge is available.
7
Bounded smoke Can one real request be verified?
Read-only preflight plus one production smoke with redacted input and a saved result receipt.
There is no safe test input, owner-approved authorization or refund path.
8
Recovery What happens after failure?
Timeout, duplicate, refund, revocation, rollback, support and incident owner.
No one can explain how to stop, reconcile or recover a partial delivery.
Safe evaluation flow
Discover → preflight → authorize → verify.
Keep free discovery separate from a paid call. The caller should be able to stop after any step, preserve the evidence, and explain why it continued.
# Free: resolve a governed route from the intended outcome
curl --get 'https://api.delx.ai/api/v1/x402/start' \
--data-urlencode 'q=inspect an API contract before production'
# Read: inspect the live route and 402 challenge
curl -i 'https://api.delx.ai/api/v1/x402/website-intelligence-report'
# Paid: only after policy checks; keep the source attribution header
# and verify the returned result, receipt and refund behavior.
Independent field review · 11–12 August 2026
What a paid review can actually establish.
Would Pay Again paid for 10 independent paid calls across Delx REST and MCP surfaces and published a “would pay again” verdict. The review is useful because it tested parity and bad-input behavior instead of treating a catalog page or a 402 challenge as proof.
01
Parity was tested
The sampled utility calls charged the same listed price and returned matching, independently checkable output over REST and MCP.
02
Two concrete defects surfaced
The MCP 402 resource-host label and util_uuid_generatecount=999 behavior were corrected the same day and retested independently on 12 August.
03
The boundary stays honest
Ten calls are evidence about a tested subset, not a certification, ranking claim, endorsement of every route, or guarantee of future behavior.