Skip to content
Build with our iMessage API - Start for free
No credit card required
No credit card required
Get API Access
or
Use the CLI

Sign in with
iMessage.Beta

Your user taps, Messages opens prefilled, and send is the entire login. Sender-bound proof, straight to your webhook.

Get started Read the API docs
No passwords, no OTP boxes, no email loops.
SSupabase Claude active
Agent started signup

Copy setup instructions for your agent

01 · app → API The tap creates a login Your backend opens a short-lived login. Messages is prefilled.
The login flow

Three steps. One belongs to the human.

Your app makes two calls. The user taps send once. Sendblue proves the human in between.

01 · app → API

The tap creates a login

Sign in with iMessage calls your backend, which starts a short-lived verification. The response carries everything the button needs — no form ever renders.

POST /services/VA9f2c1e08/verifications sms_deep_link: "sms:+16282540923?body=K7F3XQ" status: "pending"
Messages opens · prefilled, nothing to type
02 · human → Sendblue

The human hits send

One prefilled text from the phone in their hand. That is the entire ceremony — nothing to read, copy, or type back.

FROM +14155550142 TO +16282540923 BODY Login request: K7F3XQ
message delivered
03 · signed in

Approved means signed in

The user is in. Behind the scenes, in those same few seconds: Sendblue bound the approval to the sending phone, your webhook received the proof, and the session started — known numbers log in, new numbers become accounts.

sender matched & bound · +1 415 555 0142 webhook verification.approved session find_or_create → signed in audit GET /verifications/VE7d4a90cc
signed in · no password exists
Why send beats type

Verification without the verification UI.

The user proves possession with one send. Your product does everything else in code.

Zero-field login

No email, no password, no code to copy back. A new number is the same gesture — the sender becomes the account.

Human-authorized

The proof comes from a message sent by the claimed phone. The code and sender must match the same verification.

Twilio-familiar

Services, verifications, status transitions, and webhooks map to concepts your team already understands.

Quickstart

Three calls from proof.

Create a service once, start a verification for each login, then listen for approval. Twilio-shaped — services, verifications, and status checks you already know.

create-service.sh

        

      

    



    

    

      

        

          Pricing
          
Start under the Sendblue name.

          
Prove the workflow first. Move to your own brand when verification becomes part of your product.

        

        

          

            
Sendblue branded

            
$0 to start

            
Build and test with Sendblue as the visible verification sender.

            Get API keys
          

          

            
Your own brand

            
Custom

            
Use a dedicated identity, messaging number, and production support.

            Talk to Sendblue
          

        

      

    



    

      

        FAQ
        
The details humans will ask.

        

          

            
            
A standard OTP is usually delivered to a user and then copied into a form. Sendblue Verify asks the claimed phone to send the code. The approval is created from the matching code and sender together.

          

          

            
            
          

          

            
            
          

          

            
            
          

          

            
            
          

        

      

    


    

      

        
The login users don’t bounce off.

        
One button, one send, one webhook — sitting right beside Google and Apple.

        Get Sendblue Verify API keys