Create a Claude developer credential in the intended workspace, verify it with a minimal request and plan how to revoke it. Keep the secret out of your application source and screenshots.

Before you start

The native Claude API requires developer access and an API credential or a supported identity configuration. This walkthrough follows the API-key route. Official documentation.

Choose the workspace and billing owner before creating a credential. Use a recognizable purpose name, such as development or scheduled evaluation, rather than putting the secret into a shared note.

Prepare a short access record before opening the key dialog. It should say which application will use Claude, which workspace owns it, who maintains the secret and how the application can be stopped. The record should contain no secret value. This is especially useful when a temporary experiment later becomes a scheduled service and the original developer is no longer the person operating it.

Confirm that you are following the direct Claude Console workflow. A credential issued by another hosting platform belongs to that platform’s access system. Do not put it into the sample’s Anthropic key variable and assume the native endpoint will accept it. Keep the model host, billing owner and credential issuer together in the application configuration.

Step-by-step: create the key

  1. Open the Claude Console from the official quickstart and confirm the intended organization and workspace.
  2. Open API Keys and create a key for this application. Inspect the controls actually offered by the console.
  3. Copy the newly issued secret directly into your local secret store or environment configuration.
  4. Record the key’s purpose and owner without recording the secret in your documentation.

Use the provider’s current console link and setup instructions if a navigation label has changed. Official documentation.

Before confirming creation, read the workspace shown by the console and inspect the options actually available to your account. The page may change over time, so match the purpose of the control instead of relying on a remembered screen position. If the account lacks the required permission, have its owner review the workspace access rather than create an unrelated account to work around the problem.

Once the secret is issued, transfer it directly into protected configuration. Give your local configuration a name that makes its purpose obvious without embedding the secret in a filename. If you are documenting the setup, capture the key list or creation screen before any secret is visible. Crop the screenshot and redact account identifiers as well as credentials before sharing it.

Set a spending limit / budget alerts

Claude separates organization spending limits from rate limits and supports workspace controls. Review both scopes rather than assume a new key creates a separate budget. Official documentation.

Use a small, deliberate experiment to establish the request path before allowing a process to run unattended. Review organization and workspace controls with the billing owner, then decide what the application should do when it is intentionally paused. A useful failure message tells the operator where to inspect the account condition without revealing the credential or asking an end user to repair billing.

Do not treat a key’s descriptive name as an isolation boundary. Keep a development experiment in the workspace arrangement your team has chosen and document any shared account dependency. If several jobs share the same workspace, identify their owners before changing a control that may affect all of them. Test the application’s paused state as deliberately as its successful response.

Verify the key: first call with cURL and Python

The Messages request uses the Anthropic key header and API-version header. The SDK supplies these details for the Python example. Official documentation.

curl https://api.anthropic.com/v1/messages --max-time 30 -H "x-api-key: $ANTHROPIC_API_KEY" -H "anthropic-version: 2023-06-01" -H "content-type: application/json" -d '{"model":"claude-opus-5","max_tokens":256,"messages":[{"role":"user","content":"Hello"}]}'
import os
import sys
import anthropic

model = os.environ.get("ANTHROPIC_MODEL", "claude-opus-5")
if "--bad-model" in sys.argv:
    model = "ai-api-hub-invalid-model"
client = anthropic.Anthropic(
    api_key=os.environ["ANTHROPIC_API_KEY"], timeout=30.0, max_retries=0
)
try:
    message = client.messages.create(
        model=model, max_tokens=256,
        messages=[{"role": "user", "content": "Explain prompt caching in a short sentence."}],
    )
    for block in message.content:
        if block.type == "text":
            print(block.text)
    print(message.usage.model_dump_json())
except anthropic.APIStatusError as exc:
    print(f"HTTP {exc.status_code}")
    print(exc.response.text)
    raise SystemExit(1)

The response example is schematic; it was not captured from a paid request. Real wording, identifiers and usage vary.

{"type":"message","content":[{"type":"text","text":"Example response text"}]}

Run the smallest useful request from the environment that will eventually call Claude. If the terminal succeeds but the deployed worker fails, compare the selected workspace, secret version, endpoint and model identifier before editing the prompt. Record the installed client-library version as part of the reproduction. A working local environment is a useful baseline, but it does not prove the deployed process loaded the same configuration.

Inspect the response in layers: was the request accepted, did the result contain the expected content type, and did the text satisfy your simple test? Save a redacted diagnostic record with the model and request identifier. Do not paste the entire response into public issue trackers if it contains customer input or generated sensitive material. The displayed schematic response is only a guide to where you should look.

Where to put the key

Load ANTHROPIC_API_KEY from the environment and keep it in the server process that makes the request. See the complete Python script for the surrounding program.

Keep the credential in the process that makes the native Claude request. Avoid sending it to a page visitor, embedding it in a downloadable example or committing it alongside a demonstration script. The sample intentionally loads the environment variable explicitly, so a missing variable fails locally rather than silently making an unauthenticated request with an empty string.

For a deployed application, document how the secret reaches the worker and how a replacement becomes active. Some processes retain configuration until they restart; verify the application’s actual deployment behavior rather than assuming a changed dashboard value has reached every running instance. Keep the secret out of command output, screenshot captions and troubleshooting notes.

Common rejections

Authentication, billing, request validation and rate errors have distinct Claude error types. Inspect the error type before choosing a remedy. Official documentation.

Use the Claude error guide to preserve a useful redacted reproduction.

Investigate a rejected request without immediately rotating the credential. First identify whether the provider reports authentication, billing, validation or capacity. Next check the smallest request that previously worked. If that baseline succeeds, compare the additional fields or model selection in the failing request. This narrows the problem without destroying useful evidence.

If the baseline fails too, inspect the account and deployed configuration before adding retries. A repeated rejected request is not a credential test that becomes more informative with volume. Preserve the error type and request identifier, redact the input, and use the dedicated errors page to select the next action. Keep access repair and prompt debugging as separate work items.

Rotate and revoke

Create the replacement credential, update the application secret, make a controlled verification request, then revoke the retired credential in the console. Check scheduled tasks and deployment environments before declaring the migration complete.

Use the AI API cost calculator to turn the model and workload you are considering into an estimate.

Treat rotation as a small migration with a rollback decision. Identify every application, scheduled task and development environment using the old credential. Create the replacement, update each intended consumer and verify a controlled request from each important environment. Mark the old credential retired only after those checks establish that the replacement is active.

After revocation, watch for a forgotten worker repeatedly attempting to use the old value. Repair that worker’s configuration or stop it; do not restore the retired credential merely to hide an error. If the rotation followed suspected exposure, preserve an account-usage record for the owner and remove the secret from shared artifacts wherever it was disclosed.

Last verified · Source ↗

Frequently asked questions

Which environment variable does the sample use?
The sample reads ANTHROPIC_API_KEY; its value stays outside the script.
Where should I create the key?
Use the Claude Console linked from the official quickstart and select the intended workspace. Official documentation.
Why does a valid key still fail?
Check billing, model access, request format and rate controls independently of the secret value. Official documentation.
Is the example output an observed response?
No. The displayed response is a schematic shape; run the script with your authorized credential to obtain an actual result.
What should a correction report contain?
Include the redacted error, model identifier and relevant documentation link. Never send the API key.

Sources

Last verified · Source ↗