SMPP connection

SMPP is a permanent connection to Blackbox Business: your application binds once and keeps the session open, messages go out over it, and delivery receipts come back over the same session without a single request from your side.

That is what makes it the choice for steady volume. There is nothing to poll and nothing to schedule: the moment the operator reports a message, the report is already on your socket.

Where to connect

	Address	Port
Plain	smpp.blackbox.business	3700, 2775
TLS	smpp-tls.blackbox.business	2995

Both ports on the plain address behave the same way — use whichever your library defaults to. The TLS address carries its own certificate, chosen by the name you connect to, so point your client at the name and leave certificate verification switched on.

Credentials

The session uses your cabinet account:

Field	What to put in it
system_id	Your cabinet login
password	Your cabinet password
system_type	Leave empty

Two things are set once on the API settings screen:

• SMPP — the switch that opens the protocol for the account.
• IP address — fill it in, and the session is accepted from that address only. Leave it empty, and any address with the right password is accepted.

Binding

All three bind types are accepted: bind_transmitter, bind_receiver and bind_transceiver. One bind per connection — for sending and receiving at once, bind as a transceiver, or open a second connection as a receiver.

Sending

Messages go in submit_sm.

Field	What it means here
source_addr	The sender name. Register it in the cabinet first: the session sends under the names approved for your account
destination_addr	The recipient's number in international format
data_coding	0 — GSM 7-bit, 1 — ASCII, 3 — Latin-1, 8 — UCS-2
registered_delivery	Ask for a delivery receipt
validity_period	How long the message stays worth delivering
schedule_delivery_time	Send later instead of now

Length and parts. A single message holds 160 characters in GSM 7-bit and 140 octets in UCS-2; in a multi-part message a part holds 153 and 134. Both ways of splitting are understood — the UDH in the message body and the sar_msg_ref_num / sar_total_segments / sar_segment_seqnum fields — and parts are counted the same way as everywhere else in the cabinet, so the number in your report matches the number on your invoice.

submit_sm_resp returns a message_id. Keep it: the delivery receipt for that message carries the same value.

Delivery receipts

Receipts arrive as deliver_sm in the standard receipt form:

id:0199ab45-6c7d-7e8f-9012-3456789abcde sub:001 dlvrd:001 submit date:2609171432 done date:2609171433 stat:DELIVRD err:000 text:

id: is the message_id from submit_sm_resp, and stat: is the outcome:

stat:	What happened
DELIVRD	The operator confirmed delivery to the phone
ENROUTE	On its way, the outcome is not known yet
ACCEPTD	Accepted by the operator
EXPIRED	The validity period ran out before the phone came back online
UNDELIV	The operator did not deliver it
REJECTD	The message was not accepted for sending
DELETED	The message was cancelled
UNKNOWN	The operator reported no outcome

Answer each receipt with deliver_sm_resp. Up to twenty receipts are kept in flight at once, and the next ones follow as soon as you acknowledge the ones already sent.

Keeping the session

Send enquire_link on a quiet session — once a minute is plenty — and the session stays up for as long as your application keeps it. unbind closes it cleanly.

What the session understands

PDU
bind_transmitter, bind_receiver, bind_transceiver	Opening the session
submit_sm	Sending a message
deliver_sm	Delivery receipts and incoming messages, from us to you
deliver_sm_resp	Your acknowledgement of a receipt
enquire_link	Keeping the session alive
unbind	Closing the session

Everything sent over SMPP lands in the same reports as everything else: the cabinet's report of sends through the API and SMPP shows these messages line by line, with the same statuses the receipts carry.