Is it possible to include '\n' in SMS-ovef-IP using the Embedded API?

Embedded API page:

This page clearly shows the format for a string sent, including the final part of the string:
Message – Text of the SMS message. Separated from the destination number with a space and terminated with two newline characters

1.What can I do if I want to send an SMS containing “Hello\n\n\nskipped some lines” ? I have tried using \r and the behavior is the same. I get return value “00” success, but only the first line, ie “Hello” is sent.

2.On a related note, the lifetime of this embedded API is “for the foreseeable future or forever” I hope? I hope to use it in a product I’m building. I just hope it isn’t sunset in the next 5-7 years.

Test code:
printf ‘S________+15554443333 Hello\n\n\nSMS!’ | nc -i1 9999

Potentially related, very old post I found in my search prior to posting:

Running into the same issue and have tried all sorts of special characters. Nothing worked.

Is there a way?

If I could just have 1 newline that would be enough for my purposes, but that doesn’t work, even though it should work according to the specs above (which say 2 consecutive newline chars)

Hey guys, we’ll take a look at this and get back to you. I think the intention was for a newline to work here.


Hey Reuben, please let us know if you found anything. Many thanks-

Working on it now. Should have an update for you guys tomorrow

Ok so the docs apparently never reflected reality here. We’ve always taken a single newline on the SMS endpoint to end the connection.
We’re going to leave that in place, but now you can send the characters \n (not an actual newline) to create a newline in the message.
Let us know if that gives you any trouble.
We’ll update the docs with this information soon.

Hey, that’s great! I hope that doesn’t screw up existing customers, but I just tried it and it works great for me. Thank you SO MUCH for your prompt attention and solution! This has removed a big barrier to my project!

You’re welcome. We planned it so that it should be backward compatible with whatever people are doing so hopefully no issues out there.

I am having some issues after this change. I was sending two newline characters at the end of the sms message. This stopped working.

After seeing the changes to the docs, I removed the second newline character. It still doesn’t work. I have #474 internal error on the dashboard.

My hardware is an arduino NB 1500. I am using my own library with SARA R4. After opening a TCP socket, I send the following: SABCDWXYZ+12075555555 Smoke detected
with one newline character at the end.

hi @Rick_Zeldes - our engineers are currently working on an issue affecting SMS-over-IP and have posted a status adivsory on our status page. Please follow at for continual updates.


Seems to be working again.

Engineering team released a fix for this and you may have beat them to the status page update! Thanks!

Oh hey Reuben or Ryan, from my original question above - what do you expect the lifetime of this service with this specific functionality/form to be? I’m pretty convinced I’ll be using this service in a product that I’ll be selling which once sold will be no longer in my control, so they won’t be updatable. I know Hologram has sunset the Dash and probably support for it, but I believe the API / backend is intended to continue. Anyway, I’m sure you get my concern… :slightly_smiling_face:

Hi @jwallis - At this time, there are no additional roadmap plans prioritized for this service as well as the underlying embedded API. While we don’t have any plans to end support for this endpoint currently, we are increasingly seeing fewer customers build with this feature and instead favoring their own integration and control directly to SMS services from their own application servers.

Well, that is… not as comforting a reply as I’d hoped. I really like the simplicity of the embedded API, but would it be significantly safer (in terms of how long the service is expected to exist) to use Hologram’s REST API to send SMSs?

Having 2 services (one for cellular connectivity and one for SMS, such as Twilio I guess) would not be an acceptable solution for my users.

That API call is for sending an SMS message to one of the SIMs, not for device-originated SMS so may not be what you want.
Not totally clear on your application, but its probably safe to continue moving forward using the SMS-over-IP endpoint. We would not end support for this without a lengthy warning period and as of now there are no plans to start going that route.
If you want to get into more detail feel free to reach out to our support team at and they might be able to provide some more guidance on your application.

Ah, I should have realized that, that makes sense. Thank you, this helps-