Israeli SMS Gateways for Developers: How to Choose

Before comparing vendors, one technical fact decides more than any pricing feature: a Hebrew SMS holds 70 characters per segment, not 160. That comes from the encoding, not the vendor - and it means every Hebrew message that looks short is usually two or three segments in practice.

The encoding, and why it sets the budget

The SMS standard defines a basic alphabet (GSM-7) containing Latin characters and selected symbols. Hebrew is not in it. The moment a message contains a single Hebrew character, the whole message switches to UCS-2 encoding.

The practical consequences:

• A 200-character Hebrew message is not one message - it is three segments, and billed as three.
• Mixing in Latin does not help. One Hebrew character drops the entire message to 70. There is no mixed encoding.
• A long link can add a whole segment. URL shortening is not cosmetic - it is a direct saving.
• An emoji drops even a Latin message to UCS-2.

What to build: segment counting on your side, before sending, shown to whoever writes the message. Otherwise you discover it on the invoice.

The Israeli landscape

Several established vendors serve the market - among them InforU, SMS4Free (formerly Cellact) and others - all offering a send API. There is no shared standard between them.

That is the point that matters to a developer: Israeli vendors use their own API shapes, not Twilio's conventions. Most sample code you find online assumes the Twilio pattern - a particular resource path, a particular auth style, a particular response shape - and that is not what you will get.

So budget for reading the chosen vendor's documentation. Field names, authentication method and response structure must come from their official docs, not from an assumption or a familiar pattern. It is not complicated - but it is not guessable.

The seven questions that decide fit

1. Are there delivery reports?

This is the first question, not the last.

SMS is a channel without read receipts - and without a per-message delivery status there is no way to know whether a message arrived, was rejected, or vanished. Which means when a customer says "I never got it", you have no answer.

What to check: does the vendor push a callback to your endpoint, or must you poll for status? The former is better.

2. What does the sender look like?

A message can arrive from a text sender name or from a number. That affects recipient trust and their ability to reply.

The point that derails projects: if the sender is text, the recipient cannot reply. If your process expects a reply, you need a number, and you need to confirm the vendor supports inbound messages and forwards them to you.

3. What happens with opt-outs?

Who handles removal requests - the vendor or you? If you, you need a mechanism that catches the keyword, records it, and blocks future sending to that number across every campaign, not just the current one.

This is not a minor technical detail. It is an obligation taken seriously, and it belongs in the data layer rather than in the sending code.

4. How are phone numbers normalised?

Israeli numbers arrive in every form: with dashes, without, with the country code and without. Normalise to E.164 once on entry to the system and store it that way - do not fix it on every send.

And remember: an Israeli number in E.164 loses the leading zero. A mobile prefix of 052 becomes +97252 followed by the remaining digits.

5. Is there a rate limit?

Bulk sending without throttling gets blocked. Check the permitted rate and build a queue with delay, not a loop that fires everything.

6. What happens when a send fails mid-run?

A thousand-recipient campaign that died after 400 - what happens when you run it again? If the answer is "the first 400 get it twice", that is not a ready system.

The fix is a per-recipient record with a status, and a resume that skips whoever already received it.

7. What does authentication look like?

A key in a header, a token in the request body, a username and password - this varies by vendor. What is identical across all of them: the secret is not in the code and not in version control.

The trap in Hebrew itself

Beyond character counting, Hebrew text carries further problems that show up specifically in SMS:

• Invisible directional characters that sneak in from copy-paste - they count as characters and eat into the budget.
• Mixing Hebrew and numbers - the display order on the recipient's handset is not always what you saw in the editor. Test on a real device, not in a console.
• Inconsistent encoding at the source - if a customer name comes from another system, it can arrive corrupted.

The question that comes before all of this

Before choosing an SMS vendor, it is worth asking whether SMS is the right channel at all.

In Israel the answer today is usually WhatsApp - usage is high, there is no 70-character limit, and you can send media and hold a two-way conversation. That carries its own costs: templates approved in advance and a defined time window for free-form messaging.

Where SMS still wins:

• One-time verification codes. Works without internet, without an app, without prior sign-up.
• A critical message to someone without WhatsApp.
• When you need to reach a number that agreed to nothing in advance - and even then, subject to the rules on marketing contact.

Selection checklist

1. Choose the channel first - SMS or WhatsApp.
2. Count Hebrew segments before estimating cost.
3. Require delivery reports.
4. Decide whether you need inbound messages - that determines the sender type.
5. Build opt-out as a data layer that spans campaigns.
6. Normalise to E.164 on entry.
7. Read the specific vendor's documentation - do not assume a shape.
8. Plan a resume that does not send twice.