← x402 catalogue

x402 data handling and retention

Maha Strategies LLC operates these services. Updated 16 October 2026. This notice covers the released modular services, the six demand tools and their discovery measurement, not every Maha product. Other offers publish their own retention fields.

Modular services — 16 October 2026

The 1000 released modular services use Redis, not Supabase, for recovery and response measurement. Result content (995 services: 24 hours; 5 services: 30 days). Minimal purchase metadata: 90 days from creation; recovery does not extend deadlines. Content retention starts when the result is prepared. Minimal receipt metadata contains endpoint ID, input/result hashes, public payer, nonce, transaction, state and creation time. Raw inputs, signatures and recovery secrets are not written to the merchant cache. Hashes are not anonymization. Redis expiry is automatic. Public blockchain records remain permanent.

Non-identifying aggregate counts distinguish new validated responses, recovery responses and responses to the known publisher-funded wallet. They expire after 90 days of aggregate inactivity and contain no wallet, input, signature or recovery secret. A validated server response is not evidence of buyer receipt or usefulness. Protected operator indexing preserves a redacted transaction report and an encrypted private recovery outbox for 90 days; it is not counted as customer revenue.

Inputs and recovery — six demand tools

Submit synthetic or sanitized data only. Do not send credentials, identity documents, payment-card data, protected health information or confidential personal records. Input validation is not a detector for private information. The tools process your JSON to produce a bounded result; the research tools use reviewed public sources and make no model calls.

Prepared results, input hashes, payer and network, payment fingerprints, creation times, settlement receipts and a coarse discovery label are stored in our Redis recovery cache for at most 24 hours from preparation. Recovery does not restart that clock. Short quotations can be present in the result. Full source bodies, raw CSV cells, payment signatures and recovery secrets are not written to that cache or to attribution records.

Keep your exact input, signed authorization and recovery headers in your own private outbox before submitting. They are bearer evidence: encrypt them at rest, restrict access and never put them in a public support export. Reuse the original authorization for explicit recovery; do not automatically sign a replacement. Recovery can fail if output is unavailable, storage failed or the retention window ended.

Discovery measurement

The optional X-Maha-Discovery-Source header accepts bazaar, maha_canary, direct, reddit, alsp, nohumans, tanod, nsgoods or unknown. Without it, a small set of caller-supplied user-agent/referrer signals may choose a coarse label. We do not store their raw strings. These labels are self-reported, not verified referrals, customer identities or commission entitlements.

Private purchase attribution contains an offer ID, chain, authorization fingerprint, chain-specific wallet pseudonym, amount, transaction hash when known, the first discovery label, settlement/response states, retry counters and timestamps. It has no input text, IP address, cookie, raw referrer, payment signature or recovery secret. A wallet hash is pseudonymous, not anonymous: a known public wallet can be matched. A server-prepared response does not prove that a buyer received it.

These new purchase records have a 90-day active reporting window from first observation. An authenticated hourly job removes expired records in batches of up to 1,000; retries do not extend retention. Cleanup failures or a backlog can delay physical removal and require operator attention. Existing daily usage counters contain aggregate counts and bounded numerical metrics without wallet identifiers and have no fixed expiry. We do not backfill historical referral identities.

Payments, providers and access

Payment verification necessarily processes your public wallet, authorization and chain transaction. Existing payment, settlement and replay-protection ledgers are separate from attribution and are not deleted by its 90-day cleanup. Public blockchain records cannot be erased by Maha; the public settlement ledger can link to those records. Known publisher wallets are separated from other activity, but an external transfer is not automatically customer demand.

The service uses Vercel for hosting, Upstash Redis for bounded recovery and Supabase for accounting. Payment verification also uses the configured facilitator and chain RPC providers. Requests pass through those providers, which may handle IP addresses, paths, timing and security logs under their own settings. Cache expiry or database deletion is not a promise of immediate removal from provider backups or infrastructure logs. This notice does not assert their exact backup or log lifetimes.

Purchase attribution is not publicly readable. Anonymous and ordinary authenticated database roles have no access; restricted service functions handle writes and cleanup. Public product statistics are aggregates. No additional advertising cookie or browser visitor identifier is introduced by this release.

Your controls

Omit the optional source label, use sanitized examples, avoid submitting sensitive information and manage your local outbox and downloaded results. For privacy questions, access/deletion requests or infrastructure-retention details, contact mayone@mahastrategies.com. We may need to verify control of the relevant wallet; never send a private key or seed phrase. Financial/replay records and public chain data have separate constraints.

Buyer and recovery instructions ↗