Agents और scripts के लिए automatic transcription

Hushscript में automatic transcription पहले से मौजूद audio recording को editable transcript में बदलता है। Browser app में आप local video से भी शुरुआत कर सकते हैं: Hushscript आपके device पर उसका audio तैयार करता है और online recognition के लिए केवल वही audio भेजता है। परिणाम की समीक्षा और सुधार आप ख़ुद करते हैं: यह किसी व्यक्ति से proofread कराया गया या certified transcription देने वाली service नहीं है।

Automatic transcription कैसे काम करता है

1. Recording तैयार करें। Audio file इस्तेमाल करें, supported audio link import करें, या browser app में अपनी आवाज़ record करें। Video recordings के लिए local file चुनें ताकि app आपके device पर audio तैयार कर सके।
2. भेजें और transcript का इंतज़ार करें। App upload और status संभालता है। Agent REST API से तैयार audio को parts में upload कर सकता है या scoped MCP tools इस्तेमाल कर सकता है, फिर transcript तैयार होने तक job का status जाँच सकता है।
3. समीक्षा और export करें। App में transcript और speaker labels की editing करें, या API से text लें। Agent का token उसे दिए गए scopes के भीतर transcript export भी कर सकता है।

Audio और video के लिए automatic transcription software

Hushscript का automatic transcription software recording में बोली गई बातों को ऐसे text में बदलता है जिसे आप search, edit और export कर सकते हैं। App के record विकल्प से आप transcription से पहले voice recording भी बना सकते हैं। Transcription के बिना केवल recording file बनाने के लिए मुफ़्त वॉइस रिकॉर्डर इस्तेमाल करें।

App के local रूप से audio extract या convert करने के बाद automatic video transcription में वही text workflow चलता है। नीचे REST upload का उदाहरण तैयार audio से शुरू होता है; अपनी local video file app को देने के लिए वीडियो से टेक्स्ट का browser workflow इस्तेमाल करें।

क्या मैं automatic transcription मुफ़्त में आज़मा सकता हूँ?

हाँ। Sign in से पहले public preview एक file, supported audio link या browser recording के पाँच मिनट तक transcribe करता है। Browser के audio तैयार कर लेने के बाद local video भी काम करता है। Full transcription के लिए account चाहिए: पात्र personal account को card verification के बाद 30 मुफ़्त मिनट मिलते हैं (यह कैसे काम करता है, जानने के लिए कीमतें देखें)। Machine account को welcome मिनट नहीं मिलते; वह signup पर खरीदे गए pack से शुरू होता है।

API या MCP से transcript automation चलाएँ

Browser app recordings पर सीधे काम करने के लिए है। Transcript automation के लिए REST API और MCP server agent को तैयार audio upload करने, jobs जाँचने, transcripts लेने और परिणाम export करने देते हैं। Agent payment-first flow से अपना account खोल सकता है, बिना किसी human account holder के; hosted checkout के लिए फिर भी browser चाहिए, और card issuer authentication का step माँग सकता है। कोई व्यक्ति इसके बजाय app में मौजूदा account से scoped token बना सकता है। यह walkthrough machine account के signup से credential rotation तक का flow बताता है।

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-10-20",
    "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 से तय होते हैं। Signup पर केवल दो सबसे छोटे packs, 45min और 300min, खरीदे जा सकते हैं। बड़ा pack_id अस्वीकार कर दिया जाता है, और response के details.allowed_packs में वे packs दिए जाते हैं जो account अभी खरीद सकता है, ताकि caller बिना अनुमान लगाए retry कर सके। बाक़ी packs उम्र बढ़ने पर unlock होते हैं, खरीद की मात्रा बढ़ने पर नहीं: नीचे नया account क्या खरीद सकता है देखें। accept_terms_version server के current policy version से बिल्कुल match होना चाहिए, वरना call policy_version_stale के साथ fail होती है और response body में current value दी जाती है। Optional data_region hint तभी माना जाता है जब वह आपकी network location से पहले ही तय होने वाले region से मेल खाता हो। Optional dry_run: true बिना Stripe session बनाए और बिना charge के सब कुछ validate करता है; इसके signup_id में dry_ prefix होता है और इसे कभी claim नहीं किया जा सकता।

claim_secret इसी response में ठीक एक बार दिखाया जाता है। Hushscript केवल उसका hash रखता है। Claim call से पहले उसे खो देने पर signup भी खो जाता है: claim secret recover करने का कोई route नहीं है। Paid लेकिन unclaimed signup नीचे बताई गई धनवापसी की प्रक्रिया में जाता है; lookup से उसे recover नहीं किया जा सकता।

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

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

हर घंटे चलने वाला sweep, 30 मिनट की claim window और उसके बाद एक घंटे की grace अवधि बीतने पर paid लेकिन unclaimed signups जाँचता है। यह पूरी धनवापसी का प्रयास करता है, क्योंकि मिनट claim के समय ही credit होते हैं। विफल refund attempts दोबारा किए जाते हैं और उन्हें manually संभालने की ज़रूरत पड़ सकती है; धनवापसी किसी तय समय पर मिलने की guarantee नहीं है।

Account claim करें

POST /v1/agent/accounts/{signup_id}/claim एक call में paid लेकिन unclaimed signup को वास्तविक 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 से ठीक एक account बनता है, जिसकी login identity synthetic होती है और resolve नहीं की जा सकती। Request को जितनी बार भी retry किया जाए, paid pack ठीक एक बार मिलता है। यह एक PAT बनाता है: ऊपर का pat value।

Response खो जाए तो वही claim_secret देकर call दोहराएँ। Claim के एक घंटे के भीतर, और जब तक उससे जारी token कभी इस्तेमाल नहीं हुआ, retry उसी account के लिए वही response shape और नया pat लेकर 201 लौटाता है। खोया हुआ token काम करना बंद कर देता है। Token के पहले इस्तेमाल के बाद, या उस घंटे के बाद, retry का जवाब agent_claim_invalid होता है। जो retry अभी चल रहे claim से टकराए, उसे Retry-After header के साथ 429 rate_limited मिल सकता है; उस delay के बाद retry करें।

पहला token transcribe कर सकता है, transcripts पढ़ और edit कर सकता है, export कर सकता है, account balance पढ़ सकता है, मिनट खरीद सकता है और ख़ुद को rotate कर सकता है। इससे Insights, context, organization या settings-write scopes नहीं मिलते। MCP server केवल token के scopes में आने वाले tools देता है।

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

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

और मिनट खरीदें

यहाँ से account /v1/ surface इस्तेमाल करता है, जिसका पूरा दस्तावेज़ीकरण /developers में है।

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 से पहले ही मिला है। Claim token और account पर billing भी चालू करता है; किसी व्यक्ति के बनाए token के लिए billing scope और दोनों billing switches चालू होने चाहिए। Stripe को call करने वाले billing routes पर PAT billing calls की साझा, अधिक सख़्त सीमा प्रति account 60 requests प्रति मिनट है; जाँच उनके Stripe requests से पहले होती है।

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

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

Purchase अस्वीकार होने पर केवल fail होने के बजाय details.allowed_packs में अभी उपलब्ध packs दिए जाते हैं। Signup call इस table की पहली row लागू करती है, इसलिए ऊपर walkthrough में 300min खरीदा जाता है, कोई बड़ा pack नहीं। इस ladder से अलग, rolling 24 घंटे का burn cap तय करता है कि ऐसा balance कितनी तेज़ी से ख़र्च किया जा सकता है जो अभी dispute window से आगे नहीं पहुँचा है। Signup purchase account की rolling 24 घंटे में तीन purchase attempts की सीमा में गिनी जाती है; reservation के बाद declined attempts भी गिनी जाती हैं।

Transcribe करें

Upload और transcription के लिए वही multipart flow है जो किसी भी दूसरे account के लिए है। API का उदाहरण तैयार audio भेजता है; वह local video की source file upload नहीं करता।

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 करें, फिर उसी job पर POST करें: उसके /complete route को इसी तरह भेजे गए हर part का n और etag दें। फिर 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 और इस्तेमाल करने लायक mailbox नहीं होता। इसलिए PAT leak हो जाए या उसे बदलना हो, तो “password भूल गए” वाला रास्ता नहीं है। इसके लिए rotation का रास्ता है।

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 नहीं भेजनी होती। यह request authenticate करने वाले token के लिए successor बनाती है। Successor में पुराने token के scopes, billing permission, name, client label और expiry policy बने रहते हैं। यह route केवल caller के अपने token को बदलता है: account के किसी अन्य credential को list, mint या revoke नहीं कर सकता। Machine account के लिए credential recovery का यही एक रास्ता है, इसलिए पुराने token को discard करने से पहले rotate करें, बाद में नहीं।

पुराना token तुरंत revoke नहीं होता। Rotate के बाद वह सिर्फ़ एक काम के लिए चलता है: दोबारा rotate call करने के लिए। यह तब तक रहता है जब तक नया token अपनी पहली सफल request न कर ले या एक घंटा न बीत जाए, जो भी पहले हो। बाक़ी हर route पर पुराना token तुरंत 401 देता है।

अगर नया token लाने वाला response खो जाए, तो जब तक नया token इस्तेमाल नहीं हुआ, पुराने token से दोबारा rotate call करें। आपको उसी pat_id के लिए नया secret मिलता है, और पहले वाला नया secret काम करना बंद कर देता है।

नया token एक बार चल जाने तक पुराना token रखें। फिर नए token से तुरंत एक call करें, जैसे GET /v1/account। वह पहली सफल request पुराने token को हमेशा के लिए retire कर देती है।

Errors

ये errors agent signup और purchase controls से जुड़े हैं। Purchase cap किसी व्यक्ति के account पर PAT से की गई purchases पर भी लागू होता है; human session से की गई purchase इससे मुक्त है।

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

सीमाएँ

Calls की सीमा 1,200 प्रति मिनट है। Agent account में यह budget account का होता है, अलग-अलग token का नहीं: rotation lineage के सभी credentials वही budget इस्तेमाल करते हैं, इसलिए PAT rotate करने पर successor को नया allowance नहीं मिलता। Stripe तक पहुँचने वाली PAT billing calls की साझा, अधिक सख़्त सीमा प्रति account 60 प्रति मिनट है। इसमें setup और purchase, default card बदलना और card हटाना, तथा card-list cache misses शामिल हैं; जाँच Stripe call से पहले होती है। ऊपर का 24 घंटे का purchase cap भी इसी तरह प्रति account गिना जाता है, प्रति credential नहीं।

और जानें

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