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.

REST payment flow

1. 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.

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. The derived-result cache prevents repeated Xquik work for the same canonical input during the Tool TTL. This does not provide MCP payment replay; REST sync replay and async Job recovery use separate Durable Object state.