API को कैसे ऑथेंटिकेट करते हैं?

Most APIs authenticate each request by using a secret credential that the server references before responding. The requester sends their API key in a request header, which the server then validates and checks permissions for. The server will either fulfill the request or completely reject it based on whether that API key is allowed to act on a given account.

API की को कैसे स्टोर करना चाहिए?

The best way to store an API key is within a secret manager, loading it into your active environment whenever needed. Committing a key to a repository or shipping it in an inspectable artifact would potentially expose the key. Never use long-lived keys on client-side applications.

API की रोटेशन क्या है?

An API key rotation is the process of replacing an existing key with a new one at a regular interval or whenever a breach is suspected by your team. Rotating keys are a low-effort method of reducing the total time an undetected leak can use a key for. If you overlap the old and new keys for a brief validation window, API key rotation can work without introducing any downtime to your system.

API कीज़ के साथ ऑथेंटिकेशन और ऑथराइजेशन में क्या फर्क है?

API authentication is a process that confirms the person making a request has access. Authorization then decides what that person can do within your system after they have access. API keys do both at once: checking for access and validating the scope of endpoints it can reach or, in some systems, how many credits it can spend.

क्लाइंट-साइड ऐप्स में API कीज़ को कैसे सुरक्षित रखें?

The most effective way of securing API keys in client-side apps is by holding the key on your server, authenticating the user with your own session logic, then minting a single-use, short-lived token that you give to the client. Never use a long-lived key on anything shipped to the client, as this could essentially become public.

कॉन्टेंट पर जाएं

लॉग इन करें साइन अप करें

संपर्क करें लॉग इन करें

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

लेखक: Tadas Petra; Jack Limebear
प्रकाशित: 24 जून 2026
आखिरी बार अपडेट किया गया: 22 जुल॰ 2026

सुनेंइस आर्टिकल को सुनें

0:00

0:000:00

शुरू करें

और जानें

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

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

इस आर्टिकल में बताया गया है कि APIs को सही तरीके से कैसे ऑथेंटिकेट करें और कीज़ को उनके पूरे लाइफसाइकल में कैसे मैनेज करें: स्कोपिंग, रोटेशन, ऑर्गनाइजेशनल कंट्रोल्स, ऑडिटिंग और इन्सिडेंट रिस्पॉन्स। यह आपकी टीम में API ऑथेंटिकेशन और की मैनेजमेंट सही तरीके से सेटअप करने में मदद करेगा। पढ़ते समय रेफरेंस के लिए रखेंऑथेंटिकेशन रेफरेंस औरसिंगल-यूज़ टोकन रेफरेंस ओपन रखें।

सारांश

ElevenAPI हर रिक्वेस्ट को एक सिंगल सीक्रेट, xi-api-key हेडर के जरिए ऑथेंटिकेट करता है, यानी जिसके पास की है, वह आपके अकाउंट से क्रेडिट्स खर्च कर सकता है और ऑडियो जनरेट कर सकता है।
कभी भी कोई लॉन्ग-लिव्ड API की ब्राउज़र, मोबाइल ऐप या किसी भी ऐसी जगह न डालें जिसे यूज़र देख सके। इन्हें सिर्फ अपने सर्वर पर रखें।
क्लाइंट-साइड यूज़ केस में हमेशा शॉर्ट-लिव्ड, सिंगल-यूज़ टोकन का इस्तेमाल करें, जो सर्वर से जनरेट हो, कभी भी लॉन्ग-लिव्ड की का नहीं।
आप कीज़ को कम से कम परमिशन देकर, हर एनवायरनमेंट के लिए अलग की बनाकर और समय-समय पर रोटेट करके लीक का असर कम कर सकते हैं।
ऑडिटिंग और अनोमली डिटेक्शन से की लीक और अनचाही एक्टिविटी को रोका जा सकता है।

API ऑथेंटिकेशन क्या है?

API ऑथेंटिकेशन वह तरीका है जिससे कोई सर्विस यह कन्फर्म करती है कि आने वाला रिक्वेस्ट किसी खास अकाउंट पर काम करने के लिए अधिकृत है या नहीं। रिक्वेस्टर क्रेडेंशियल देता है, सर्विस उसे वेरिफाई करती है, और वेरिफिकेशन के बाद रिस्पॉन्स देती है।

साधारण भाषा में, यह सवाल का जवाब देता है: क्या यह रिक्वेस्ट इस अकाउंट के लिए अधिकृत है? ध्यान दें कि यह प्रोसेस API ऑथराइजेशन से अलग है, जिसमें बताया जाता है कि ऑथेंटिकेटेड रिक्वेस्ट आपके सिस्टम में क्या कर सकता है।

की मैनेजमेंट क्या है?

की मैनेजमेंट उन सभी प्रैक्टिसेज़ का सेट है जिनसे आप किसी API की को उसके पूरे लाइफसाइकल में मैनेज करते हैं। इसमें की को बनाना, स्टोर करना, इस्तेमाल करना, रोटेट करना और एक्सेस रिवोक करना शामिल है। ये सिस्टम्स API की की सुरक्षा सुनिश्चित करने के लिए होते हैं।

सख्त की मैनेजमेंट सिस्टम्स से आप की लीक होने से रोक सकते हैं और इसके पब्लिकली एक्सेसिबल होने का रिस्क कम कर सकते हैं।

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

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

ElevenAPI एक ही सीक्रेट-बेयरिंग मैकेनिज्म से ऑथेंटिकेट करता है: xi-api-key हेडर। जिसके पास की है, वह अधिकृत है, और रिक्वेस्ट में कोई दूसरा फैक्टर नहीं है।

अगर आपके पास आपकी कुंजी है, तो वे आपके क्रेडिट खर्च कर सकते हैं। टेक्स्ट टू स्पीच,

वे बड़े पैमाने पर जनरेट कर सकते हैं, और हमारा रेट-लिमिटिंग मॉडल इस स्थिति को और गंभीर बना देता है। लिमिट कंकरेंसी पर आधारित है, सिर्फ रिक्वेस्ट्स-पर-मिनट कोटा नहीं। किसी मॉडल फैमिली के लिए पांच कंकरेंसी लिमिट वाली की काफी सारे सिमल्टेनियस जनरेशन चला सकती है, और जो अटैकर इन लिमिट्स को समझता है, वह दुरुपयोग को पैरेललाइज कर सकता है।

वे आपके अकाउंट के तहत कंटेंट बना सकते हैं। आपकी की से जनरेट हुआ कोई भी ऑडियो आपके वर्कस्पेस से जुड़ा होता है, और वॉइस व इनपुट्स के आधार पर यह आपकी रेप्युटेशन या कभी-कभी लीगल चिंता भी बन सकता है।

की लीक होने के तरीके आम हैं, और ये वही फेल्योर मोड्स हैं जिनसे बाकी सभी तरह के क्रेडेंशियल्स लीक होते हैं:

क्लाइंट-साइड कोड में API कीज़: ब्राउज़र बंडल, मोबाइल बाइनरी या सिंगल-पेज ऐप में डाली गई की, प्रैक्टिकली पब्लिक होती है। मिनिफिकेशन, ऑबफुस्केशन नहीं है।
रिपॉजिटरीज़ में API कीज़: Git में हार्डकोडेड कीज़, जिसमें प्राइवेट रिपोज़ भी शामिल हैं जो बाद में पब्लिक हो जाते हैं या बहुत जगह क्लोन हो जाते हैं, और .env जैसी फाइलें जो कभी ट्रैक होने के लिए नहीं थीं।
लॉग्स और ट्रेसेज़ में API कीज़: रिक्वेस्ट लॉगर्स, एरर ट्रैकर्स और ऑब्ज़र्वेबिलिटी पाइपलाइंस अक्सर HTTP हेडर्स कैप्चर करते हैं। xi-api-key में की आपके लॉग स्टोर, आपके APM वेंडर और जिसे भी रीड एक्सेस है, वहां पहुंच जाती है।
CI और स्क्रीनशॉट्स में API कीज़: बिल्ड लॉग्स, सपोर्ट टिकट्स और शेयर किए गए टर्मिनल्स।

नीचे दिए गए हर सेक्शन का मकसद इनमें से किसी एक की संभावना या असर को कम करना है।

मुख्य नियम: API कीज़ हमेशा सर्वर-साइड रखें

इस आर्टिकल में बाकी सब कुछ API की ऑथेंटिकेशन और मैनेजमेंट के रिस्क को कम करने की जानकारी देता है। लेकिन यह एक नियम सबसे जरूरी है और इसे सबसे पहले लागू करें।

क्योंकि मैकेनिज्म बहुत सिंपल है, मुख्य नियम है कि लॉन्ग-लिव्ड API की सिर्फ आपके कंट्रोल वाले सर्वर पर होनी चाहिए। इसे कभी भी ब्राउज़र, मोबाइल ऐप, डेस्कटॉप क्लाइंट या किसी भी ऐसी जगह न डालें जिसे यूज़र डाउनलोड या इंस्पेक्ट कर सके। अगर की क्लाइंट-साइड कोड में है, तो मान लें कि वह पहले ही कंप्रोमाइज हो चुकी है।

SDK अपने आप ELEVENLABS_API_KEY पढ़ता है, इसलिए सबसे साफ कोड में कुछ पास नहीं करना पड़ता और क्लाइंट एक बार इनिशियलाइज़ होता है।

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",
});

प्रोडक्शन में इसे सीक्रेट मैनेजर (जैसे AWS Secrets Manager, GCP Secret Manager, HashiCorp Vault या आपके प्लेटफॉर्म का विकल्प) से प्रोसेस स्टार्ट पर लोड करना चाहिए, न कि इमेज या .env में हार्डकोड करके।

क्लाइंट-साइड ऐप्स के लिए सिंगल-यूज़ टोकन

मुख्य नियम बिल्कुल साफ है, लेकिन कई सही वजहें हैं जहाँ क्लाइंट को खुद ElevenAPI तक पहुँचना पड़ता है: जैसे ब्राउज़र में स्ट्रीम किया गया

आपका सर्वर लॉन्ग-लिव्ड की रखता है, अपने सेशन लॉजिक से यूज़र को ऑथेंटिकेट और ऑथराइज करता है, फिर शॉर्ट-लिव्ड टोकन बनाता है और सिर्फ वही क्लाइंट को देता है। टोकन जल्दी एक्सपायर हो जाता है और उसी ऑपरेशन तक सीमित रहता है जिसके लिए जारी हुआ था, इसलिए लीक हुआ टोकन ज्यादा काम का नहीं रहता। सपोर्टेड एंडपॉइंट्स और रिक्वेस्ट फॉर्मेट के लिए सिंगल-यूज़ टोकन रेफरेंस देखें।

यहां एक ब्रोकर एंडपॉइंट का बेसिक लॉजिक है। यह आपके सेशन लॉजिक से यूज़र को ऑथराइज करता है, फिर डॉक्युमेंटेड टोकन एंडपॉइंट पर टोकन बनाता है। रिक्वेस्ट सर्वर से लॉन्ग-लिव्ड xi-api-key के साथ जाती है, और क्लाइंट को सिर्फ शॉर्ट-लिव्ड टोकन मिलता है।

// ... 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() });
});

इसके बाद ब्राउज़र उसी टोकन से कनेक्ट करता है, और लॉन्ग-लिव्ड की कभी पेज में नहीं जाती।

कीज़ को कम से कम परमिशन तक सीमित करना

लीस्ट प्रिविलेज़ का मतलब है कि हर की में सिर्फ उतनी ही परमिशन हो जितनी उसके काम के लिए जरूरी है, उससे ज्यादा नहीं। ElevenAPI आपको कई परमिशन-बेस्ड रिस्ट्रिक्शन लगाने देता है, जिससे आप कंट्रोल कर सकते हैं कि की क्या कर सकती है और क्या नहीं।

एक ऑल-पावरफुल की सबसे खराब स्थिति है, और यही डिफॉल्ट भी है। बेहतर तरीका है मानकर चलना कि कोई भी की कभी न कभी लीक हो सकती है, और जब हो, तो वह सिर्फ उतना ही कर सके जितना उसके काम के लिए जरूरी है।

शुरुआत करें स्कोप रिस्ट्रिक्शन से, जिससे आप तय कर सकते हैं कि की कौन से API एंडपॉइंट्स को कॉल कर सकती है। सिर्फ ट्रांसक्रिप्शन के लिए इस्तेमाल होने वाली की कोटेक्स्ट टू स्पीच एक्सेस; एक की

इसके बाद आता है क्रेडिट कोटा। हर की के लिए कस्टम क्रेडिट लिमिट सेट करने से लीक का फाइनेंशियल नुकसान सीमित रहता है और आपके कोड में रनअवे लूप्स भी कंट्रोल में रहते हैं।

IP व्हाइटलिस्टिंग और आगे जाती है। आप की को खास IP एड्रेस या CIDR रेंज तक सीमित कर सकते हैं, और नॉन-व्हाइटलिस्टेड IP से आने वाले रिक्वेस्ट्स को 403 के साथ रिजेक्ट किया जाता है। यह एंटरप्राइज फीचर अभी प्रीव्यू में है, और आपके अकाउंट मैनेजर के जरिए उपलब्ध है।

आखिर में, किसी की को डेवलपमेंट, स्टेजिंग और प्रोडक्शन में शेयर न करें। हर एनवायरनमेंट के लिए अलग की जारी करें, हर एक का अपना स्कोप और कोटा हो। इससे डेवलपर लैपटॉप से लीक हुई की प्रोडक्शन क्रेडिट्स से दूर रहती है, आप एक एनवायरनमेंट को रोटेट कर सकते हैं बिना बाकी को प्रभावित किए, और यूसेज लॉग्स भी समझने में आसान रहते हैं क्योंकि ट्रैफिक पहले से ही ओरिजिन के हिसाब से बंटा होता है।

API की रोटेशन

की रोटेशन का मतलब है किसी की को नियमित रूप से नई की से बदलना। यह तब भी किया जा सकता है जब आपको ब्रीच या एक्सपोजर का शक हो।

शेड्यूल पर रोटेशन करने से वह विंडो छोटी हो जाती है जिसमें कोई लीक बिना पता चले इस्तेमाल हो सकती है। रोटेशन तभी आसान है जब आपका कोड इसके लिए तैयार हो, इसलिए जरूरत पड़ने से पहले ही रोटेशन के लिए डिजाइन करें।

मुख्य तरीका है ओवरलैपिंग कीज़, जिससे आप बिना डाउनटाइम के कटओवर कर सकते हैं:

नई API की बनाएं:नई की को मौजूदा की के साथ प्रोविजन करें, वही स्कोप, कोटा और IP रिस्ट्रिक्शन के साथ। दोनों अब वैध हैं।
की अपडेट करें:नई की को अपने सीक्रेट मैनेजर में अपडेट करें और इंस्टेंसेज़ को इसे पिक करने दें (रीस्टार्ट, री-रीड या सीक्रेट-मैनेजर रिफ्रेश, आपकी सेटअप के हिसाब से)।
ट्रैफिक कन्फर्म करें:देखें कि ट्रैफिक नई की पर आ रहा है। यूसेज देखें कि पुरानी की शांत हो गई है।
की एक्सेस हटाएं: जब पुरानी की पर कोई ट्रैफिक न दिखे तो उसे रिवोक कर दें।

क्योंकि ओवरलैप के दौरान दोनों कीज़ वैध रहती हैं, कभी ऐसा पल नहीं आता जब रिक्वेस्ट्स सिर्फ क्रेडेंशियल की कमी से फेल हों। ओवरलैप विंडो का दूसरा फायदा है: कोई मिसकन्फिगर इंस्टेंस खुद को दिखा देता है क्योंकि वह पुरानी की यूज़ करता रहता है, तो आप उसे कट करने से पहले पकड़ सकते हैं।

ओवरलैप को नॉन-इवेंट बनाने के लिए, अपने कोड को ऐसे स्ट्रक्चर करें कि रोटेशन सिर्फ एक कॉन्फिगरेशन चेंज हो, कोड चेंज नहीं। की को एक ही जगह से पढ़ें, जहां उसे रिफ्रेश किया जा सके, और एक स्विच तय करे कि कौन सा सीक्रेट एक्टिव है।

// 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;
}

ओवरलैप के दौरान, आप दोनों PRIMARY और SECONDARY को पॉप्युलेट रखते हैं और ELEVENLABS_KEY_ACTIVE को फ्लिप करते हैं। एप्लिकेशन कोड कभी नहीं बदलता।

रोटेशन की फ्रीक्वेंसी के लिए, हर 90 दिन में एक बार बैकएंड कीज़ का रूटीन रोटेशन अच्छा डिफॉल्ट है, हाई-वैल्यू या ज्यादा एक्सेस वाली कीज़ के लिए और जल्दी, और किसी भी एक्सपोजर पर तुरंत। इसे शेड्यूल्ड जॉब से ऑटोमेट किया जा सकता है, जो प्रोविजन, रोल, वेरिफाई और रिवोक करता है, जिससे रोटेशन एक इवेंट से बैकग्राउंड प्रोसेस बन जाता है।

वर्कस्पेस एक्सेस कंट्रोल्स और परमिशन

जहां स्कोपिंग और रोटेशन हर की को सुरक्षित बनाते हैं, वहीं वर्कस्पेस कंट्रोल्स तय करते हैं कि की कौन बना सकता है। यहां आप ऑर्गनाइजेशनल पॉलिसी सेट कर सकते हैं, जो आपकी सभी की मैनेजमेंट प्रैक्टिसेज़ को आगे प्रभावित करेगी।

शुरुआत करें ह्यूमन और मशीन क्रेडेंशियल्स को अलग करके। लोग अपने अकाउंट और परमिशन से डैशबोर्ड में साइन इन करते हैं; सर्विसेज़ की या बेहतर, सर्विस अकाउंट्स से ऑथेंटिकेट करती हैं। किसी सर्विस को किसी व्यक्ति की पर्सनल एक्सेस से बनी की पर न चलाएं, और लोग एक ही मशीन की शेयर न करें। वजह है ऑफबोर्डिंग: जब कोई व्यक्ति जाता है या सर्विस रिटायर होती है, तो आप सिर्फ सही क्रेडेंशियल रिवोक करना चाहेंगे, बिना बाकी को प्रभावित किए।

सर्विस अकाउंट्स भी यही मकसद पूरा करते हैं। वे मशीन वर्कलोड्स को इंसान से अलग पहचान देते हैं, अपने स्कोप के साथ, जिससे आपका ऑडिट ट्रेल सही रहता है।

इसके बाद एक्सेस को रोल्स से मैप करें, न कि एक-एक व्यक्ति से। वर्कस्पेस में ग्रुप और मेंबर परमिशन इसी के लिए हैं। हर ग्रुप को उसके काम के लिए जरूरी कम से कम परमिशन दें, मेंबरशिप समय-समय पर रिव्यू करें, और कोशिश करें कि कोई भी क्रेडेंशियल, चाहे इंसान का हो या मशीन का, अपने रोल से ज्यादा न कर सके।

ऑडिट और डिटेक्शन

अब तक हमने बताया कि लीक का नुकसान कैसे कम करें। अब बताते हैं कि लीक हुआ है या नहीं, यह कैसे पता करें। अच्छी डिटेक्शन तीन आदतों पर टिकी है।

पहली है रिकॉर्ड रखना कि कौन सी की (आईडेंटिफायर से, कभी सीक्रेट वैल्यू से नहीं) किस क्लास के रिक्वेस्ट के लिए, कहां से और कितनी मात्रा में यूज़ हुई। xi-api-key हेडर को हर लॉगिंग और ट्रेसिंग लेयर से हटा दें। आपके HTTP मिडलवेयर और APM कॉन्फिग में रेडक्शन रूल लगाएं, जिससे की लॉग स्टोर्स में जाने का सबसे आम तरीका बंद हो जाता है।

दूसरी है क्रेडिट कंजम्पशन में अनोमली मॉनिटर करना। हर की के क्रेडिट खर्च को ट्रैक करें और बेसलाइन से डेविएशन पर अलर्ट करें: अचानक स्पाइक, अजीब समय पर जनरेशन, या कोई की जो आइडल होनी चाहिए थी, अचानक एक्टिव हो जाए।

तीसरी है कंकरेंसी हेडर्स पर नजर रखना। हर रिस्पॉन्स में हम करंट और मैक्सिमम कंकरेंट रिक्वेस्ट्स लौटाते हैं: current-concurrent-requests और maximum-concurrent-requests हेडर्स में। ये बताते हैं आपके पास कितनी हेडरूम है, और अगर मैक्सिमम पर लगातार पिन है जो आपने शुरू नहीं किया, तो यह दुरुपयोग का मजबूत संकेत है। रॉ HTTP एंडपॉइंट से रिस्पॉन्स हेडर्स सीधे दिखते हैं:

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.

ऐसी स्थिति में अलर्ट्स ट्रिगर होने चाहिए। ऐसा डैशबोर्ड जिसका कोई ध्यान न रखे, वह डिटेक्शन नहीं देता। क्रेडिट-स्पाइक और कंकरेंसी-सैचुरेशन सिग्नल्स को उसी अलर्टिंग पाथ में जोड़ें जो आप आउटेज के लिए यूज़ करते हैं, और इसका क्लियर ओनर तय करें।

इन्सिडेंट रिस्पॉन्स

चाहे आपकी सिक्योरिटी और मॉनिटरिंग कितनी भी अच्छी हो, मानकर चलें कि कोई की कभी न कभी लीक हो सकती है। इसके लिए पहले से प्लान बनाकर रखें, जिससे नुकसान कम करने के लिए आपके पास एक रोडमैप हो, समय बचे और असर कम हो।

API की एक्सपोजर के लिए एक तयशुदा इन्सिडेंट रिस्पॉन्स रास्ता:

लीक हुई की तुरंत रिवोक करें: पूरे स्कोप को समझने का इंतजार न करें। रिवोक की गई की से जनरेशन नहीं हो सकती, और रिवोकेशन रिवर्सिबल है क्योंकि आप हमेशा रिप्लेसमेंट जारी कर सकते हैं। यही सबसे जरूरी कदम है।
नई की पर रोटेट करें: अगर लीक हुई की प्रोडक्शन ट्रैफिक चला रही थी, तो ओवरलैप प्रक्रिया उल्टी करें: नई की लाएं, ट्रैफिक शिफ्ट करें, फिर कन्फर्म करें कि लीक हुई की बंद हो गई है। क्योंकि आपका कोड की को कॉन्फिग से पढ़ता है, यह सिर्फ एक कॉन्फिग फ्लिप है, कोड चेंज नहीं।
यूसेज लॉग्स से ब्लास्ट रेडियस जांचें: लीक कंट्रोल में आने के बाद, उसका आकलन करें। की कितने समय तक वैध और एक्सपोज़्ड रही? उस विंडो में कितने क्रेडिट्स खर्च हुए, और क्या पैटर्न सही ट्रैफिक जैसा है या दुरुपयोग जैसा? कौन से एंडपॉइंट्स टच हुए?
डिपेंडेंट सीक्रेट्स रोटेट करें:कोई की शायद ही अकेले लीक होती है। अगर वह किसी रिपो, लॉग स्टोर या CI पाइपलाइन में एक्सपोज़ हुई है, तो मान लें कि आसपास के सीक्रेट्स भी एक्सपोज़ हैं और उन्हें भी रोटेट करें।
लीक का रास्ता बंद करें: पता करें कि की कैसे लीक हुई और उसे ठीक करें, वरना फिर होगा: फाइल को .gitignore में डालें और हिस्ट्री पर्ज करें, लॉगर में हेडर रेडक्शन जोड़ें, सीक्रेट को बिल्ड आर्टिफैक्ट से बाहर करें, और CI सिस्टम की एक्सेस टाइट करें।
पोस्ट-मॉर्टम लिखें:टाइमलाइन, ब्लास्ट रेडियस, रूट कॉज़ और जो कंट्रोल्स जोड़े गए (स्कोप टाइटनिंग, IP व्हाइटलिस्टिंग, CI में सीक्रेट स्कैनर, और तेज रोटेशन) को डॉक्युमेंट करें।

इन स्टेप्स को फॉलो करके, आपके पास API एक्सपोजर जैसी स्थिति के लिए एक तयशुदा प्रोसेस रहेगा।

कंप्लायंस पोज़िशन: SOC 2, HIPAA और डेटा रिटेंशन

ऑथेंटिकेशन कंप्लायंस इवैल्यूएशन का एक हिस्सा है, और यहां क्या दावा किया जा सकता है, इसमें सावधानी बरतें। नीचे दी गई बातें एक फैक्टुअल शुरुआती बिंदु हैं, आपके यूज़ केस के लिए फाइनल निर्णय नहीं।

ElevenLabsSOC 2 कंप्लायंट है। योग्य प्लान्स और यूज़ केस के लिए HIPAA कंप्लायंस और जीरो-रिटेंशन मोड्स उपलब्ध हैं। जीरो-रिटेंशन का मतलब है कि प्रोसेसिंग के बाद रिक्वेस्ट कंटेंट स्टोर नहीं होता, जो तब जरूरी है जब आपके इनपुट्स या जनरेटेड ऑडियो सेंसिटिव हों।

कौन सा मोड लागू होता है, यह आपके प्लान, कॉन्फिगरेशन और आप क्या प्रोसेस कर रहे हैं, इस पर निर्भर करता है। किसी भी मोड पर भरोसा करने से पहले अपनी एलिजिबिलिटी और सटीक शर्तें कन्फर्म करें, और ऊपर बताए गए एक्सेस कंट्रोल्स के साथ इन्हें जोड़ें। कंप्लायंस सर्टिफिकेशन यह तय करते हैं कि प्लेटफॉर्म आपका डेटा कैसे हैंडल करता है; की मैनेजमेंट यह तय करता है कि आपकी ओर से कौन एक्ट कर सकता है, और यह हिस्सा आपके हाथ में है।

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

सिर्फ सर्वर-साइड कीज़ सबसे बड़ा लीक रिस्क हटाती हैं। सिंगल-यूज़ टोकन उन क्लाइंट्स तक यह गारंटी बढ़ाते हैं जिन्हें सच में हमारी API तक पहुंच चाहिए। स्कोपिंग और एनवायरनमेंट के हिसाब से अलगाव किसी भी लीक का नुकसान सीमित करते हैं। कॉन्फिगरेशन में बनी रोटेशन रिकवरी को रूटीन बना देती है। वर्कस्पेस कंट्रोल्स इंसान और मशीन की पहचान अलग रखते हैं। ऑडिटिंग दुरुपयोग को अलर्ट बना देती है, न कि बिल पर सरप्राइज। एक लिखा हुआ रनबुक इन्सिडेंट को प्रोसीजर बना देता है।

यह वही क्रेडेंशियल हाइजीन है जो किसी भी हाई-वैल्यू सीक्रेट को सुरक्षित रखती है, बस यहां की की खासियत है कि इससे पैसे खर्च होते हैं और बड़े पैमाने पर ऑडियो जनरेट होता है।

जब आप इसे असली रिक्वेस्ट शेप्स के साथ सेटअप करने के लिए तैयार हों, तो ऑथेंटिकेशन रेफरेंस और सिंगल-यूज़ टोकन रेफरेंस में सपोर्टेड एंडपॉइंट्स की मौजूदा लिस्ट है। मॉनिटरिंग के लिए कंकरेंसी मॉडल समझने के लिए, मॉडल्स रेफरेंस और API क्विकस्टार्ट पढ़ें।

अपनी ElevenAPI इंटीग्रेशन को सुरक्षित बनाएं

मजबूत API ऑथेंटिकेशन एक बेसिक कंट्रोल है, जिस पर कई और सिक्योरिटी प्रैक्टिसेज़ बनती हैं। सर्वर-साइड कीज़, क्लाइंट्स के लिए सिंगल-यूज़ टोकन, लीस्ट प्रिविलेज स्कोपिंग और की मैनेजमेंट में रोटेशन जैसी चीजें बड़े पैमाने पर रिस्क को रोकने में मदद करती हैं।

सपोर्टेड एंडपॉइंट्स और सही हेडर फॉर्मेट के लिए, देखेंElevenAPI डाक्यूमेंटेशन। अगर आप शुरू करने के लिए तैयार हैं, तोElevenLabs से API की रिक्वेस्ट करें और आज ही बनाना शुरू करें।