Verify: start

Phone verification in two calls: this one sends a 6-digit code, check compares it. Sendy generates the code, stores only its hash, counts attempts and expires it; your app keeps nothing but the verification id. to is an Israeli mobile number (E.164 or local 05XXXXXXXX); from is one of your approved senders; locale is "he" (default) or "en". The message text is fixed: in Hebrew קוד האימות שלך ל-{sender} הוא 482913 (a phone sender names nothing: קוד האימות שלך הוא 482913), in English Your {sender} verification code is 482913. It cannot be customised, which is what keeps it a service message rather than marketing content.

Policy: 6 digits · valid 10 minutes from the last send · 5 wrong checks lock the verification · a resend is allowed after 60 seconds, up to 3 sends in total · 1 credit per code sent, checks are free. 056/059 numbers cannot receive codes and are refused up front (UNSUPPORTED_PREFIX, not charged).

Calling start again for a phone whose verification is still open does not open a second one: the same id comes back. Past the cooldown that is a resend (one more credit); inside it the response is 200 with retry_after and nothing is sent or charged, so a double-click or a page refresh never bills twice; a request that arrives while the first code is still being sent gets 409 VERIFY_IN_PROGRESS. A start with a different from or locale closes the open verification and opens a new one. An optional Idempotency-Key header replays the original response.

curl -X POST https://sendy.co.il/api/v1/verify \
  -H "Authorization: Bearer sk_live_8Jc…" \
  -H "Content-Type: application/json" \
  -d '{ "to": "0501234567", "from": "Sendy", "locale": "he" }'

const res = await fetch(`https://sendy.co.il/api/v1/verify`, {
  method: "POST",
  headers: { Authorization: "Bearer sk_live_8Jc…", "Content-Type": "application/json" },
  body: JSON.stringify({ to: "0501234567", from: "Sendy", locale: "he" }),
});
const verification = await res.json(); // keep verification.id with the user's session

{
  "id": "cmv8s1x2y0001abcd12345678",
  "status": "pending",
  "to": "+972501234567",
  "from": "Sendy",
  "locale": "he",
  "sends": 1,
  "max_sends": 3,
  "attempts_left": 5,
  "expires_at": "2026-10-24T14:10:00.000Z",
  "last_sent_at": "2026-10-24T14:00:00.000Z",
  "retry_after": null,
  "delivery": "sent",
  "created_at": "2026-10-24T14:00:00.000Z",
  "verified_at": null
}

Build it yourself, or use this?

POST /messages in transactional mode still works for a code you generate and store yourself, and is the right choice when you need your own wording, another channel alongside SMS, or codes that are not phone verification. Verify is the right choice when you want none of that logic on your side: the price per SMS is the same, and the message text, the attempt counting, the expiry and the per-number abuse limits are Sendy's problem.

Verify sends no webhook events: message.* covers POST /messages sends only. Read a verification's outcome from the check response, or its delivery from GET /verify/{id}.