Skip to main content
Every non-2xx response throws a typed subclass of EigenpalError.
HTTPClassNotes
400EigenpalValidationError.issues carries per-field problems
401EigenpalAuthErrorBad / missing API key
403EigenpalForbiddenErrorAPI trigger disabled, scope mismatch
404EigenpalNotFoundErrorWorkflow / execution doesn’t exist
429EigenpalRateLimitError.retryAfter is the server-suggested wait (seconds)
5xxEigenpalServerErrorAuto-retried up to maxRetries
timeout / abortEigenpalTimeoutError
import { EigenpalClient, EigenpalValidationError } from '@eigenpal/sdk';

try {
  await client.run('workflows.extract-invoice');
} catch (err) {
  if (err instanceof EigenpalValidationError) {
    for (const issue of err.issues) {
      console.error(`${issue.field}: ${issue.message}`);
    }
  }
  throw err;
}

​
Retries

The SDK retries on 5xx, 429 (honoring Retry-After), and network errors. 4xx errors are surfaced immediately as typed exceptions. Configure via maxRetries: 
new EigenpalClient({ maxRetries: 3 }); // default
Backoff is exponential (250ms, 500ms, 1s, 2s) unless the server returns Retry-After.

​
Request id

Every error carries requestId from the server’s response header. Forward it to support for fastest triage: 
catch (err) {
  if (err instanceof EigenpalError) {
    log.error({ requestId: err.requestId, status: err.status }, err.message);
  }
}

​
Bad baseUrl

If baseUrl points at a non-API host (the marketing site, a misconfigured proxy), the SDK throws EigenpalError with a clear message instead of returning HTML or surfacing a downstream JSON-parse crash. Set baseUrl to your EigenPal instance root.