Provisioning Failures
The state machine
An agent request moves through:
pending ──► approved ──► provisioning ──► fulfilled
│
└──► rejected (with a note, non-instant agents only)
provisioning ──failure──► provisioning_failed ──Retry──► provisioningA provisioning_failed request shows a client-safe message in the Note column of Your requests (/dashboard/agents) or Agent Requests (/admin/agent-requests), and a Retry button — there’s no need to file a new request, retrying re-runs the same provisioning job.
Why it fails
Before AgentLane spends an API call importing and activating the workflow, every credential the agent’s catalog entry requires is live-checked — a bad Twilio token or an expired Anthropic key fails provisioning in seconds with a clear message, instead of after the workflow has already been half-imported. customjs is never checked (it isn’t a real stored credential).
A credential pre-flight failure is never retried automatically — a bad key doesn’t fix itself on a backoff schedule, so it fails the request on the very first attempt rather than burning through retry attempts first. Every other kind of failure (e.g. the workflow engine being briefly unreachable) gets a few automatic retries before landing on provisioning_failed.
What each error message means
provisioningErrorPublic | What actually failed | Fix |
|---|---|---|
| “Twilio credential invalid — verify your SID and Auth Token” | A live GET against the Twilio Accounts API failed with the given SID/token | Re-check the Account SID and Auth Token in Settings → Integrations (or the client’s own Settings → Credentials, if they override it) |
| “Anthropic API key rejected — check your key in Settings > Integrations” | A live GET /v1/models against Anthropic’s API failed | Re-check the key; make sure it hasn’t been revoked or hit a spend limit |
| “OpenAI API key rejected — check your key in Settings > Integrations” | Same check, against OpenAI’s /v1/models | Re-check the key |
| “Calendar integration failed — check your Cal.com credentials” | A live GET /v2/me against Cal.com’s v2 API failed | Re-check the API key — note Cal.com’s v1 API key format won’t work here, this checks against v2 |
| “Resend API key rejected — check your key in Settings > Integrations” | A live GET /domains against Resend’s API failed | Re-check the key |
| “Database connection failed — check your Postgres connection details” | A live SELECT 1 against the configured Postgres connection failed | Re-check host/port/database/user/password, and whether the database is reachable from AgentLane’s network (firewall/allowlist) |
| “Activepieces instance unreachable — contact support” | The provisioning call itself failed at the network level (not a credential issue) | Check Workflow Engine status, or contact AgentLane support — this isn’t something a credential fix resolves |
| “Provisioning failed — contact support” | An unclassified failure — something other than a known credential or connectivity error | Contact AgentLane support with the request ID; an Admin can see the full internal error in AgentRequest.provisioningError |
These pre-flight checks are skipped in local development (NODE_ENV=development) or when SKIP_PREFLIGHT_CHECKS=true — if you’re testing locally and provisioning succeeds despite an obviously invalid key, that’s why.
Retrying
Once you’ve fixed the underlying credential, click Retry on the request row. This re-queues the same provisioning job — it does not create a new request, and the request keeps its original ID and history.
Related
- Deploy your first agent — the request flow this failure interrupts
- Connect your integrations — the credential waterfall these checks resolve against
- Admin: Provision a partner — if the partner’s own instance (not a single agent request) is what’s failing to provision