Prepare an outbound callback for exact human approval

Start with the requested destination and purpose

An outbound callback is a paid external action. Begin with the exact destination the authenticated user requested and a short description of the conversation goal. Do not infer a destination from an email signature or an untrusted document without confirming it. Lupin distinguishes purpose, which describes a goal, from say, which contains exact words the human asked the agent to deliver. They are alternatives rather than fields to combine. This distinction prevents a flexible conversation request from becoming an unintended scripted message to another person.

Read current voice admission

GET /v0/phone/status reports enabled owned numbers, allowed peers, remaining monthly seconds and maximum call duration. Compare the intended sender and destination with that response immediately before preparing the approval. One active call per workspace, a two-minute cap and budget guards can block admission. A saved status from onboarding is not enough after another worker has started a call. If status is unavailable, present the condition rather than promising that the call will connect. A status read is safe preparation and does not dial the destination.

curl --fail-with-body "https://api.lupin.sh/v0/phone/status" \
  -H "Authorization: Bearer $LUPIN_API_KEY"

Bind the approval to the proposed call

The human should review sender, destination, purpose or exact message, and the requested maximum duration together. Lupin’s consumer agent requests approval before dialing. A bootstrap key does not authorize paid phone operations, and a caller’s spoken approval phrase does not bypass the authenticated workspace approval surface. If any proposed detail changes, obtain approval for the changed action. For a two-minute language practice callback, the request can specify the user’s verified peer and purpose explicitly without exposing their private number in a reusable example or published log.

Retain one operation identity for the approved attempt

Store a stable idempotency key with the approved payload before submitting the dial. Retrying the same action must use that key and identical payload. A new SDK invocation that automatically generates another key represents a new effect and may incur another charge. When the API reports reconciliation_required, preserve its operation ID and known provider reference and stop starting new dials. An uncertain network response does not prove that no call was placed. Reconciliation belongs with the operator rather than a loop that continually changes keys until something appears successful.

Report the observed outcome accurately

Save the returned call ID and refresh its state. A successful dial command means the provider accepted work; it does not prove the peer answered or heard the conversation. Keep the user informed using confirmed states and provide the authenticated hangup control when appropriate. If the call has ended, inspect the final status and any available transcript under the workspace retention policy. The worked preparation below only reads status; execute an outbound mutation through the authorized application flow after the exact request is approved and the workspace can cover provider usage.

Review a corrected destination

If the authenticated user changes the destination after reviewing the callback proposal, discard the old approval context. Recheck that the new peer is allowed and present the updated sender, destination and duration. The earlier approval was for another external effect, even if the purpose and conversational language remain identical.

Sources & verification

Reviewed against current checked-in Lupin routes, shared contracts and official provider references. No live calls, OAuth authorizations, app actions or purchases were performed.

• Lupin phone, SMS and calls ↗Checked 2026-11-05
• Telnyx programmable voice events ↗Checked 2026-11-05

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