Claude API ऑथेंटिकेशन के 4 तरीके: Bedrock, Vertex और अन्य

Claude API ऑथेंटिकेशन के चार मार्ग

Claude API ऑथेंटिकेशन का निर्णय इस बात पर निर्भर करता है कि आपका क्लाइंट कौन सा क्रेडेंशियल उपयोग करता है। इसके चार तरीके हैं और ये एक ही मैकेनिज्म के अलग-अलग रूप नहीं हैं। डायरेक्ट Anthropic API एक static key को x-api-key हेडर में भेजता है। Amazon Bedrock हर रिक्वेस्ट को AWS क्रेडेंशियल्स के साथ साइन करता है, और उस सेटअप में कहीं भी Anthropic key का उपयोग नहीं होता है। Google Cloud एक अल्पकालिक (short-lived) Google access token भेजता है। Microsoft Foundry एक Azure-issued key या Microsoft Entra token का उपयोग करता है।

यह गाइड Linux सर्वर पर चल रही सर्विस में SDK (software development kit) को कॉन्फ़िगर करने के लिए है। यदि आप इसके बजाय Claude Code कमांड लाइन टूल को कॉन्फ़िगर कर रहे हैं, तो वेरिएबल्स और प्रक्रिया अलग होगी: देखें Claude Code को Bedrock या Vertex पर पॉइंट करना। यदि सर्विस अभी तक मौजूद नहीं है, तो पहले उसे VPS पर पहली Claude API ऐप के साथ बनाएं और क्रेडेंशियल के लिए यहाँ वापस आएं।

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

Route 1: एक Anthropic API key

यह सीधा रास्ता है, और केवल यही वह तरीका है जहाँ Anthropic secret जारी करता है। Requests Anthropic के API host पर Messages endpoint पर जाती हैं, और प्रत्येक request में तीन headers होते हैं।

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model": "MODEL_ID", "max_tokens": 64, "messages": [{"role": "user", "content": "Hello"}]}'

MODEL_ID को Anthropic के models overview से एक वर्तमान identifier के साथ बदलें। एक सफल response वह JSON है जिसमें content array और usage object होता है। एक गलत या expired key HTTP 401 के साथ authentication_error लौटाती है। एक गायब anthropic-version header एक अलग विफलता है, क्योंकि वह header हर request पर आवश्यक है; SDKs इसे आपके लिए सेट कर देते हैं।

Client का निर्माण चार तरीकों में सबसे छोटा है, क्योंकि इसमें निर्माण करने के लिए कुछ भी नहीं है। प्रत्येक आधिकारिक SDK अपने आप environment से ANTHROPIC_API_KEY को पढ़ लेता है।

import os
from anthropic import Anthropic

client = Anthropic()  # reads ANTHROPIC_API_KEY from the environment

message = client.messages.create(
    model=os.environ["CLAUDE_MODEL"],
    max_tokens=64,
    messages=[{"role": "user", "content": "Hello"}],
)
print(message.usage)

Model identifier को key के साथ environment में रखना उचित है। Model के नाम आपके नियंत्रण से बाहर एक schedule पर बदलते हैं, और केवल एक string को edit करने के लिए code को फिर से deploy करना अनावश्यक काम है।

Keys Console में बनाई जाती हैं, जहाँ आप निर्माण के समय expiry चुनते हैं: 3 घंटे, 1 दिन, 7 दिन या 30 दिन के presets, एक custom अवधि, या Never। Expiry निर्माण के समय तय हो जाती है और बाद में बदली नहीं जा सकती। Anthropic एक long-lived key के expire होने से पहले उसके creator को email भेजता है, लेकिन कम अवधि वाली key बिना किसी चेतावनी mail के expire हो जाती है। एक expired key 401 लौटाती है और उसे reactivate नहीं किया जा सकता, इसलिए समाधान हमेशा एक नई key बनाना ही है।

Direct API पर चुनने के लिए कोई region नहीं होता, और bill सीधे आपके Anthropic organization को जाता है। Workspaces एक key को एक project तक सीमित करते हैं, जो यह देखने का सबसे स्पष्ट तरीका है कि एक single service कितना खर्च करती है। उस bill के पीछे के गणित के लिए, how per-token API pricing compares against a subscription देखें।

यहाँ एक और विकल्प शामिल है, क्योंकि यह static secret को पूरी तरह से हटा देता है। Workload Identity Federation एक workload को उस identity provider से OpenID Connect (OIDC) token का आदान-प्रदान करने देता है जिस पर आप पहले से भरोसा करते हैं, ताकि POST /v1/oauth/token पर एक short-lived Anthropic token प्राप्त हो सके, और SDK उस token के expire होने से पहले उसे refresh कर देता है। कोई भी sk-ant-api... string कहीं भी नहीं बनाई या copy की जाती है। यह Kubernetes, GitHub Actions और cloud VMs के लिए उपयुक्त है, जिनके पास पहले से ही एक platform identity होती है। एक साधारण VPS के पास आमतौर पर ऐसा कोई issuer नहीं होता, इसलिए उस box पर एक file में API key रखना ही सही उत्तर है, और यह guide बाकी हिस्सों में इसी तरह से काम करती है।

Route 2: Amazon Bedrock पर AWS credentials

Bedrock पर आपके पास कोई Anthropic key नहीं होती है। SDK प्रत्येक HTTP request को सामान्य AWS credentials का उपयोग करके AWS Signature Version 4 (SigV4) के साथ sign करता है, और AWS यह तय करता है कि क्या वह caller model को invoke कर सकता है।

pip install -U "anthropic[bedrock]"
aws sts get-caller-identity

aws sts get-caller-identity आपके credentials द्वारा पहचानी गई identity का account number और ARN (Amazon Resource Name) print करता है। इसे किसी भी अन्य काम से पहले चलाएं। यदि यह विफल होता है, तो Claude call भी विफल हो जाएगी, क्योंकि SDK उसी chain का पालन करता है: पहले constructor arguments, फिर AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN और AWS_REGION environment variables, उसके बाद AWS config file और standard chain के बाकी हिस्से (SSO, assumed roles, ECS task role, instance metadata service)।

client construction में जो बदलाव आता है, वह class और एक argument का है।

from anthropic import AnthropicBedrock

client = AnthropicBedrock(aws_region="us-east-1")

यहाँ Region केवल सजावट नहीं है। Bedrock endpoints प्रति region होते हैं, model access AWS console में प्रति region दिया जाता है, और region, SigV4 signature का हिस्सा होता है, इसलिए एक region के लिए compute किया गया signature दूसरे द्वारा अस्वीकार कर दिया जाता है। service environment में AWS_REGION को स्पष्ट रूप से set करें। Anthropic के दस्तावेज़ों के अनुसार AnthropicBedrock client, AWS_REGION को पढ़ता है और unset होने पर us-east-1 पर वापस आ जाता है, और यह region के लिए ~/.aws/config को नहीं पढ़ता है। यही कारण है कि AWS CLI उसी box पर Claude models को सफलतापूर्वक list कर सकता है जहाँ आपका Python process विफल हो जाता है: CLI ने आपकी config file पढ़ी और client ने नहीं।

EC2 instance पर आप एक IAM (identity and access management) role attach करते हैं और कोई भी secret कभी disk पर नहीं आता, क्योंकि instance metadata service SDK को temporary credentials प्रदान करती है। AWS के बाहर एक VPS में न तो instance role होता है और न ही metadata service। तब आप box पर मौजूद IAM user की long-lived access key pair (जो Anthropic key के समान ही एक secret है) और federation के बीच चुनाव कर रहे होते हैं: अपने identity provider के विरुद्ध authenticate करें, AWS STS (security token service) को call करें, और इसके द्वारा लौटाए गए temporary credentials का उपयोग करें। Bedrock, AWS_BEARER_TOKEN_BEDROCK के माध्यम से bearer token भी स्वीकार करता है, जिसे 12 घंटे की सीमा के साथ document किया गया है और AWS द्वारा इसे सबसे कम पसंदीदा तरीका बताया गया है।

बिल Anthropic के बजाय आपके AWS account पर आता है, जो आमतौर पर यहाँ आने का मुख्य कारण होता है। अगस्त 2026 में document किए गए अनुसार, regional endpoints पर global endpoint की तुलना में 10% अधिक शुल्क लगता है। Bedrock की एक error को पहचानना आवश्यक है क्योंकि यह permissions की समस्या जैसी दिखती है लेकिन वह है नहीं: Invocation of model ID ... with on-demand throughput isn't supported. Retry your request with the ID or ARN of an inference profile that contains this model. यह model routing है, और कोई भी credential परिवर्तन इसे ठीक नहीं करेगा।

Route 3: Vertex AI पर Google credentials

Google Cloud, Application Default Credentials (ADC) का उपयोग करता है। यह एक निश्चित खोज क्रम है जिसका पालन Google auth libraries करती हैं ताकि आपको बिना नाम दिए credential मिल सके। ADC सबसे पहले GOOGLE_APPLICATION_CREDENTIALS की जाँच करता है, फिर gcloud auth application-default login द्वारा लिखी गई फ़ाइल की, और अंत में metadata server के माध्यम से जुड़े service account की।

pip install -U "anthropic[vertex]"
gcloud auth application-default login

एक वर्कस्टेशन पर login करने से $HOME/.config/gcloud/application_default_credentials.json लिखा जाता है और आपका काम पूरा हो जाता है। सर्वर पर यह गलत टूल है, क्योंकि इसमें स्टोर किया गया credential एक इंसान का होता है और उस व्यक्ति के account के साथ ही समाप्त हो जाता है। Google Cloud के बाहर कोई metadata server भी नहीं होता, इसलिए ADC अंत में GOOGLE_APPLICATION_CREDENTIALS पर आ जाता है जो एक service account key फ़ाइल की ओर इशारा करता है। वह JSON फ़ाइल एक long-lived secret है और उसे इस गाइड में बाद में बताए गए तरीके से ही संभालना आवश्यक है। Google Cloud के अंदर, VM के साथ एक service account जोड़ें और फिर सुरक्षित रखने के लिए कोई फ़ाइल नहीं बचती।

from anthropic import AnthropicVertex

client = AnthropicVertex(project_id="my-project", region="global")

यदि आप SDK से नीचे raw HTTP पर जाते हैं तो दो चीजें बदल जाती हैं। model identifier request body से बाहर निकलकर URL path में चला जाता है, और anthropic_version header से बाहर निकलकर body में चला जाता है, जहाँ इसे vertex-2023-10-16 पढ़ना चाहिए। credential एक सामान्य Google access token होता है।

curl https://aiplatform.googleapis.com/v1/projects/${PROJECT_ID}/locations/global/publishers/anthropic/models/${MODEL_ID}:rawPredict \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "Content-Type: application/json" \
  -d '{"anthropic_version": "vertex-2023-10-16", "max_tokens": 64, "messages": [{"role": "user", "content": "Hello"}]}'

Region एक प्रथम-श्रेणी का तर्क (first-class argument) है। global उपलब्धता के लिए गतिशील रूप से route करता है, us और eu multi-region identifiers हैं, और us-east5 जैसा नाम एक एकल region को पिन करता है। अगस्त 2026 में प्रलेखित अनुसार, multi-region और regional endpoints की लागत global की तुलना में 10% अधिक है। बिलिंग Google Cloud project के माध्यम से होती है, इसलिए कोटा और चालान Google के होते हैं।

Route 4: Microsoft Foundry ही Azure का मार्ग है

यदि आपने Azure पर Claude के लिए खोज की है, तो यह वही अनुभाग है जिसकी आपको आवश्यकता थी, और एक समर्थित मार्ग वास्तव में मौजूद है। Claude, Microsoft Foundry (जिसे पहले Azure AI Foundry कहा जाता था) में चलता है, और इसका बिल Azure Marketplace के माध्यम से Claude Consumption Units में आता है। आप एक Foundry resource बनाते हैं, उसके भीतर एक Claude model deploy करते हैं, और https://{resource}.services.ai.azure.com/anthropic/v1/* पर स्थित Azure-hosted endpoint को कॉल करते हैं।

दो प्रकार के credentials काम करते हैं। पहला, Foundry portal में deployment के Details tab से प्राप्त Azure-issued key है, जिसे api-key या x-api-key header में भेजा जाता है। दूसरा, Microsoft Entra token है, जो सर्वर पर बेहतर विकल्प है क्योंकि Azure role-based access control यह नियंत्रित करता है कि endpoint को कौन कॉल कर सकता है।

ACCESS_TOKEN=$(az account get-access-token --resource https://ai.azure.com --query accessToken -o tsv)

curl https://${RESOURCE}.services.ai.azure.com/anthropic/v1/messages \
  -H "content-type: application/json" \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H "anthropic-version: 2023-06-01" \
  -d '{"model": "DEPLOYMENT_NAME", "max_tokens": 64, "messages": [{"role": "user", "content": "Hello"}]}'

model field में आपका deployment name होता है, न कि model identifier। डिफ़ॉल्ट रूप से ये दोनों समान होते हैं, लेकिन जिस क्षण आप स्वयं deployment का नाम रखते हैं, ये अलग हो जाते हैं। यही कारण है कि एक सही request पर भी अक्सर Deployment not found error आती है। Python और TypeScript SDKs environment से ANTHROPIC_FOUNDRY_API_KEY और ANTHROPIC_FOUNDRY_RESOURCE को पढ़ते हैं। Foundry का समर्थन हर SDK में नहीं है: अगस्त 2026 में प्रलेखित जानकारी के अनुसार, यह C#, Java, PHP, Python और TypeScript को कवर करता है, जबकि Go और Ruby SDKs के लिए generic client को Foundry base URL पर point करना पड़ता है।

इस workaround में एक जोखिम है। यदि environment में ANTHROPIC_API_KEY अभी भी set है, तो generic client उसे उठा लेगा और आपकी Anthropic key को Microsoft endpoint पर भेज देगा। इस variable को unset करें, या client पर environment defaults को disable करें। Entra tokens लगभग एक घंटे के बाद expire हो जाते हैं, इसलिए लंबे समय तक चलने वाली प्रक्रिया को उन्हें start-up पर capture करने के बजाय refresh करना होगा।

आपके सर्वर पर क्रेडेंशियल कितने समय तक सक्रिय रहता है?

[
  {
    "label": "Anthropic key, 30-day preset",
    "max_lifetime_hours": 720
  },
  {
    "label": "Anthropic key, 7-day preset",
    "max_lifetime_hours": 168
  },
  {
    "label": "AWS STS assumed role",
    "max_lifetime_hours": 12
  },
  {
    "label": "Bedrock bearer token",
    "max_lifetime_hours": 12
  },
  {
    "label": "Entra ID access token",
    "max_lifetime_hours": 1
  },
  {
    "label": "Federated Anthropic token",
    "max_lifetime_hours": 1
  }
]

ये प्रत्येक प्रदाता द्वारा प्रकाशित अधिकतम सीमाएं और डिफ़ॉल्ट मान हैं जिन्हें अगस्त 2026 में पढ़ा गया था, न कि मापे गए आंकड़े। ये एक कारण से महत्वपूर्ण हैं: ये बताते हैं कि लीक हुआ क्रेडेंशियल तब तक कितने समय तक काम करता रहेगा जब तक आप यह पता लगा रहे हैं कि वह लीक हो गया है। चार्ट के नीचे दिए गए अल्पकालिक टोकन प्रत्येक 1 घंटे तक चलते हैं, और SDK उन्हें रिफ्रेश करता है, इसलिए कम जीवनकाल होने से आपको संचालन में कोई अतिरिक्त मेहनत नहीं करनी पड़ती। एक assumed role 12 घंटों पर रहता है। 30-दिन के प्रीसेट के साथ बनाई गई एक key 720 घंटों तक मान्य रहती है, और यही वह क्रेडेंशियल है जो एक महीने तक आपके सर्वर पर एक फाइल में पड़ा रहता है।

VPS पर क्रेडेंशियल कहाँ रखें

सीक्रेट को ऐसी फाइल में रखें जिसे केवल root ही पढ़ सके, और systemd को इसे प्रोसेस तक पहुँचाने दें। यह तरीका हर SDK वर्जन से स्वतंत्र है, इसलिए इसे एक बार सही ढंग से करना फायदेमंद है।

sudo useradd --system --home /opt/claude-app --shell /usr/sbin/nologin claudeapp
sudo install -d -m 700 -o root -g root /etc/claude-app
sudo install -m 600 -o root -g root /dev/null /etc/claude-app/env
sudoedit /etc/claude-app/env

फाइल में सादे KEY=value लाइनें होती हैं। इसमें कोई export, कोई कोट्स, और कोई शेल सिंटैक्स नहीं होना चाहिए, क्योंकि systemd इसे शेल के माध्यम से चलाने के बजाय खुद पार्स करता है।

ANTHROPIC_API_KEY=sk-ant-api03-REPLACE-ME
CLAUDE_MODEL=REPLACE-ME

[Unit]
Description=Claude API service
After=network-online.target

[Service]
User=claudeapp
EnvironmentFile=/etc/claude-app/env
ExecStart=/opt/claude-app/venv/bin/python -m claude_app
Restart=on-failure

[Install]
WantedBy=multi-user.target

systemd, User=claudeapp पर स्विच करने से पहले root के रूप में EnvironmentFile= को पढ़ता है, इसलिए सर्विस अकाउंट को फाइल के लिए रीड एक्सेस की आवश्यकता नहीं होती है। root के स्वामित्व वाली 600 मोड की फाइल पर्याप्त है, यही कारण है कि ऊपर दिया गया install कमांड इसे इसी तरह सेट करता है। इसे sudo systemctl enable --now claude-app के साथ शुरू करें, फिर systemctl status claude-app के साथ पुष्टि करें कि यूनिट active (running) तक पहुँच गई है, न कि लूप में रीस्टार्ट हो रही है।

चार चीजें जिनसे बचना चाहिए, प्रत्येक का कारण आप स्वयं जाँच सकते हैं:

• यूनिट फाइल के अंदर Environment= के साथ की (key) न लिखें। /etc/systemd/system के अंतर्गत यूनिट सभी के लिए पढ़ने योग्य होती है, इसलिए systemctl cat claude-app किसी भी लोकल यूजर को सीक्रेट दिखा सकता है।
• इसे कमिट न करें। .gitignore एक नई फाइल को कमिट से बाहर रखता है, लेकिन पहले से कमिट की गई फाइल के लिए कुछ नहीं करता, क्योंकि git हिस्ट्री में जो एक बार चला गया वह सुरक्षित रहता है।
• इसे कंटेनर इमेज में न डालें। ENV लाइनें और --build-arg वैल्यू इमेज लेयर्स में रिकॉर्ड हो जाती हैं, और docker history --no-trunc उन्हें वापस दिखा सकता है। बाद की लेयर में फाइल को डिलीट करने से वह पिछली लेयर से नहीं हटती। सीक्रेट्स को रन टाइम पर --env-file या माउंट की गई फाइल के माध्यम से पास करें।
• प्रोसेस एनवायरनमेंट को root से निजी न समझें। sudo tr '\\0' '\\n' < /proc/$(pgrep -u claudeapp -f claude_app | head -1)/environ की (key) को वापस दिखा सकता है। लक्ष्य सीक्रेट को बॉक्स पर मौजूद अन्य सभी अकाउंट्स से दूर रखना है, न कि root से, जो आपकी किसी भी कोशिश के बावजूद इसे पढ़ सकता है।

यह अंतिम बिंदु उस सीमा को निर्धारित करता है जो यह डिज़ाइन आपको प्रदान करता है। एनवायरनमेंट वेरिएबल सीक्रेट रखने के लिए एक अच्छा कंटेनर है जब केवल सर्विस और root ही इसे पढ़ सकते हों। यह तब गलत कंटेनर होता है जब प्रोसेस ऐसा कोड चलाती है जिसे आपने नहीं लिखा है, क्योंकि प्रोसेस जो कुछ भी निष्पादित कर सकती है, वह अपने एनवायरनमेंट को भी पढ़ सकती है। सीक्रेट्स को AI एजेंट की पहुँच से दूर रखना इस मामले को कवर करता है, जो एक अलग समस्या है और जिसका समाधान भी अलग है।

बिना डाउनटाइम के key को रोटेट कैसे करें?

आगे की ओर रोटेट करें, और पिछली वाली को रद्द (revoke) करें।

1. Console में, पुरानी key वाले workspace में ही नई key बनाएँ।
2. इसे /etc/claude-app/env में sudoedit के साथ लिखें।
3. sudo systemctl restart claude-app चलाएँ।
4. पुष्टि करें कि service requests का उत्तर दे रही है, फिर Console में पुरानी key को रद्द कर दें।

EnvironmentFile को unit शुरू होने पर पढ़ा जाता है, इसलिए एक चल रही process उसी value को बनाए रखती है जो उसे launch के समय दी गई थी। systemctl daemon-reload unit files को फिर से पढ़ता है और चल रही process के environment को नहीं छूता है, इसलिए केवल restart करने पर ही नई key लागू होती है। यदि आप step 4 के बजाय step 1 में ही रद्द कर देते हैं, तो step 3 तक service बंद रहेगी।

अन्य तीन तरीके provider स्तर पर रोटेट होते हैं। एक IAM user एक साथ दो active access keys का समर्थन करता है, इसलिए दूसरी key बनाएँ, उसे deploy करें, और फिर पहली वाली को हटा दें। Google service account key भी इसी तरह रोटेट होती है। Foundry key को portal में regenerate किया जाता है, जो पुरानी key को तुरंत अमान्य कर देता है, इसलिए click करने से पहले नई value लिख लें। Entra tokens और federated Anthropic tokens को रोटेशन की आवश्यकता ही नहीं होती है, और जहाँ संभव हो इनका उपयोग करना सबसे सुरक्षित विकल्प है।

जब आप Console में हों, तो workspace पर खर्च की सीमा (spend limit) निर्धारित करें। एक लीक हुई key किसी भी अन्य नुकसान से पहले महंगी साबित होती है, और VPS पर मौजूद agent कितना खर्च कर सकता है, इसकी सीमा तय करना लेख में इसके नियंत्रणों के बारे में विस्तार से बताया गया है।

मेरा क्लाइंट 401 या 403 क्यों लौटाता है?

डायरेक्ट API पर authentication_error के साथ 401। की (key) गलत है, रद्द कर दी गई है, या उसकी समय-सीमा समाप्त हो गई है। लोग अक्सर समय-सीमा समाप्त होने वाली बात भूल जाते हैं, क्योंकि कोड में कोई बदलाव नहीं हुआ होता और कल तक रिक्वेस्ट काम कर रही होती है। कंसोल में की (key) के expiry कॉलम की जाँच करें, या Admin API से expires_at पढ़ें, जहाँ बिना expiry वाली की (key) के लिए यह null होता है।

SDK आपके फेडरेशन सेटअप को अनदेखा करता है और इसके बजाय एक की (key) का उपयोग करता है। क्रेडेंशियल प्राथमिकता क्रम में ANTHROPIC_API_KEY और ANTHROPIC_AUTH_TOKEN फेडरेशन से ऊपर होते हैं, इसलिए इनमें से कोई भी इसे ओवरराइड (shadow) कर सकता है। इसका सटीक उदाहरण: एक वेरिएबल जिसे खाली स्ट्रिंग के रूप में एक्सपोर्ट किया गया है, वह अभी भी अपना स्थान घेरता है, इसलिए ANTHROPIC_API_KEY="" के कारण SDK फॉल-थ्रू (fall-through) होने के बजाय एक खाली की (key) के साथ ऑथेंटिकेट करता है। unset ANTHROPIC_API_KEY का उपयोग करें।

फेडरेशन पर Authentication failed संदेश के साथ 401। यह संदेश जानबूझकर हर संभावित कारण के लिए समान रखा गया है, ताकि कोई कॉलर एरर टेक्स्ट पढ़कर आपके नियम कॉन्फ़िगरेशन का पता न लगा सके। वास्तविक कारण कंसोल में ऑथेंटिकेशन हिस्ट्री पेज पर दर्ज होता है। JWT के बारे में अनुमान लगाने के बजाय वहीं से शुरुआत करें।

Foundry पर 403। टोकन ऑथेंटिकेट हो गया है लेकिन आपके Azure अकाउंट में वह रोल नहीं है जो इस कॉल की अनुमति देता है। रिक्वेस्ट करने वाली आइडेंटिटी को Azure RBAC रोल जैसे कि Foundry User (पूर्व में Azure AI User) या Cognitive Services User असाइन करें।

Bedrock पर कोई भी समस्या। सबसे पहले सर्विस यूजर के रूप में aws sts get-caller-identity चलाएं। यह बताता है कि क्या बॉक्स में AWS क्रेडेंशियल्स काम कर रहे हैं या नहीं, जो क्रेडेंशियल की समस्या को मॉडल एक्सेस की समस्या या क्षेत्र (region) के बेमेल होने से अलग करता है। मॉडल एक्सेस AWS कंसोल में प्रति क्षेत्र (region) दिया जाता है और एक क्षेत्र में इसे इनेबल करना आसान है जबकि आप दूसरे क्षेत्र को कॉल कर रहे होते हैं।

FAQ

क्या Bedrock या Vertex पर Claude का उपयोग करने के लिए मुझे Anthropic API key की आवश्यकता है?

नहीं। Amazon Bedrock पर SDK हर request को SigV4 का उपयोग करके AWS credentials के साथ sign करता है, और Google Cloud पर यह Application Default Credentials के माध्यम से प्राप्त Google access token भेजता है। इन दोनों सेटअप में Anthropic द्वारा जारी कोई secret नहीं होता है, और उपयोग का बिल Anthropic के बजाय cloud account पर आता है। यही कारण है कि ANTHROPIC_API_KEY में छोड़ी गई Anthropic key उन hosts पर एक खतरा है: cloud endpoint की ओर इशारा करने वाला एक सामान्य client उसे खुशी-खुशी वहां भेज देगा।

क्या Claude Azure पर उपलब्ध है?

हाँ, Microsoft Foundry (जिसे पहले Azure AI Foundry कहा जाता था) के माध्यम से। आप एक Foundry resource बनाते हैं, उसमें एक Claude model deploy करते हैं, और https://{resource}.services.ai.azure.com/anthropic/v1/messages को Azure-issued key के साथ api-key header में या Microsoft Entra bearer token के साथ call करते हैं। उपयोग का बिल Azure Marketplace के माध्यम से Claude Consumption Units में आता है। Request body में model field में आपका deployment name होना चाहिए, जो केवल तब तक model identifier के समान होता है जब तक आप deployment का नाम नहीं बदलते।

मुझे Linux सर्वर पर Claude API key कहाँ स्टोर करनी चाहिए?

इसे root के स्वामित्व वाली और 600 mode वाली एक file में रखें, जिसे systemd unit में EnvironmentFile= के माध्यम से load किया जाए। systemd unit के User= पर स्विच करने से पहले ही root के रूप में उस file को पढ़ लेता है, इसलिए service account को इसकी आवश्यकता नहीं होती है। इसे repository से बाहर रखें, unit file से बाहर रखें (जो world readable होती है और systemctl cat द्वारा print की जाती है), और container image layers से बाहर रखें, क्योंकि docker history --no-trunc, ENV या --build-arg के साथ सेट की गई किसी भी चीज़ को print कर देता है।

मेरी Claude API request ने 401 error देना क्यों शुरू कर दिया जबकि कुछ भी नहीं बदला?

सबसे आम कारण वह key है जो निर्माण के समय चुनी गई expiry तक पहुँच गई है। Expiry निर्माण के समय सेट की जाती है, जिसे बाद में edit नहीं किया जा सकता, और अल्पकालिक (short-lived) keys बिना किसी चेतावनी email के expire हो जाती हैं। एक expired key को reactivate नहीं किया जा सकता, इसलिए एक replacement बनाएँ, उसे environment file में लिखें, service को restart करें, और बाद में पुरानी key को revoke कर दें। यदि key निश्चित रूप से current है, तो जाँचें कि कोई पुरानी credential उसे shadow तो नहीं कर रही है: खाली string पर सेट ANTHROPIC_API_KEY अभी भी अन्य सभी credential sources पर प्राथमिकता रखती है।