ऑटोमेटेड उपयोग

पहले Hushscript account खोलने के लिए कम से कम एक बार किसी व्यक्ति की ज़रूरत होती थी। अब यह पूरी कहानी नहीं है। एक payment-first flow किसी agent को अपना ही account खोलने, उसे fund करने, और उसे चलाने देता है, बीच में कहीं कोई human account holder नहीं। /developers और /mcp उन दो interfaces का दस्तावेज़ीकरण करते हैं जो यह account फिर use करता है; यह page एक पाने का walkthrough है।

Sign up

POST /v1/agent/accounts एक headless signup खोलता है। अभी कोई account नहीं है, कोई cookie नहीं, और कोई token नहीं: बस एक pending purchase।

curl -X POST https://api.hushscript.com/v1/agent/accounts \
  -H "Content-Type: application/json" \
  -d '{
    "contact_email": "ops@example-agent.dev",
    "pack_id": "300min",
    "accept_terms_version": "2026-08-01",
    "agent": {
      "name": "research-crawler",
      "platform": "langgraph",
      "contact_url": "https://example-agent.dev/bots/research-crawler"
    }
  }'

{
  "signup_id": "hsr1:eu:4c3a1f9e7b2d4e6f8a0c1b2d3e4f5061",
  "claim_secret": "cs_9f3d2a1b7e6c4f5a8b9d0e1f2a3b4c5d",
  "checkout_url": "https://checkout.stripe.com/c/pay/cs_test_a1B2c3D4e5F6",
  "pack": "300min",
  "amount": 599,
  "currency": "usd",
  "expires_at": 1789112400
}

contact_email सिर्फ़ receipts और notices के लिए है, कभी login के लिए नहीं। pack_id, 45min, 300min, 900min, 1800min, 6000min में से एक होता है; amount या currency कभी खुद न भेजें, दोनों server पर pack से derive होते हैं। सिर्फ़ दो सबसे छोटे packs, 45min और 300min, signup पर खरीदे जा सकते हैं। कोई बड़ा pack_id मना कर दिया जाता है, और उस refusal में details.allowed_packs भी होता है जो यह बताता है कि यह account अभी क्या खरीद सकता है, ताकि caller बिना guess किए retry कर सके। बाक़ी की ladder age के साथ unlock होती है, volume के साथ नहीं: नीचे कोई नया account क्या खरीद सकता है देखें। accept_terms_version को server के current policy version से बिल्कुल match करना चाहिए, वरना call policy_version_stale के साथ fail होती है, जो अपने body में current value बताती है। एक optional data_region hint तभी honor होता है जब वह उस region से सहमत हो जो आपकी network location पहले से बताती है। एक optional dry_run: true सब कुछ बिना किसी Stripe session और बिना किसी charge के validate करता है; इसका signup_id dry_ prefix के साथ आता है और कभी claim नहीं किया जा सकता।

claim_secret सिर्फ़ इसी response में, बस एक बार दिखाया जाता है। Hushscript सिर्फ़ इसका hash store करता है। claim call से पहले इसे खो देने का मतलब है signup को खो देना: किसी claim secret को recover करने का कोई रास्ता नहीं है, और escrow में रखा payment नीचे बताए गए sweep से refund होता है, किसी lookup से वापस नहीं मिलता।

अपने ही browser में checkout पूरा करें

checkout_url एक hosted Stripe Checkout page है। यह इस पूरे flow का इकलौता step है जिसे browser चाहिए, और यह किसी व्यक्ति का browser होना ज़रूरी नहीं: कोई agent इसे अपने ही automation से चला सकता है (card fields भरना, submit करना, redirect follow करना)। Hushscript कभी card details नहीं देखता, किसी भी तरह से; Stripe देखता है। इसे पूरा करने और फिर claim करने के लिए window 30 मिनट की है, ऊपर वाला expires_at।

जो signup paid हो जाता है पर कभी claim नहीं होता, उसे एक hourly sweep अपने आप refund कर देता है, उस 30 मिनट की window बंद होने के करीब एक घंटे बाद। refund पूरा होता है, क्योंकि minutes सिर्फ़ claim के समय ही किसी balance में credit होते हैं, इसलिए किसी unclaimed signup के पास consume करने के लिए कभी कुछ था ही नहीं।

Account claim करें

POST /v1/agent/accounts/{signup_id}/claim एक paid, unclaimed signup को एक call में एक असली account में बदल देता है।

curl -X POST https://api.hushscript.com/v1/agent/accounts/hsr1:eu:4c3a1f9e7b2d4e6f8a0c1b2d3e4f5061/claim \
  -H "Content-Type: application/json" \
  -d '{"claim_secret": "cs_9f3d2a1b7e6c4f5a8b9d0e1f2a3b4c5d"}'

{
  "user_id": "usr_7d1a2b3c4d5e6f708192a3b4c5d6e7f8",
  "pat": "hsr1:eu:pat.k3n2j1.8f7e6d5c4b3a29180716253443526170",
  "scopes": [
    "transcripts:read",
    "transcripts:write",
    "transcribe",
    "account:read",
    "export",
    "billing",
    "pat:rotate"
  ],
  "balance_seconds": 18000
}

Claim करना single use है। यह ठीक एक account बनाता है, जिसके पीछे एक synthetic, unresolvable login identity होती है, retry होने पर भी paid pack सिर्फ़ एक बार grant करता है, और ठीक एक PAT mint करता है: ऊपर वाला pat value, जो भी सिर्फ़ एक बार दिखाई जाती है।

गलत secret, कोई अनजान signup_id, पहले से claim हो चुका signup, कोई refund हो चुका signup, और कोई expire हो चुका signup, ये सब एक जैसा ही agent_claim_invalid error देते हैं। जानबूझकर, response से caller के लिए इन में फ़र्क़ बताने का कोई तरीका नहीं है। सिर्फ़ secret के सही निकलने के बाद ही payment state सामने आती है: कोई ऐसा Checkout Session जो अभी settle नहीं हुआ, इसके बजाय wrong_state देता है।

ऊपर वाला balance_seconds पूरा starting balance है। Agent accounts को न कोई welcome bonus मिलता है, न card verification से मिलने वाले मुफ़्त minutes, जैसे किसी व्यक्ति के पहले account को मिलते हैं; वे सिर्फ़ उस pack से शुरू होते हैं जो उन्होंने खरीदा। यह जानबूझकर है, कोई gap नहीं: account के exist करने से पहले ही इसका payment हो चुका था।

ज़्यादा minutes खरीदें

यहां से account किसी भी दूसरे account की तरह behave करता है, उसी /v1/ surface पर जिसे /developers पूरी तरह document करता है।

curl -X POST https://api.hushscript.com/v1/billing/purchase \
  -H "Authorization: Bearer hsr1:eu:pat.k3n2j1.8f7e6d5c4b3a29180716253443526170" \
  -H "Content-Type: application/json" \
  -d '{
    "pack": "300min",
    "quick_payment_method_id": "pm_1PqR2sT3uV4wX5yZ",
    "idempotency_key": "purchase-2026-09-11-01"
  }'

{
  "balance_seconds": 36000
}

इसके लिए billing scope चाहिए, जो ऊपर वाला claim response पहले ही दे चुका है, और यह card-saving route के साथ एक ज़्यादा tight 60 requests प्रति मिनट share करता है, उस Stripe call से पहले जो इनमें से कोई भी करता है।

कोई नया account क्या खरीद सकता है

Pack size settled payments की age पर unlock होती है, account कितना ख़र्च करता है उस पर नहीं। कोई purchase अगली tier की तरफ़ तभी गिना जाता है जब वह अपनी ही payment date से 7 दिन आगे निकल चुका हो, इसलिए कोई बिल्कुल नया account जल्दी खरीदारी करके बड़े packs तक नहीं पहुंच सकता।

कोई मना की गई purchase blind fail होने के बजाय details.allowed_packs में current set बताती है। signup call इस table की पहली row apply करती है, इसीलिए ऊपर वाला walkthrough 300min खरीदता है, कुछ बड़ा नहीं। ladder से अलग, एक rolling 24 घंटे का burn cap यह सीमित करता है कि वह balance कितनी तेज़ी से ख़र्च हो सकता है जो अभी dispute window से आगे नहीं निकला।

Transcribe करें

Upload करना और transcribe करना किसी भी दूसरे account जैसा ही multipart flow है।

curl -X POST https://api.hushscript.com/v1/uploads \
  -H "Authorization: Bearer hsr1:eu:pat.k3n2j1.8f7e6d5c4b3a29180716253443526170" \
  -H "Content-Type: application/json" \
  -d '{
    "size_bytes": 48213504,
    "duration_seconds": 1860,
    "title": "weekly-standup-2026-09-11",
    "idempotency_key": "upload-2026-09-11-01"
  }'

{
  "job_id": "job_3a2b1c0d9e8f7a6b5c4d3e2f1a0b9c8d",
  "part_urls": [
    { "n": 1, "url": "https://r2.hushscript.com/uploads/job_3a2b1c0d.../part-1?X-Amz-Signature=..." }
  ]
}

हर part को उसके presigned URL पर PUT करें, फिर भेजे गए हर part के n और etag के साथ उसी job के /complete पर POST करें। फिर job को poll करें:

curl https://api.hushscript.com/v1/jobs/job_3a2b1c0d9e8f7a6b5c4d3e2f1a0b9c8d \
  -H "Authorization: Bearer hsr1:eu:pat.k3n2j1.8f7e6d5c4b3a29180716253443526170"

{
  "id": "job_3a2b1c0d9e8f7a6b5c4d3e2f1a0b9c8d",
  "state": "done",
  "transcript_id": "trs_6f5e4d3c2b1a0908f7e6d5c4b3a29180"
}

curl https://api.hushscript.com/v1/transcripts/trs_6f5e4d3c2b1a0908f7e6d5c4b3a29180 \
  -H "Authorization: Bearer hsr1:eu:pat.k3n2j1.8f7e6d5c4b3a29180716253443526170"

{
  "id": "trs_6f5e4d3c2b1a0908f7e6d5c4b3a29180",
  "language": "en",
  "duration_seconds": 1860,
  "body": "..."
}

Credential rotate करें

किसी machine account का कोई password नहीं होता और कोई usable mailbox नहीं होता, इसलिए अगर कोई PAT leak हो जाए या बस बदलना पड़े, तो कोई “forgot your password” path नहीं है। Rotation ही वह path है।

curl -X POST https://api.hushscript.com/v1/agent/credentials/rotate \
  -H "Authorization: Bearer hsr1:eu:pat.k3n2j1.8f7e6d5c4b3a29180716253443526170"

{
  "pat": "hsr1:eu:pat.p9q8r7.1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d",
  "pat_id": "p9q8r7",
  "scopes": [
    "transcripts:read",
    "transcripts:write",
    "transcribe",
    "account:read",
    "export",
    "billing",
    "pat:rotate"
  ],
  "expires_at": null
}

इस call को कोई body नहीं चाहिए। यह atomically एक successor mint करता है और वह token revoke कर देता है जिसने request को authenticate किया था, इसलिए पुराना PAT उसके साथ की गई अगली ही call पर fail होता है। successor predecessor के scopes, billing permission, name, client label, और expiry policy रखता है। यह route सिर्फ़ caller के अपने token को छूता है: यह account के किसी और credential को list, mint, या revoke नहीं कर सकता। यह इकलौता credential-recovery path है जो किसी machine account के पास होता है, इसलिए पुराना token discard होने से पहले rotate करें, बाद में नहीं।

Errors

ये चार खासतौर पर agent accounts के लिए हैं और किसी human account पर कभी नहीं आतीं:

एक बार claim secret के सही निकल जाने के बाद, कोई unpaid Checkout Session agent_claim_invalid के बजाय wrong_state (4001) देता है। पूरा catalog OpenAPI document में है।

Limits

Calls 1,200 प्रति मिनट तक सीमित हैं। किसी agent account के लिए यह budget account का होता है, individual token का नहीं: rotation lineage का हर credential उसी एक budget पर draw करता है, इसलिए किसी PAT को rotate करने से successor को कोई नया allowance नहीं मिलता। दो billing writes, card save करना और pack खरीदना, एक ज़्यादा tight 60 प्रति मिनट प्रति account share करते हैं, उस Stripe call से पहले जो इनमें से कोई भी करता है। ऊपर वाला 24 घंटे का purchase cap भी इसी तरह गिना जाता है, प्रति credential के बजाय प्रति account।

और जानें

यह page account lifecycle cover करता है: उसे खोलना, fund करना, और उसका credential चालू रखना। account फिर जो भी कर सकता है, उसके लिए REST API देखें, जिसमें पूरा OpenAPI document भी शामिल है, या MCP server देखें, raw HTTP के बजाय tools पर वही account पाने के लिए।