AI एजेंट्स first class API consumers बन रहे हैं। जिस क्षण आप किसी एजेंट को अपने दम पर tools को call करने देते हैं, आपको एक practical समस्या का सामना करना पड़ता है: एजेंट metered API access के लिए कैसे भुगतान करे बिना किसी इंसान के checkout process से गुजरे, invoices को manage किए, या manually keys rotate किए?
यही motivation है AI एजेंट्स के लिए x402 payments की: एक सरल, HTTP-native paywall pattern जहाँ एक API Payment Required के साथ respond कर सकती है, और एजेंट programmatically payment complete करके request को retry कर सकता है।
x402 क्या है?
x402 एक API payment flow के लिए shorthand है जो HTTP status code 402 Payment Required के around बना है।
HTTP 402 लंबे समय से exist करता है, लेकिन यह HTTP standard में जानबूझकर “reserved for future use” है, जिसका मतलब है कि इससे attached कोई single official, universal payment protocol नहीं है। (देखिए HTTP semantics specification, RFC 9110।)
Practice में, जब developers “x402” कहते हैं, तो उनका मतलब आमतौर पर होता है:
- एक API जो 402 के साथ request को deny कर सकती है जब payment की जरूरत हो।
- 402 response में एक machine-readable payment challenge (“क्या pay करना है, कितना, और कहाँ”)।
- एक client (अक्सर एजेंट) जो programmatically pay कर सकता है और proof of payment के साथ same request को retry कर सकता है।
So, x402 कम “one exact spec” है और ज्यादा “compatible design choices का family” है जो सभी एक outcome को aim करते हैं: pay-per-request APIs जिन्हें autonomous agents safely use कर सकें।
x402 AI एजेंट्स के लिए specifically क्यों महत्वपूर्ण है
Traditional API monetization humans और backend services के लिए fine work करता है, लेकिन agents के लिए awkward हो जाता है:
- Subscriptions और API keys एक long-lived identity और human-managed billing relationship assume करते हैं।
- Manual checkout flows agent loop के अंदर tool calls के साथ fit नहीं होते।
- Prepaid credits help करते हैं, लेकिन still आपको usage reporting, overage handling, और reconciliation implement करना पड़ता है।
x402 appealing है क्योंकि यह agents के already operate करने के तरीके के साथ align करता है:
- Agent एक tool को call करता है।
- अगर tool currently usable नहीं है (missing auth, missing prerequisites, missing payment), तो tool structured error के साथ respond करता है।
- Agent (या इसका runtime) prerequisite को resolve करता है और फिर से try करता है।
Core x402 request flow (challenge, pay, retry)
High level पर, एक typical x402 flow कुछ इस तरह दिखता है:
- Agent एक normal HTTP request बनाता है API endpoint पर।
- API returns 402 Payment Required plus एक structured “payment required” payload।
- Agent (या payment component) payment execute करता है।
- Agent original request को retry करता है, proof of payment attach करके।
- API proof को validate करती है और 200 OK return करती है normal response के साथ।
“Payment challenge” के अंदर क्या होता है?
क्योंकि x402 एक pattern है, exact fields implementation के हिसाब से vary करते हैं, लेकिन challenge आमतौर पर communicate करता है:
- Price (amount, currency)
- Scope (यह payment exactly क्या buy करती है, उदाहरण के लिए one request, N tokens, 60 seconds का access)
- Payment method endpoint(s) (payment कहाँ भेजनी है)
- Expiry (quote कब तक valid है)
- एक correlation identifier जिसे server payment validate करते समय recognize करेगा
एक well designed challenge इतना explicit होता है कि client bina guess किए pay कर सकता है, और इतना narrow होता है कि इसे unrelated requests के लिए replay नहीं किया जा सकता।
x402 vs APIs को charge करने के अन्य तरीके
x402 एकमात्र option नहीं है। यहाँ agent-workflow perspective से एक practical comparison है।
| Approach | यह कैसे काम करता है | Pros | Agents के लिए Cons |
|---|---|---|---|
| API keys + monthly billing | Out-of-band pay करें, usage meter करें | Classic SaaS के लिए simple | Agents को still keys चाहिए, quota logic, overage behavior |
| Prepaid credits | Credits buy करें, per call decrement करें | Budgeting straightforward है | Still billing UI और reconciliation logic चाहिए |
| “Bring your own card” checkout | Per tool human checkout | Familiar UX | Autonomous flows को break करता है, tool-call friendly नहीं |
| x402 (402 challenge, pay, retry) | Need के moment पर pay करें | Fine-grained, automation-native | Idempotency, replay protection, और retries के लिए careful design चाहिए |
AI agent में x402 का उपयोग कैसे करें (client side)
Most teams agent runtime layer में x402 support implement करती हैं, prompt में नहीं।
एक अच्छा rule है: LLM decide करता है कि tool call cost के worth है या नहीं, लेकिन आपका code payment mechanics handle करता है।
1) Tool calls को “402 handler” के साथ wrap करें
आपके agent का HTTP client (या tool wrapper) 402 को recoverable state के रूप में treat करना चाहिए:
- Request attempt करें
- अगर 402 है, challenge parse करें
- Budget और policy check करें
- Pay करें
- Proof के साथ retry करें
यह payment logic को deterministic और testable रखता है।
2) Budgets और stop conditions add करें
Agents loop करेंगे। Loops में payments quickly expensive हो सकती हैं unless आप budgets enforce करें। Typical controls में शामिल हैं:
- Per-run budget (उदाहरण के लिए, max $2 per task)
- Per-tool budget (उदाहरण के लिए, max 10 paid calls to Tool X)
- Payment और underlying request के लिए max retry count
3) Retried requests को idempotent बनाएं
कोई भी “pay then retry” flow steps के बीच fail हो सकता है।
अगर client successfully pay करता है लेकिन retry request timeout हो जाता है, तो आपका system same action के लिए फिर से pay करने से avoid करना चाहिए unless यह explicitly allowed है।
Practice में इसका मतलब आमतौर पर होता है:
- Client underlying operation के लिए idempotency key भेजता है।
- Server payment proof को उस operation के साथ bind करता है।
(Exactly आप इन्हें कैसे encode करते हैं यह आपके implementation पर depend करता है, लेकिन invariants stable हैं।)
4) Payment proofs को secrets की तरह treat करें
अगर proof-of-payment एक bearer token है (या contain करता है), तो इसे API key की तरह protect करना चाहिए:
- इसे plaintext में log न करें।
- इसे LLM के सामने expose न करें unless आपके पास strong reason है।
- इसे केवल तब तक store करें जब तक जरूरी है।
API पर x402 कैसे implement करें (server side)
Server पर, आपका goal “pay, then retry” को real internet failure modes के under reliable बनाना है।
Purchase unit को design करें
इस बारे में explicit रहें कि one payment क्या buy करती है। Examples:
- Specific endpoint पर one request
- One “job” (submit और later retrieve)
- Access का small time window
Agent-facing APIs तब best work करती हैं जब unit small और deterministic होती है।
Payment को specific intent के साथ bind करें
एक common pitfall “anything” के लिए valid payment challenge issue करना है। यह replay को invite करता है।
Instead, इसे कम से कम इन चीजों के साथ bind करें:
- Endpoint और method
- Request hash (या canonical representation)
- Expiry
Verify, then fulfill
एक safe ordering है:
- Payment proof verify करें
- Request idempotency verify करें
- Request fulfill करें
- Normal response return करें
Partial failures के through think करें
आपका design इन जैसे questions का answer करना चाहिए:
- अगर client pay करता है लेकिन never retries करता है, तो क्या आप automatically refund करेंगे या later redemption allow करेंगे?
- अगर client same proof के साथ twice retries करता है, तो क्या second एक no-op है?
- अगर आपका payment processor down है, तो क्या आप fail closed (most common) करेंगे या grace access allow करेंगे?
Agent toolchains में x402 के लिए best practices
LLM को payment plumbing से बाहर रखें
अगर LLM directly payment requests construct कर रहा है, तो आपको risk है:
- Prompt injection causing unauthorized payments
- Payment credentials leak हो सकते हैं
- Non-deterministic behavior जो audit करना hard है
एक tool contract prefer करें जैसे: “यहाँ price है, approve या deny करें।” फिर code को rest handle करने दें।
Costs को agent के लिए visible बनाएं
Agents बेहतर decisions लेते हैं जब tool call में cost metadata include होता है। Consider exposing:
- Call से पहले estimated cost
- 402 challenge के अंदर confirmed cost
- Payment के बाद remaining budget
Auditability के लिए log करें
Minimum पर, log करें:
- Request id / correlation id
- Price quote id
- Payment confirmation id
- Idempotency key
- Final outcome (fulfilled, cancelled, expired)
यह “agent ने mysteriously money spend किया” और “हम every charge को explain कर सकते हैं” के बीच का difference है।
एक concrete example: “email verification” tool के लिए charging
बहुत सारे agent workflows को email की input channel के रूप में जरूरत होती है, उदाहरण के लिए sign-up verification, OTP retrieval, या SaaS integration tests।
अगर आप pay-per-use interface के behind email tool expose कर रहे हैं, तो x402 make sense कर सकता है:
- Agent request करता है: “एक inbox create करें और verification email का wait करें।”
- Server 402 और उस inbox session के लिए price के साथ respond करता है।
- Agent runtime pay करता है, फिर retry करता है।
- Server inbox provision करता है और inbox handle return करता है।
अगर आप email-driven automation build कर रहे हैं, तो Mailhook इन flows में commonly used inbox primitives provide करता है (API के via disposable inbox creation, structured JSON के रूप में emails receive करना, webhooks, polling fallback, signed payloads, batch processing, shared domains और custom domain support)। Canonical integration details के लिए, Mailhook का machine-readable reference use करें: llms.txt।
Common pitfalls (और उनसे कैसे बचें)
Replay attacks। अगर proof को different requests के लिए reuse किया जा सकता है, तो यह होगा। Proofs को narrow scope के साथ bind करें और उन्हें quickly expire करें।
Retries पर double charging। Assume करें कि timeouts और retries होंगे। Idempotency keys और consume-once semantics use करें।
Model को payment artifacts leak करना। Proofs, wallet credentials, और payment processor responses को prompts और tool outputs से बाहर रखें unless absolutely necessary।
Unbounded agent loops। Budgets, max retry counts, और “stop if price exceeds X” policies add करें।
अक्सर पूछे जाने वाले प्रश्न
क्या x402 एक official HTTP standard है? x402 community shorthand है payment flows के लिए जो HTTP 402 Payment Required use करते हैं। HTTP 402 spec में exist करता है, लेकिन payment protocol details universally standardized नहीं हैं।
क्या AI agents के लिए x402 payments implement करने के लिए crypto चाहिए? जरूरी नहीं। Defining idea 402 challenge, pay, retry pattern है। Underlying payment rail implementation के हिसाब से vary हो सकती है।
Agents कैसे decide करते हैं कि pay करना है या नहीं? Safest pattern policy-driven code है: budgets और allowlists enforce करें, फिर optionally LLM को quoted cost के based पर approved paid tools के among choose करने दें।
x402 implementation को retry के लिए safe क्या बनाता है? Idempotency। आपको stable operation identifier चाहिए ताकि “pay then retry” same intent के लिए twice charge न कर सके।
यह email inbox automation जैसे tool APIs से कैसे relate करता है? Agents को अक्सर reliable external interactions (email, SMS, data providers) के लिए paid tools की जरूरत होती है। x402 उन tools को per use meter करने का one way है, while flow को fully programmatic रखते हुए।
Agent-friendly tools build करें जो email को reliably handle कर सकें
अगर आपके agents या QA pipelines को deterministically email receive करने की जरूरत है, तो आप inboxes को human accounts के instead short-lived, programmable resources की तरह treat कर सकते हैं। Mailhook API के via disposable inboxes provide करता है और received emails को structured JSON के रूप में deliver करता है, webhooks (plus polling fallback) और security के लिए signed payloads के साथ।
Mailhook को mailhook.co पर explore करें, और exact integration contract और current capabilities के लिए, Mailhook के llms.txt से start करें।
