SMS providers and delivery queue
Configure the default SMS provider, test delivery, and manage pending, processing, or failed messages.
Last updated: 2026-08-19
Choose the provider
Select one default SMS provider for system functions or disable SMS explicitly. Available integrations can include ISP Billing, Clickatell, BeSMS, Skebby, SMS Hosting or SmsTools, SMSAPI, and GatewayAPI according to contract.
Disabling causes send requests to be skipped intentionally. Changing provider does not migrate credit, approved senders, whitelists, or provider history.

Provider-specific credentials
Clickatell uses a REST token; GatewayAPI uses token and sender; SMSAPI uses OAuth token and sender; BeSMS uses username, password, sender, and route ID; SmsTools uses AUTH_KEY, AUTH_SECRET, and sender. Skebby uses API username or email, password, message type GP/TI/SI, and an approved sender; legacy fields remain only for compatibility.
Keep credentials server-side, verify environment and balance, and never copy values between providers merely because field names look similar.
Sender, domains, and links
The sender name must be approved by the provider and comply with destination-country rules. When messages link to Customer Area, configure and verify the final custom domain; GatewayAPI may require that domain in an anti-fraud whitelist.
Open the complete link on the production hostname before enabling automatic messages. Avoid unauthorized URL shorteners and never place credentials or personal data in query strings.
Test message
After saving the default provider, use Send test message with an authorized number in international format. This performs a real provider request and may consume credit.
A successful response proves provider acceptance, not handset delivery or reading. Verify balance, provider log, delivery state when available, and the destination phone.
SMS queue
The queue displays jobs that are Pending, Processing, or Failed; completed jobs leave this operational view. Filter by state, recipient, and message type and inspect attempt count and the date from which the job is eligible.
A long-running Processing state may indicate a worker or provider timeout. Check the job and provider before sending the same communication manually.

Retry, remove, and clear
Retry makes a failed message immediately eligible; first correct the provider, credit, number, sender, or credential problem. Remove cancels one pending or failed job.
Clear queue removes all pending or failed messages in scope and can interrupt invoice, ticket, reminder, or marketing automation. Review filters, volume, business impact, and duplicate risk before confirmation.
Checklist
- Select one intentional default provider
- Complete the provider-specific fields
- Protect tokens and passwords
- Approve sender and required domains
- Verify balance and international number format
- Use an authorized test recipient
- Separate acceptance, delivery, and reading
- Inspect worker and provider state
- Correct the cause before Retry
- Assess duplicate risk after timeouts
- Clear the queue only with understood impact