lupin.Open console
Reliability & costs

Diagnose an admission rejection before investigating the provider

Separate local budget or entitlement rejection from an attempted provider request, and preserve the journal when recording that rejection fails.

Locate the earliest failed boundary

A paid operation can fail during authentication, resource authorization, billing admission, usage reservation, durable checkpoint storage or the provider call itself. A single red error banner hides these distinct facts. Begin with the structured code and operation phase, then locate the earliest boundary whose success is not established.

For example, a budget rejection is a decision about starting new activity. It is not evidence that an upstream service is down. Increasing request timeouts or retrying against another provider does not repair a missing permission, exhausted allowance or unpriced action under an active spending limit.

Understand the durable rejection requirement

The Lupin phone wrapper records an operation before spending and performs admission before invoking the provider execution callback. Expected billing and usage errors become a rejected journal state with a saved error and status. That saved state makes an identical replay return the rejection consistently across workers.

Persistence is part of the proof. If saving the rejection fails, the wrapper returns a reconciliation requirement instead of presenting an ordinary final rejection. Its message can establish that this attempt did not start a new provider request while still warning that durable admission state needs inspection. Preserve both parts of that statement.

Check allowance, budget and pricing separately

Read billing usage for customer retail allowance and overage admission. Read the usage ledger and budgets for configured provider-cost limits and outstanding reservations. They answer different accounting questions. An organization can have included allowance remaining while a matching provider-cost budget blocks an unbounded or unpriced action.

A configured price estimate also has a required scope. The documented SMS maximum must cover the entire accepted send, including segments, media, destination and carrier charges. Substituting a convenient base price does not establish a safe upper bound. A refusal to admit such activity can be the intended control.

Keep journal and provider evidence distinct

An operator should capture a compact incident record containing the error code, durable phase, admission category and whether the provider invocation boundary was crossed. Avoid treating a provider reference as mandatory when no provider request began. Its absence is useful context, although absence alone never proves a negative.

If the state cannot be read reliably, stop replacements for that action and retain its retry identity. Storage recovery may reveal a committed reservation or an older attempt. Sending a new action while the journal is unavailable trades a local availability problem for a possible duplicate external effect.

Repair the cause through the correct control

A permissions problem requires an authorized key decision. Exhausted included usage requires a plan or explicit overage decision. An active provider-cost limit requires a verified bounded rate or a different authorized workflow. These are deliberate account changes, not automatic incident workarounds.

After the cause is resolved, check the original operation’s documented replay behavior before submitting anything new. A durably rejected identity may continue replaying its recorded rejection. A separately authorized new action needs its own identity and a clear explanation of why the original cannot still produce an external effect. Keep that decision in the incident record.

Sources & verification

Reviewed against the checked-in Lupin implementation and official reference documentation on 2026-11-05. Operational examples are illustrative; no live paid action, provider mutation or external message was executed.

Prepared with AI assistance by Lupin editorial. How we research and maintain these guides.

Put it into practice

Give your agent the right tools.

Review the API, workspace requirements and permissions before enabling a workflow.

Explore phone See plans