Internal Server Error
internal_error500
Something went wrong on our end. The fix is on us — capture the request_id and contact support if it persists.
What this means
A request reached us, but something in our code or infrastructure failed before we could return a real answer. This is not a bug in your integration — it's a bug or outage on our side. Every internal_error response is automatically reported to our on-call team via Sentry.
When you'll see this
- An unexpected exception escaped one of our calculation engines (rare — most engines have typed error handling).
- A database query failed during a non-read operation (transient connectivity issue, deadlock, or migration in progress).
- A required runtime dependency was misconfigured at deploy time and we caught it on the first request that needed it.
- An internal invariant was violated — usually a sign of a code defect we'll fix in the next release.
Learn more about how this works
Treat this the way you'd treat a 500 from any other API: it's our problem to solve, not yours. The response is intentionally vague because a detailed error message from a platform failure usually leaks implementation detail without helping the developer. The useful information lives in the request_id field — pass that to support and we can trace exactly what happened in our logs and Sentry.
Worth knowing: we never return internal_error for a problem the caller can fix. If the request payload was malformed, you'd get validation_error. If your key is wrong, you'd get an api_key_* code. internal_error always means us.
Example response
{
"success": false,
"error": "internal_error",
"message": "Something went wrong on our end. Please try again, or contact [email protected] if the problem persists. Include your request_id when contacting support.",
"details": [],
"retry_after": null,
"doc_url": "https://docs.asterwise.com/reference/errors/internal_error",
"request_id": "req_01HXYZABCDEFGH",
"timestamp": "2026-05-25T12:34:56Z"
}
- Retry the exact same request once after 1-2 seconds. Most
internal_errorresponses are transient. - If it fails again, save the
request_idfrom the response body and email it to [email protected]. - If your integration is in production and many requests are failing, check status.asterwise.com for an active incident.
Wrap calls in a single retry-then-report pattern. Don't retry-loop indefinitely — internal_error either resolves in one retry or needs human attention.
Python:
Production handler
- Python
- TypeScript
import httpx
import logging
import time
logger = logging.getLogger(__name__)
def call_asterwise(url, headers, payload):
for attempt in (1, 2):
response = httpx.post(url, headers=headers, json=payload, timeout=30)
if response.status_code == 500:
body = response.json()
if attempt == 1:
time.sleep(1)
continue
logger.error(
"Asterwise internal_error after retry",
extra={"request_id": body.get("request_id")},
)
raise RuntimeError(f"Asterwise failure: {body.get('request_id')}")
return response.json()
async function callAsterwise(url: string, headers: HeadersInit, payload: unknown) {
for (const attempt of [1, 2]) {
const response = await fetch(url, {
method: "POST",
headers,
body: JSON.stringify(payload),
});
if (response.status === 500) {
const body = await response.json();
if (attempt === 1) {
await new Promise((r) => setTimeout(r, 1000));
continue;
}
console.error("Asterwise internal_error", { request_id: body.request_id });
throw new Error(`Asterwise failure: ${body.request_id}`);
}
return response.json();
}
}
Avoid this error by
- Log the
request_idfor every error response, not justinternal_error. It's the fastest path to a fix when something does break. - Set sensible HTTP timeouts (10-30s) so a slow
internal_errorresponse doesn't cascade into your own timeouts. - Subscribe to status.asterwise.com — we post active incidents there before tickets pile up.
- Don't aggressively retry on
internal_error. One retry is fine; ten is just amplifying our outage.