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 Hologram · Apiary 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-

So I recently told someone trying to use the SIM7000 with’s service ( about Hologram’s SMS-over-IP and they alerted me to this message on the embedded page ( which says

SMS-over-IP is no longer supported and requests will receive an error from the Hologram Cloud endpoint. For device-originated outbound SMS, customers may continue to use circuit switched SMS with Hologram IoT SIMs.

I do not specifically remember this so I assume it’s new, and means this service will in fact go away soon. I just tried using it and it works. I am wondering if I’m grandfathered in and that’s why it’s still working for me? Does sending SMSs cost hologram $, and that’s why it’s no longer supported?

Hi @jwallis - thanks for your feedback on SMS-over-IP and recommendation to
another developer about it.
Our engineering team identified an issue where SMS-over-IP was used to generate high volumes of SMS spam and disrupted service for other customers. Due to this, we have ended support for onboarding new customers to this feature while continuing support for existing customers at this time. I’ll notify our documentation team to clarify that on the reference page, thanks for bringing that to our attention.