Build with Evidexa

Choose a transport

Connect an MCP client to /mcp, or call the four JSON REST routes under /v1. Tool discovery, this documentation, OpenAPI, and pricing are free.

Monthly subscription route

Monthly USD billing by card or bank is the planned conventional access model for developers and teams that need predictable spend. It will use the same MCP/REST tools and evidence contract as pay per call. No subscription checkout, API-key entitlement, plan price, or availability is active yet; activation remains gated on the company, consumer-capable merchant provider, tax/invoice, refund, privacy, and source-rights requirements in the launch checklist.

Pay-per-call route

The machine-native route is currently paused. Its published per-call prices remain $0.01–$0.10. x402 is one billing rail for autonomous callers, not the product identity or the only planned way to access Evidexa.

x402 REST contract

1. When the pay-per-call route is active, send a JSON request without payment.
2. Read the x402 V2 PAYMENT-REQUIRED challenge.
3. Validate the amount, network, asset, and recipient against your budget.
4. Retry with a valid PAYMENT-SIGNATURE.
5. For a synchronous call, read the result and PAYMENT-RESPONSE receipt.

Client compatibility: an unsigned x402 discovery request may send a valid JSON body as text/plain or without a Content-Type; Agentic Wallet 2.12.1 may instead issue a bodyless discovery POST. Evidexa returns only the price challenge for that bodyless probe because no input is available to inspect. Any retry carrying a payment proof must use Content-Type: application/json and pass byte, JSON/Schema, policy, and Provider preflight before settlement.

Async Intelligence Jobs

For user_intelligence, topic_intelligence, or product_intelligence, set request_context.response_mode to async and provide a cryptographically random client_request_id of at least 16 characters. After x402 verification, Evidexa returns 202 Accepted with Location, Retry-After, and an opaque /v1/intelligence/jobs/… result URL. The 202 response is only an authorization acknowledgement: billing.charged is false, and Evidexa settles only after the background Provider operation succeeds.

Poll the result URL until it returns HTTP 200 with status: succeeded, the Intelligence result, and PAYMENT-RESPONSE. A queued or running Job returns 202. A business failure returns its safe error with charged: false. HTTP 409 EVIDEXA-409-PAYMENT_OUTCOME_UNKNOWN requires manual reconciliation and never authorizes another payment. Jobs expire after the selected Tool TTL.

Safe REST retries

Synchronous calls advertise the optional x402 payment-identifier extension. Reuse the same signed payload and Payment ID after a lost response; Evidexa replays the stored result without settling again. Clients without that extension may use an eligible random client_request_id and retry the identical body without a payment proof. Async Jobs always use that ID for deterministic recovery: resending the identical body returns the existing Job, while a different body with the same ID returns HTTP 409 before verification, Provider work, or settlement. Do not submit a fresh payment after an ambiguous result.

Safe MCP retries

Every paid MCP Tool requires request_context.client_request_id as a cryptographically random value of at least 16 characters. Persist it until the Tool TTL expires. After one successful settlement, the same ID and identical canonical input recover the stored CallToolResult and public receipt without another payment proof, Provider request, or facilitator settlement. The result carries evidexa/retry-entitlement metadata with an opaque reference and replay flag. A concurrent duplicate returns an in-progress error with billing.charged: null, while reusing the ID for different input returns EVIDEXA-409-IDEMPOTENCY_CONFLICT.

The ID is a short-lived bearer recovery capability: keep it private and unpredictable. If Tool execution finished but settlement became ambiguous, Evidexa quarantines the ID as EVIDEXA-409-PAYMENT_OUTCOME_UNKNOWN, also with billing.charged: null; stop and reconcile instead of creating a fresh proof.

Client support matrix

Routes

Response contract

Every successful result includes a status (ok, partial, or no_data), a data window, coverage, warnings, billing metadata, public source identifiers, and evidence-backed insights. A canonical cache hit reports zero newly consumed Provider Credits. X post text and complete upstream payloads are not returned.

Safety

Requests for doxxing, real-time location tracking, sensitive-trait inference, prohibited political persuasion, or high-impact decisions are rejected before payment. Read the acceptable-use policy.

Limits

Xquik Guest REST is the sole production data provider in the MVP. A cache miss can fail when that provider is unavailable or the prepaid balance is below reserve. Provider deadlines are 8/12/25/35 seconds by tool; request_context.max_latency_ms may lower but never raise the applicable limit. Async foreground readiness is capped at eight seconds. REST and MCP retry state use protocol-separated identifier hashes in the same Durable Object class. The derived-result cache separately prevents repeated Xquik work for the same canonical input during the Tool TTL. Because the current official MCP handler executes the business callback before settlement, a failed settlement may still consume Provider Credits even though the retry ID is quarantined from automatic repayment.