MessageNet (TCPIPReceiver) Consolidation – Sinch MessageMedia

× Sinch MessageMedia

× DirectSMS

× WholesaleSMS

× MobiPost

× SMSBroadcast

× SMSCentral

× Streetdata

✔ MessageNet

This article helps existing MessageNet TCPIPReceiver customers move from the legacy TCP-based SMS integration to the MessageMedia REST API. It describes how the current TCP protocol works, how it maps to the REST API, and what you need to change in your implementation. Your existing legacy credentials can not be used. BASIC/HMAC credentials should be created; the main change is sending one HTTP POST per message with a JSON body instead of a newline-delimited payload over a TCP connection.

Current state (TCP receiver)

The current integration uses a TCP-based receiver that listens on a fixed port (typically 7000). Clients open a TCP connection to the host and send a single message as newline-delimited text. The protocol has no formal framing. Authentication is done with a username and password. The receiver parses the buffer into fixed positions (reply path, reply type, username, recipient type, destination number, network, subject, and message body), then authenticates the user and lodges the message via the internal lodge service. The only operation supported is sending (lodging) a message. After processing, it sends a short response on the same connection: either ACK (ASCII character 6 followed by carriage return and “Lodge OK”) or NAK (ASCII character 21 followed by carriage return and “Lodge Error”). The connection is left open for the client to close.

Technical Guidelines

This section highlights key differences between the current MessageNet TCPIPReceiver and the REST API and provides key examples to understand the technical changes required for the transition. This is by no means a detailed documentation of the REST API endpoints.

How to Use REST API

Current legacy API customers need to set up a REST API key. This can be done by reaching our Support team.

Rest API developer’s guide can be accessed from Sinch MessageMedia Developer Guides – Sinch MessageMedia

API Endpoint Matrix Summary

Legacy API	Summary	REST API
TCP receiver (send message)	Sending SMS	POST /v1/messages

Guide to Transition

Sending SMS

MessageNet TCPIPReceiver SMS

Connect to host:7000, send one newline-delimited block, e.g.:

Sample example of a request payload

<ReplyPath>
<ReplyType>
<username>testuser

<RecipientType>1



<DestinationNumber>+61412345678
<Network>GSM



<Subject>Reminder for Monday 9am
<Body>This is the message body.

“The labels in angle brackets (e.g. <ReplyPath>) are for reference only. Send only the values; each value on its own line, with empty lines where indicated to keep positions correct.”
So the actual payload is newline-delimited values (and blank lines), not the tags.

Sample examples for success response payload

\x06\rLodge OK (ACK)

Sample examples for Error response payload

\x15\rLodge Error (NAK)

Key notes (TCP payload)

The payload is plain text, newline-delimited (\n); line endings may be \r\n or \r and are normalized to \n before parsing.
Fields are position-based: line index defines the field (e.g. line 0 = ReplyPath, line 1 = ReplyType, line 2 = Username, …). Empty lines are still required to keep positions correct.
Username is on line 2; password is not a separate field: it is the last word of the Subject (line 13) and/or the first word of the first line of the Message (line 14+). Both are stripped from subject and message before lodging.
Destination number is on line 8; Use international format where applicable (e.g. E.164).
Subject is a single line (line 13); Message is everything from line 14 onward, with line breaks preserved. Together they carry the visible content; the last word of subject and first word of first message line are treated as credentials.
ReplyPath (line 0) and ReplyType (line 1) are source/reply identifiers; RecipientType (line 4) is typically "1" or "2";
Network (line 9) is e.g. GSM or NZT (defaults to GSM if empty).
One payload = one message; one recipient per payload. The connection can be reused to send another message in the same format.

REST API Request

POST /v1/messages HTTP/1.1
Host: api.messagemedia.com
Content-Type: application/json; charset=utf-8
Accept: application/json
Authorization: Basic <base64(username:password)>
{
    "messages": [
        {
            "content": "<Subject> + <Body>",
            "destination_number": "+<mobile_number>",
            "format": "SMS"
        }
    ]
}

Concatenate subject and body as needed, or send only the body if your use case does not use a subject

REST API Response

202 Accepted
JSON response with message_id and status

Key changes

Existing legacy credentials can not be used. BASIC/HMAC credentials should be created via MessageNet platform. More info on credentials can refer to API Reference | ReDoc
You no longer open a long-lived TCP connection or send newline-delimited text. Send a single POST with a JSON body (can choose to send up to 100 messages in a single request); there is no form submission. Set Content-Type to application/json (not application/x-www-form-urlencoded).
No position-based parsing. The REST API uses named fields in JSON (e.g. content, destination_number) instead of fixed line positions. You do not need to pad empty lines or count newlines; build a JSON object with the appropriate keys.
ReplyPath/ ReplyType parameters are not supported in Rest API - you’ll need to use alternatives like specifying a source_address (for alpha sending) and setting up callback_url/webhooks if you require MOs/DRs to your own endpoints.
Network is not supported in REST API, should use format default value is SMS
Password is not sent in the message. With TCP, the password could appear as the last word of the subject and/or the first word of the message. With REST, authenticate via the BASIC Auth header and send only the actual subject and message content in the body, so credentials are not stored or logged in message content.
Response is HTTP status and JSON. Instead of reading ACK (\x06\rLodge OK) or NAK (\x15\rLodge Error) from the socket, check the HTTP status code (e.g. 202 Accepted for success) and parse the response body (e.g. message_id, status, or error details) from JSON.
TLS for transport. Use HTTPS for the REST API so traffic is encrypted in transit; the TCP receiver typically runs over plain TCP unless you use a separate TLS proxy.
More options in the message body. The REST API supports extra properties (e.g. delivery reports, scheduling, metadata) that the TCP protocol does not. See the Messages API documentation: API Reference | ReDoc