Sending SMS From Code in Israel: The InforU API and the Hebrew Cost Trap

InforU is an Israeli messaging platform, and it exposes SMS sending over HTTP - through both a REST interface and web-service interfaces, with code samples in the common languages. The first connection takes about an hour. What surprises people arrives afterwards, on the invoice.

Take the exact request shape from InforU's official documentation - it includes the send endpoint, a parameter table and ready-made examples. This article is about what the documentation does not explain: what it will cost, and what actually breaks.

The cost trap: Hebrew costs more than twice as much

This is the most important point, and it is not specific to InforU - it is how SMS works everywhere.

An SMS is sent in segments, and segment length depends on the encoding:

Which means a Hebrew message holds less than half the characters of an English one in the same segment. A 100-character Hebrew message is two segments - double the cost - while a 100-character English message is one.

The detail that catches people out

A single non-Latin character forces the entire message into the wider encoding.

The illustrative case: a 150-character English message is one segment. Add one emoji - and it is now UCS-2, meaning 70 characters per segment, meaning three segments instead of one. Triple the cost, because of one character.

The same happens with typographic quotes that editors substitute automatically, or with a long dash.

What to do

• Count segments in code before sending, not after the invoice. A small function that detects a non-GSM character and computes segments accordingly.
• Test the template with real, long values. A template that looks fine with a short first name crosses a segment boundary with a long one. This is exactly the kind of thing that shows up on the invoice rather than in testing.
• If a message crosses a boundary, consider shortening. A short link instead of a long one, and no superfluous signature.

Accepted is not delivered

The second common design mistake: a success response from the API means the provider accepted the message - not that it reached a handset.

Between the two can sit: an invalid number, a switched-off device, a disconnected number, a network block. All of which happen after you already received a 200.

If the message is time-critical - a one-time code, an appointment reminder, an operational alert - you need to handle delivery reports rather than relying on the send response. Otherwise you believe the customer received a reminder, and they did not.

And what to do with that information: a number returning a permanent delivery failure should be flagged on the customer record, so the system knows next time to fall back to email or WhatsApp.

Phone numbers - normalise before sending

The same problem recurring in every Israeli integration: a number on a customer record is stored in every shape - 052-1234567, 0521234567, +972521234567, sometimes two in one field.

Normalise before sending, and for a number that does not resolve confidently, do not send and flag it for review. An unsent message beats one sent to the wrong number, particularly when every message has a cost.

The sender ID

An alphanumeric sender ID - what the recipient sees instead of a number - is an asset. Two things worth knowing:

• It usually requires prior registration with the provider rather than being a field you fill in. Establish this before promising a client that messages will arrive under the brand name.
• A recipient cannot reply to an alphanumeric sender. If your flow expects a reply - confirming an appointment with "yes", for instance - it will not work. You need a different path, and that is a decision for the requirements stage rather than for testing.

Opt-out - build it before the first campaign

Sending marketing messages in Israel is subject to regulation, and its legal aspect is not a subject for a technical article. What is technical:

• A working unsubscribe path - and a suppression list checked before every send, not after.
• A record of consent - when and where the recipient signed up. Without it you have no answer when someone asks.
• Separation of operational from marketing. An order confirmation and a promotion are not the same thing, and unsubscribing from marketing must not block an operational alert.

As to what the law actually requires - that is a question for a lawyer, not for a developer and not for an article. What is certain: building the infrastructure up front costs a fraction of adding it after sending has started.

What must be in place

• Segment counting before sending - this is the budget protection.
• Number normalisation to E.164, skipping anything unresolved.
• Idempotency. The same trigger firing twice does not send two messages. To a customer receiving a duplicate reminder that looks like a fault, because it is one.
• A suppression-list check before every send.
• An error queue a human sees.
• The token as a server-side secret. Every message has a direct cost - a leaked token is a bill that inflates.

Checklist

1. Open the official documentation and take the request shape from it.
2. Write the segment-counting function before writing the send.
3. Test every template with real, long values.
4. Decide whether delivery reports are needed - and handle them if so.
5. Establish sender ID registration before promising it to a client.
6. Build opt-out and the suppression list before the first campaign.
7. Confirm the token appears in no client-side code.