SMS.ir or a phone gateway? How ClassBan sends school SMS

School software that needs to send SMS has two simple options: the API of an online provider (such as SMS.ir) or a gateway on a phone that turns your own SIM card into an HTTP service. ClassBan supports both.

Two options, two kinds of trouble

Online provider: you need an account, an API key and credit. In return you do not need a phone that stays on and connected. You depend on internet access and your balance.

Phone gateway: a phone on the school network acts as an HTTP server and sends messages with its own SIM. By default ClassBan calls a Traccar SMS Gateway. Costs follow your SIM tariff and you do not depend on an outside service; but the phone must stay on, charged and on the network, and it can hang or get rate-limited by the carrier if you send a lot.

I deliberately give no prices; tariffs change, so ask your provider or carrier.

ClassBan's structure: primary and fallback

Sending tries the phone gateway first; if that fails, SMS.ir is tried as the fallback. URLs and keys come from environment variables, never from code.

The send queue

Sending 30 messages at once would hang a phone, so messages go through a queue: a default 5-second gap (configurable), automatic retries with a growing delay (1×, 2×, 3× the base gap) and at most 10 attempts before the message is dropped and logged.

An honest limitation: the queue lives in memory. If the app closes mid-send, unsent messages are lost. That is acceptable for a few dozen messages a day; heavier use needs a persistent queue.

Normalize phone numbers

One of the most common reasons an SMS "did not go" is the number format. ClassBan strips everything but digits and adds a leading 0 to 10-digit numbers starting with 9.

Which one?

Small school, low volume, someone who looks after the phone: a phone gateway is enough. No dedicated phone or higher reliability needed: an online provider. Both available: primary plus fallback with a queue and a log. See also the attendance and SMS guide.