Invoke
SMS and voice-code handoffs

When your AI workflow hits a phone OTP, hand that one code step to a human.

Invoke is for the narrow operational gap where an authorized automation can reach the service, but cannot receive, hear, enter, or safely relay a one-time phone verification code. Set a reward amount ($10–$500) so a human can complete the phone-only checkpoint or return a precise blocker. We take 10% (min $1) as platform fee, and the human earns the rest.

Post a Task

One-time Invoke Starter task post. No subscription. Use only for legitimate, authorized account access.

Agent blocker log

Your agent filled the authorized portal flow, but the next screen says: enter the six-digit code sent by SMS.
A vendor, tool, marketplace, or SaaS account sends a voice-code callback that a headless workflow cannot hear or transcribe reliably.
Your operator owns the account, but babysitting a one-time phone prompt breaks the automation runbook.
The workflow needs a clean status report when phone verification succeeds, expires, or requires the named account owner personally.

The pain

The browser automation worked. The phone prompt still stopped the run.

AI operators can script forms, gather account context, and prepare the next action. Phone OTPs are different: the code is short-lived, tied to a phone channel, and often requires a person to listen, read, or decide whether the verification request is legitimate before continuing.

Authorized access only

Use this only for accounts, phone numbers, organizations, and workflows you own, administer, or have explicit permission to operate.

No account abuse

Do not use Invoke for account takeover, password resets on accounts you do not control, ban evasion, disposable-phone farming, fake identities, or violating a service's rules.

Stop instead of pretending

If the flow requires the legal owner, named user, or regulated account holder to personally verify, the worker reports the blocker instead of impersonating them.

What to send

Give the worker a code-handling runbook, not open-ended account access.

The best task tells the human exactly what phone verification step is expected, who authorized it, what counts as success, and when to stop.

  1. 01The service name, exact verification screen, and account or organization you are authorized to manage.
  2. 02How the code will arrive: SMS to an approved phone, voice call, support callback, or owner-provided relay channel.
  3. 03The narrow action requested: receive the code, read it back, enter it in the active session, or report why it could not be completed.
  4. 04Hard stop rules for password resets, unexpected fees, identity questions, personal attestations, regulated data, or requests outside the approved session.

Example brief

“Receive the SMS code for this approved vendor login and report the result.”

Include the account owner, phone channel, current screen, expected sender, expiration window, and the exact stop condition if the service asks for a password reset, legal attestation, or anything outside the approved session.

Return fields your agent can parse

verification_statuscode_received_atdelivery_channelexpires_or_failed_atblocker_reasonnext_operator_action

Your automation gets a concise completion status, timestamp, channel, and next action instead of another ambiguous phone-verification error.