api_error
An unexpected error occurred on Anthropic's servers — not in your code. Retry with exponential backoff and check status.anthropic.com for active incidents.
What the error looks like
{
"type": "error",
"error": {
"type": "api_error",
"message": "Internal server error"
}
}
When it happens
- Anthropic infrastructure issues or active incidents
- Very occasional transient failures during model serving
- During Anthropic deployments or scaling events
- Rarely: edge cases in your request that trigger an unhandled server error
The Anthropic SDK retries 500 errors automatically up to 2 times. Increase
max_retries for higher availability.Fix: Retry with backoff
import anthropic
import time
client = anthropic.Anthropic(max_retries=5) # SDK handles it
# Manual retry if you need full control:
def call_with_retry(messages, max_attempts=5):
delay = 5
for attempt in range(max_attempts):
try:
return client.messages.create(
model="claude-sonnet-4-6",
max_tokens=1024,
messages=messages,
)
except anthropic.APIStatusError as e:
if e.status_code == 500 and attempt < max_attempts - 1:
print(f"api_error, retrying in {delay}s...")
time.sleep(delay)
delay = min(delay * 2, 120)
else:
raise
Check the Anthropic status page
If 500 errors persist (more than 5 minutes), check for active incidents:
import requests
def check_anthropic_status():
"""Check if Anthropic has an active incident."""
r = requests.get("https://status.anthropic.com/api/v2/status.json", timeout=5)
data = r.json()
status = data["status"]["indicator"] # none, minor, major, critical
desc = data["status"]["description"]
print(f"Anthropic status: {status} — {desc}")
return status == "none" # True if all good
Subscribe to status.anthropic.com for email/webhook incident alerts.
FAQ
Can my request cause a 500 error?
Rarely — in theory a specific input could trigger an unhandled edge case. If you see 500 consistently on one specific request but not others, try simplifying the prompt or report it to Anthropic support.
api_error vs overloaded_error — which is which?
api_error (500) = internal server failure, unknown cause. overloaded_error (529) = capacity issue, known cause. Both are retryable with backoff, but overloaded is more common during peak load.