ElevenAPI के लिए API ऑथेंटिकेशन और की मैनेजमेंट

API authentication वह तरीका है जिससे कोई सेवा यह पुष्टि करती है कि आने वाले अनुरोध को किसी अकाउंट पर कार्रवाई करने की अनुमति है। उदाहरण के लिए, ElevenAPI के साथ, API क्रेडेंशियल उन अनुरोधों को अधिकृत करते हैं जो मीटर्ड क्रेडिट खर्च करते हैं, बड़े पैमाने पर स्पीच और संगीत जनरेट करते हैं और कुछ डिप्लॉयमेंट में संवेदनशील ऑडियो तक पहुँचते हैं।

लीक हुई key से पैसे खर्च हो सकते हैं और आपके अकाउंट के नाम पर कंटेंट जनरेट किया जा सकता है। यह आपके प्लेटफ़ॉर्म पर जरूरत से ज़्यादा अनुमतियों वाली पहुँच भी दे सकती है, जिससे डेटा लीक और अन्य अटैक वेक्टर की संभावना बनती है। 2020 में भी, 90% से ज़्यादा डेवलपर कम-से-कम एक रोज़ाना प्रक्रिया में APIs इस्तेमाल करते थे। अब मॉडल कॉन्टेक्स्ट प्रोटोकॉल्स (MCPs) और AI के बढ़ते उपयोग के साथ APIs हर जगह हैं।

यह लेख बताता है कि APIs को सही तरह से authenticate कैसे करें और keys के पूरे lifecycle में उनका प्रबंधन कैसे करें: scoping, rotation, संगठनात्मक नियंत्रण, auditing और incident response। इससे आप अपनी टीम में API authentication और key management सही तरीके से सेट अप कर पाएंगे। पढ़ते समय संदर्भ के लिए authentication reference और single-use tokens reference खुले रखें।

सारांश

• ElevenAPI हर अनुरोध को एक ही secret, यानी xi-api-key header, से authenticate करता है। इसका मतलब है कि key रखने वाला कोई भी व्यक्ति क्रेडिट खर्च कर सकता है और अकाउंट के नाम पर ऑडियो जनरेट कर सकता है।
• लंबे समय तक वैध रहने वाली API key को कभी browser, mobile app या ऐसी किसी चीज़ में शामिल न करें जिसे यूज़र देख सके। इन्हें अपने नियंत्रित server पर रखें।
• Client-side उपयोग के मामलों में server-side बनाए गए कम समय तक वैध, single-use tokens से authenticate करें, लंबे समय तक वैध key से कभी नहीं।
• Keys को न्यूनतम आवश्यक अनुमतियों तक सीमित करके, हर environment के लिए अलग keys रखकर और तय शेड्यूल पर rotation करके आप लीक का असर कम कर सकते हैं।
• Auditing और anomaly detection, key leaks और अप्रत्याशित समस्याओं को रोकने में मदद करते हैं।

API authentication क्या है?

API authentication वह तरीका है जिससे कोई सेवा काम शुरू करने से पहले पुष्टि करती है कि आने वाले अनुरोध को किसी खास अकाउंट पर कार्रवाई करने की अनुमति है। अनुरोधकर्ता क्रेडेंशियल देता है, सेवा उसका सत्यापन करती है और सत्यापन के बाद जवाब देती है।

सरल शब्दों में, यह सवाल पूछता है: क्या इस अनुरोध को इस अकाउंट की ओर से कार्रवाई करने की अनुमति है? ध्यान दें कि यह प्रक्रिया API authorization से अलग है, जो तय करता है कि authenticated अनुरोध को आपके सिस्टम में क्या करने की अनुमति है।

Key management क्या है?

Key management उन व्यापक तरीकों को कहते हैं जिनसे आप API key के पूरे lifecycle को नियंत्रित करते हैं। इससे तय होता है कि keys कैसे बनाई, स्टोर, इस्तेमाल, rotate और revoke की जाती हैं। ये सिस्टम API key की शुरू से अंत तक सुरक्षा के लिए होते हैं।

मज़बूत key management सिस्टम से आप keys के लीक होने से बच सकते हैं और उनके सार्वजनिक रूप से उपलब्ध होने का जोखिम घटा सकते हैं।

API key सुरक्षा क्यों ज़रूरी है: थ्रेट मॉडल

अब authentication और key management की परिभाषा स्पष्ट है, तो यह समझना ज़रूरी है कि key को गलत तरीके से संभालने पर क्या गड़बड़ होती है। पहले थ्रेट मॉडल देखने से आगे बताई गई हर प्रक्रिया का उद्देश्य साफ़ होता है: हर एक या तो key leak होने की संभावना कम करती है या leak होने पर उसका नुकसान।

ElevenAPI एक secret-आधारित तरीके, xi-api-key header, से authenticate करता है। जिसके पास key है, वह अधिकृत है और अनुरोध में कोई दूसरा factor नहीं होता।

आपकी key से वे आपके क्रेडिट खर्च कर सकते हैं। टेक्स्ट टू स्पीच, स्पीच टू टेक्स्ट, संगीत और साउंड इफेक्ट्स सभी मीटर्ड हैं, और वैध key वाला हमलावर आपके quota या balance खत्म होने तक लगातार जनरेशन कर सकता है।

वे बड़े पैमाने पर जनरेशन कर सकते हैं, और हमारा rate-limiting मॉडल इस स्थिति को दिखने से अधिक गंभीर बनाता है। सीमा साधारण requests-per-minute quota पर नहीं, concurrency पर आधारित है। किसी model family के लिए concurrency limit पाँच वाले plan की key पर्याप्त संख्या में एक साथ generation चला सकती है, और इन सीमाओं को समझने वाला हमलावर दुरुपयोग को parallelize करेगा।

वे आपके अकाउंट के नाम पर कंटेंट बना सकते हैं। आपकी key से जनरेट हुआ हर ऑडियो आपके workspace से जुड़ा होता है और शामिल voices व inputs के आधार पर यह प्रतिष्ठा से जुड़ी, और कभी-कभी कानूनी, चिंता बन सकता है।

Keys के लीक होने के तरीके साधारण हैं और वही failure modes हैं जिनसे हर तरह के क्रेडेंशियल लीक होते हैं:

• Client-side code में API keys: Browser bundle, mobile binary या single-page app में भेजी गई key व्यावहारिक रूप से सार्वजनिक होती है। Minification, obfuscation नहीं है।
• Repositories में API keys: Git में commit की गई hardcoded keys, जिनमें private repos भी शामिल हैं जो बाद में public हो जाएं या व्यापक रूप से clone किए जाएं, और .env जैसी वे files भी जिन्हें कभी track नहीं किया जाना था।
• Logs और traces में API keys: Request loggers, error trackers और observability pipelines अक्सर HTTP headers capture करते हैं। xi-api-key की key आपके log store, APM vendor और इन दोनों की read access रखने वाले हर व्यक्ति तक पहुँच जाती है।
• CI और screenshots में API keys: Build logs, support tickets और shared terminals।

नीचे का हर section इनमें से किसी एक की संभावना या प्रभाव घटाने से जुड़ा है।

मुख्य नियम: API keys को server-side रखें

इस लेख की बाकी सभी बातें API key authentication और management के जोखिम को घटाने की जानकारी देती हैं। यह एक नियम उसकी नींव है और आपको इसे सबसे पहले लागू करना चाहिए।

तरीका इतना सरल है कि मुख्य नियम यही है: लंबे समय तक वैध API key सिर्फ़ आपके नियंत्रित server पर होनी चाहिए। इसे कभी browser, mobile app, desktop client या ऐसी किसी चीज़ में शामिल न करें जिसे यूज़र डाउनलोड करके देख सके। अगर key client-side code में है, तो उसे पहले से compromised मानें।

SDK ELEVENLABS_API_KEY को अपने-आप पढ़ता है, इसलिए सबसे साफ़ code में कुछ भी pass नहीं किया जाता और client को एक बार initialize किया जाता है।

import { ElevenLabsClient } from "@elevenlabs/elevenlabs-js";

// Reads process.env.ELEVENLABS_API_KEY when apiKey is omitted - never a literal.
const elevenlabs = new ElevenLabsClient();

const audio = await elevenlabs.textToSpeech.convert("JBFqnCBsd6RMkjVDRZzb", {
  text: "Generated entirely server-side.",
  modelId: "eleven_flash_v2_5",
  outputFormat: "mp3_44100_128",
});

Production में इसे process start पर secret manager (AWS Secrets Manager, GCP Secret Manager, HashiCorp Vault या आपके प्लेटफ़ॉर्म के समकक्ष) से लोड किया जाना चाहिए, न कि image में शामिल करके या repo में commit की गई .env से।

Client-side apps के लिए single-use tokens

मुख्य नियम पूरी तरह लागू होता है, लेकिन कई वैध उपयोग के मामलों में client को खुद ElevenAPI तक पहुँचना होता है: streamed टेक्स्ट टू स्पीच चलाने वाला browser, transcription के लिए ऑडियो capture करने वाला mobile app और यूज़र के tab में चल रहा real-time agent। लंबे समय तक वैध key वहाँ नहीं जा सकती। समाधान है client को ऐसा क्रेडेंशियल देना जिसका लीक होना कम जोखिम वाला हो: कम समय तक वैध, single-use token।

आपका server लंबे समय तक वैध key रखता है, आपके अपने session logic से यूज़र को authenticate और authorize करता है, फिर कम समय तक वैध token बनाकर सिर्फ़ वही client को देता है। Token जल्दी expire हो जाता है और सिर्फ़ उसी कार्रवाई तक सीमित होता है जिसके लिए जारी हुआ था, इसलिए लीक हुआ token जल्द ही बेकार हो जाता है। समर्थित endpoints और सटीक request shape के लिए single-use tokens reference देखें।

यह broker endpoint का आवश्यक logic है। यह आपके session logic से यूज़र को authorize करता है, फिर documented tokens endpoint पर token बनाता है। अनुरोध server से लंबे समय तक वैध xi-api-key के साथ जाता है और client को सिर्फ़ उससे बना कम समय तक वैध token वापस मिलता है।

// ... express app and route boilerplate
app.post("/api/voice-token", async (req, res) => {
  // 1. Authorize the user with YOUR session/auth system first.
  if (!req.session?.user) return res.status(401).json({ error: "unauthorized" });

  // 2. Mint a short-lived token server-side. The long-lived key travels only
  //    in this server-to-server request, never to the browser.
  const response = await fetch("https://api.elevenlabs.io/v1/tokens", {
    method: "POST",
    headers: {
      "xi-api-key": process.env.ELEVENLABS_API_KEY as string,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({}), // populate per the tokens reference
  });

  // 3. Return only the short-lived token. The API key never leaves the server.
  res.json({ token: await response.json() });
});

फिर browser उस token से connect करता है और लंबे समय तक वैध key कभी page में नहीं आती।

Keys को न्यूनतम आवश्यक अनुमतियों तक सीमित करना

Least privilege का सिद्धांत कहता है कि हर key में सिर्फ़ उसके काम के लिए ज़रूरी permissions हों, उससे ज़्यादा नहीं। ElevenAPI आपको permissions-आधारित कई restrictions लागू करने देता है, जो तय करते हैं कि key क्या कर सकती है और क्या नहीं।

एक ही सर्वशक्तिशाली key लीक के असर के लिहाज़ से सबसे खराब स्थिति है, और यह आसान default भी है। बेहतर तरीका है मानकर चलना कि कोई भी key कभी न कभी leak होगी और यह सुनिश्चित करना कि ऐसा होने पर वह सिर्फ़ उतना ही कर सके जितना काम के लिए ज़रूरी है।

Scope restriction से शुरू करें, जो यह सीमित करता है कि key किन API endpoints को call कर सकती है। सिर्फ़ transcription के लिए इस्तेमाल होने वाली key को टेक्स्ट टू स्पीच access की ज़रूरत नहीं है; संगीत feature की key को voice management तक पहुँचने की ज़रूरत नहीं है।

अगला है credit quota। हर key के लिए custom credit limit तय करने से leak होने पर वित्तीय नुकसान सीमित होता है और आपके code में runaway loops भी नियंत्रित रहते हैं।

IP whitelisting इससे भी आगे जाती है। आप key को खास IP addresses या CIDR ranges तक सीमित कर सकते हैं और whitelist में शामिल न होने वाले IPs के अनुरोधों को 403 के साथ reject किया जाता है। यह Enterprise feature अभी preview में है और आपके account manager के ज़रिए उपलब्ध है।

अंत में, development, staging और production के बीच एक ही key शेयर न करें। हर environment के लिए अलग key जारी करें, हर एक का अपना scope और quota हो। Per-environment keys डेवलपर के laptop पर हुए leak को production credits से दूर रखती हैं, एक environment को rotate करने देती हैं बिना बाकी को प्रभावित किए, और usage logs को समझना आसान बनाती हैं क्योंकि traffic पहले से origin के आधार पर अलग होता है।

API key rotation

Key rotation का मतलब है नियमित रूप से किसी key को नई key से बदलना। जब भी आपको breach या exposure का संदेह हो, आप यह कार्रवाई कर सकते हैं।

शेड्यूल के अनुसार rotation करने से वह समय भी कम होता है जिसमें बिना पकड़े गए leak का दुरुपयोग हो सकता है। Rotation तभी आसान होता है जब आपका code उसके लिए बनाया गया हो, इसलिए ज़रूरत पड़ने से पहले इसके लिए डिज़ाइन करें।

मुख्य तकनीक overlapping keys है, जिससे बिना downtime के cutover होता है:

1. नई API key बनाएं: मौजूदा key के साथ समान scope, quota और IP restrictions वाली नई key provision करें। अब दोनों वैध हैं।
2. Key अपडेट करें: अपने secret manager में secret अपडेट करके और instances को उसे लेने देकर नई key roll out करें (आपके setup के आधार पर restart, re-read या secret-manager refresh)।
3. Traffic की पुष्टि करें: पुष्टि करें कि traffic नई key पर चल रहा है। यह पक्का करने के लिए usage देखें कि पुरानी key निष्क्रिय हो गई है।
4. Key access हटाएं: सुरक्षित समय तक कोई traffic न दिखने पर पुरानी key revoke कर दें।

Overlap के दौरान दोनों keys वैध होती हैं, इसलिए क्रेडेंशियल न होने से अनुरोध कभी fail नहीं होते। Overlap window का दूसरा लाभ है: गलत configuration वाला instance पुरानी key इस्तेमाल करता रहेगा, जिससे उस key को बंद करने से पहले आप उसे ढूँढ सकते हैं।

Overlap को बिना किसी परेशानी के चलाने के लिए code को इस तरह बनाएं कि rotation configuration change हो, code change नहीं। Key को एक ही जगह से पढ़ें, जहाँ उसे refresh किया जा सके, और एक switch से तय होने दें कि कौन-सा secret live है।

// Rotation is driven by configuration, not code edits. The secret manager (or
// the deploy that injects env vars) is the single point of change.
// ELEVENLABS_KEY_ACTIVE selects which slot is live, enabling overlap.
let client: ElevenLabsClient | undefined;

function activeKey(): string {
  const slot = process.env.ELEVENLABS_KEY_ACTIVE ?? "primary";
  const name = slot === "primary" ? "ELEVENLABS_API_KEY_PRIMARY" : "ELEVENLABS_API_KEY_SECONDARY";
  return process.env[name] as string;
}

function getClient(): ElevenLabsClient {
  return (client ??= new ElevenLabsClient({ apiKey: activeKey() }));
}

// Call after a secret refresh to pick up the rotated key without a deploy.
function resetClient(): void {
  client = undefined;
}

Overlap के दौरान PRIMARY और SECONDARY, दोनों populated रखें और ELEVENLABS_KEY_ACTIVE को flip करें। Application code कभी नहीं बदलता।

Cadence के लिए, backend keys का हर 90 दिन में नियमित rotation एक उचित default है; high-value या व्यापक रूप से access की जाने वाली keys के लिए ज़्यादा बार, और किसी भी exposure पर तुरंत। इसे scheduled job से automate किया जा सकता है जो provision, roll, verify और revoke करे, जिससे rotation किसी event के बजाय background process बन जाता है।

Workspace access controls और permissions

जहाँ scoping और rotation अलग-अलग keys को सुरक्षित रखते हैं, वहीं workspace controls तय करते हैं कि शुरुआत में उन्हें कौन बना सकता है। इससे संगठनात्मक नीति बनाने और उसका पालन करने की जगह मिलती है, जो आगे आपकी सभी key management प्रक्रियाओं को प्रभावित करेगी।

Human और machine credentials को अलग करके शुरू करें। लोग अपने accounts और permissions से dashboard में sign in करें; services keys या, बेहतर विकल्प के रूप में, service accounts से authenticate हों। किसी service को किसी व्यक्ति की personal access से बनाई गई key पर न चलने दें और लोगों को एक machine key शेयर न करने दें। कारण है offboarding: जब कोई व्यक्ति जाता है या कोई service retire होती है, तो आप बिना बाकी पर असर डाले ठीक वही credential revoke करना चाहते हैं।

Service accounts का लक्ष्य भी यही है। वे machine workloads को ऐसी पहचान देते हैं जो किसी व्यक्ति से जुड़ी नहीं होती, अपने scoping के साथ, जिससे आपका audit trail सटीक रहता है।

फिर access को एक-एक व्यक्ति के बजाय roles से map करें। Workspaces इसी के लिए group और member permissions support करते हैं। हर group को काम के लिए आवश्यक न्यूनतम अनुमति दें, समय-समय पर membership की समीक्षा करें और ऐसी व्यवस्था रखें जहाँ कोई भी एक credential, human हो या machine, अपनी role की ज़रूरत से ज़्यादा न कर सके।

Audit और detection

पिछले चरणों में हमने बताया कि leak से होने वाला नुकसान कैसे कम करें। इस चरण में हम बताएंगे कि सबसे पहले leak हुआ है या नहीं, यह कैसे पता करें। अच्छी detection तीन आदतों पर टिकी है।

पहली आदत है रिकॉर्ड करना कि किस key ने (identifier से, secret value से कभी नहीं) किस तरह के अनुरोध को, कहाँ से और कितनी मात्रा में serve किया। हर logging और tracing layer से xi-api-key header हटा दें। आपके HTTP middleware और APM configuration में redaction rule, keys के log stores तक पहुँचने के सबसे आम तरीके को रोक देता है।

दूसरी आदत है anomalies के लिए credit consumption monitor करना। समय के साथ हर key का credit usage track करें और baseline से विचलन पर alert दें: अचानक spike, असामान्य समय पर generation या ऐसी key का अचानक सक्रिय होना जिसे निष्क्रिय रहना था।

तीसरी आदत है concurrency headers देखना। हम हर response में current-concurrent-requests और maximum-concurrent-requests headers में मौजूदा और अधिकतम concurrent requests लौटाते हैं। ये बताते हैं कि आपके पास कितनी headroom है, और अधिकतम सीमा पर लगातार पहुँचना जिसे आपने शुरू नहीं किया, दुरुपयोग का मज़बूत संकेत है। Raw HTTP endpoint इस्तेमाल करने पर response headers सीधे मिलते हैं:

const resp = await fetch("https://api.elevenlabs.io/v1/text-to-speech/JBFqnCBsd6RMkjVDRZzb", {
  method: "POST",
  headers: {
    "xi-api-key": process.env.ELEVENLABS_API_KEY as string,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({ text: "Monitoring headroom.", model_id: "eleven_flash_v2_5" }),
});

const current = resp.headers.get("current-concurrent-requests");
const maximum = resp.headers.get("maximum-concurrent-requests");
// Emit these to your metrics pipeline; alert on sustained saturation you did not cause.

इनसे alerts trigger होने चाहिए। ऐसा dashboard जिसे कोई नहीं देखता, detection नहीं देता। स्पष्ट owner के साथ credit-spike और concurrency-saturation signals को उसी alerting path में जोड़ें जिसका उपयोग आप outages के लिए करते हैं।

Incident response

बेहतरीन सुरक्षा और monitoring systems होने पर भी आपको मानकर चलना चाहिए कि कोई key आखिरकार leak होगी। नुकसान सीमित करने वाले चरणों की सूची के साथ पहले से योजना बनाने पर आपके पास ऐसा response roadmap होता है जो समय बचाता है और प्रभाव कम करता है।

API key exposure के लिए पहले से तय incident response pathway यह है:

1. लीक हुई key तुरंत revoke करें: पूरा scope समझने का इंतज़ार न करें। Revoked key जनरेशन नहीं कर सकती और आप हमेशा replacement जारी कर सकते हैं। यह सबसे महत्वपूर्ण कार्रवाई है।
2. नई key पर rotate करें: अगर लीक हुई key production traffic serve कर रही थी, तो overlap प्रक्रिया को उलटे क्रम में अपनाएं: नई key शुरू करें, traffic switch करें, फिर पुष्टि करें कि लीक हुई key बंद है। आपका code key को configuration से पढ़ता है, इसलिए यह config flip है, code change नहीं।
3. Usage logs से blast radius का आकलन करें: Leak को नियंत्रित करने के बाद उसका आकलन करें। Key कितने समय तक वैध और exposed थी? उस दौरान कितने credits खर्च हुए और क्या pattern वैध traffic या दुरुपयोग से मेल खाता है? उसने किन endpoints को access किया?
4. निर्भर secrets को rotate करें: Key शायद ही कभी अकेले leak होती है। अगर वह repo, log store या CI pipeline में exposed हुई थी, तो मानें कि उसी जगह के आसपास के secrets भी exposed हैं और उन्हें भी rotate करें।
5. Leak path बंद करें: पता लगाएं कि key कैसे बाहर गई और उसे ठीक करें, वरना यह फिर होगा: file को .gitignore में जोड़ें और history purge करें, logger में header redaction जोड़ें, secret को build artifact से बाहर निकालें और CI system तक access कड़ा करें।
6. Post-mortem लिखें: Timeline, blast radius, root cause और जोड़े गए ठोस controls दर्ज करें (scope tightening, IP whitelisting, CI में secret scanner और तेज़ rotation cadence)।

इन चरणों का पालन करके API exposure से जुड़े आपदा-परिदृश्यों के लिए आपके पास एक तैयार प्रक्रिया होगी।

Compliance स्थिति: SOC 2, HIPAA और data retention

Authentication व्यापक compliance evaluation का एक हिस्सा है और यहाँ क्या दावा किया जा सकता है या नहीं, इस पर सावधानी ज़रूरी है। नीचे दिए बिंदुओं को आपके उपयोग के मामले के निर्धारण के रूप में नहीं, बल्कि तथ्यात्मक शुरुआती जानकारी के रूप में लें।

ElevenLabs SOC 2 compliant है। योग्य plans और उपयोग के मामलों के लिए HIPAA compliance और zero-retention modes उपलब्ध हैं। Zero-retention का मतलब है कि processing के बाद request content स्टोर नहीं किया जाता, जो आपके inputs या जनरेट किया गया ऑडियो संवेदनशील होने पर महत्वपूर्ण है।

कोई mode लागू होगा या नहीं, यह आपके plan, configuration और आप क्या process कर रहे हैं, उसके विवरण पर निर्भर करता है। इनमें से किसी पर निर्भर होने से पहले अपने अकाउंट की eligibility और सटीक शर्तों की पुष्टि करें, और इन्हें ऊपर बताए गए access controls के साथ इस्तेमाल करें। Compliance certifications यह नियंत्रित करते हैं कि प्लेटफ़ॉर्म आपका data कैसे संभालता है; key management यह नियंत्रित करता है कि आपकी ओर से कौन कार्रवाई कर सकता है, और वह हिस्सा आपकी ज़िम्मेदारी है।

अच्छी API key सुरक्षा कैसी दिखती है

सिर्फ़ server-side keys सबसे बड़े leak surface को हटा देती हैं। Single-use tokens उन clients तक यह सुरक्षा बढ़ाते हैं जिन्हें सच में हमारे API तक पहुँचना होता है। Scoping और per-environment separation किसी एक leak के नुकसान को सीमित करते हैं। Configuration में शामिल rotation, recovery को जोखिम भरा नहीं बल्कि नियमित बनाता है। Workspace controls human और machine identities को अलग रखते हैं। Auditing दुरुपयोग को बिल पर चौंकाने वाली चीज़ के बजाय alert में बदल देता है। लिखी हुई runbook incident को एक प्रक्रिया में बदल देती है।

यह वही credential hygiene है जो किसी भी high-value secret को सुरक्षित रखती है, और इसे ऐसी key पर लागू किया गया है जिसकी खासियत यह है कि वह पैसे खर्च करती है और बड़े पैमाने पर ऑडियो जनरेट करती है।

जब आप इसे वास्तविक request shapes के साथ जोड़ने के लिए तैयार हों, तो authentication reference और single-use tokens reference में supported endpoints की मौजूदा सूची है। आपके monitoring को जिस concurrency model को track करना चाहिए उसे समझने के लिए models reference और API quickstart अगले सही संसाधन हैं।

अपने ElevenAPI integration को सुरक्षित करें

मज़बूत API authentication एक बुनियादी नियंत्रण है, जिस पर कई अन्य सुरक्षा प्रक्रियाएँ टिकी होती हैं। सिर्फ़ server-side keys इस्तेमाल करना, clients के लिए single-use tokens deploy करना, least privilege scoping और key management में rotation शामिल करना जैसे कदम बड़े पैमाने पर जोखिम रोकने में मदद करते हैं।

Supported endpoints और इस्तेमाल किए जाने वाले सटीक header format की अधिक जानकारी के लिए ElevenAPI documentation देखें। शुरू करने के लिए तैयार हैं, तो आज ही बनाना शुरू करने हेतु ElevenLabs से API key का अनुरोध करें।

API authentication और key management के बारे में FAQs