@muratk the motivation for an API is to enable user-level applications to provide cost/volume estimates to the end-user.
These apps can of course include their own encoding & splitting logic, but that creates the possibility that the API provider and app count messages differently creating error.
It’s a bit like the “price-the-cart” problem where it’s best to have a single code path.
For example, I’ve seen some SMS systems use a simple logic for charset encoding and CSM calculation as follows:
- try to encode message buffer in GSM 03.38
- If succeeds, divide number of characters by 160 to determine number of SMSs
- If fails, divide number of chars by 70 to determine number of SMSs
But a more sophisticated system would encode each individual message in a CSM as efficiently as possible, so that if a non-GSM char appeared once, say in the first 70 chars, the first message would be Unicode encoded, but the rest of the buffer would go as GSM.
If the underlying service provider uses one approach and the app another, counts will be off.