Keep credentials out of browsers and logs.
Connect messaging to your systems
SMS API for systems and applications
Connect your app, CRM or store to ITBeep messaging in Jordan. Understand authentication, Arabic encoding, message identifiers, error handling and API versus SMPP.
From request acceptance to the delivery report.
Get help setting up sending and reporting.
From application to message
Authenticate securely and trace each message
Your application server sends using the account credential and authentication method in the approved integration documentation. Never place credentials in public JavaScript, analytics URLs or source control. Redact credentials and OTP content from request logs and use HTTPS.
A send request contains the account key api-token, sender name SenderText, mobile number MobileNumber and text MessageBody. Keep the endpoint and key in server settings. Check the HTTP status and success value after sending, then follow delivery reporting. Your integration documentation describes response fields and message identifiers.
- ✓Normalize Jordanian mobiles to 962 followed by the number without its local leading zero.
- ✓Test Arabic, mixed text and segmentation before estimating costs.
- ✓Link your business reference to the message identifier available in the response.
const url = new URL(process.env.SMS_SEND_URL);
url.search = new URLSearchParams({
"api-token": process.env.SMS_TOKEN,
SenderText: approvedSender,
MobileNumber: recipient,
MessageBody: messageText
}).toString();
const response = await fetch(url, {
redirect: "error",
signal: AbortSignal.timeout(10000)
});
const result = await response.json();
if (!response.ok || result.success !== true) {
throw new Error("Submission not confirmed");
}API or SMPP?
API or SMPP: which fits your system?
SMS API suits stores, apps and CRM systems: send when an order, sign-in or appointment occurs. SMPP suits systems managing persistent connections and large volumes. We help set the submission rate for your account and destinations.
Correct input errors, such as an invalid number, before retrying. For temporary outages, increase the delay between attempts. If a request times out without a result, check its status before resending to avoid duplicates. Keep a stable reference for each operation.
When using a status webhook, verify its source according to your integration settings. Notifications can arrive more than once or out of order. Update the message by its reference without sending the text again.
Implementation steps
How we prepare and launch the service
We review the use case and requirements, then test the setup before production sending begins.
- 01Short technical review
Triggers, destinations, volume, and systems.
- 02Credentials and testing
Sample requests and intentional errors.
- 03Connect status reporting
Secured webhook and idempotent handling.
- 04Monitored launch
Limited traffic followed by controlled scale.
Information we need
Share these details for an accurate proposal
These details help us confirm pricing, requirements, and the right operating model from the first conversation.
- 01Programming language and source system
- 02Use cases and templates
- 03Destinations, volume, and peaks
- 04Webhook and logging requirements
Frequently asked questions
Straight answers about the service
Is a test environment available?+
We define the available testing approach during technical setup before production credentials, covering success, errors, and reporting.
Can the API handle OTP and campaigns?+
It can support multiple workloads, but we separate flows, templates, and rates so sensitive traffic does not get mixed with campaigns.
What is the difference between API and SMPP?+
HTTP APIs are simpler for most apps. SMPP generally suits providers and high-volume operations needing persistent sessions.
Related services