── Telecom Lab ──
Building real systems on
programmable infrastructure.
I build on the 46elks API — SMS, Voice, and phone numbers as engineering primitives. Documented as I go.
── Principle ──
Communication is infrastructure, not a feature.
Most systems treat SMS and voice as afterthoughts — a notification bolted on at the end of the stack, routed through a managed platform nobody fully understands.
That framing is wrong. When a server goes down at 3am, email won't wake you. When a call needs routing, a SaaS platform adds a layer you don't control. When your system needs to speak, it should speak directly — through an API you own.
46elks exposes telephony as a clean REST interface. No platform lock-in. No managed abstractions hiding the protocol. Just HTTP, basic auth, and a phone network. These experiments document what you can build on top of it.
── Built on ──
Alerts, OTPs, notifications
Single POST request. No SDK. Delivers to any number, globally.
IVR systems, call flows
Webhook-driven call logic. TTS, keypress routing, call transfers.
Dynamic routing, on-call
Provision and configure numbers via API. Route by schedule or rule.
── Featured Experiment ──
SMS-Based Server Downtime Alert System
A 3am outage. Email doesn't wake you. PagerDuty adds a managed layer I don't want. The question: can a direct 46elks SMS call — triggered by a dead health check — close that gap reliably, with no platform in between?
// The entire alert leg. No SDK. No wrapper. const body = new URLSearchParams({ from: 'Monitor', to: process.env.ALERT_PHONE, message: `[DOWN] ${CONFIG.targetUrl} unreachable. ${ts}`, }).toString(); await fetch('https://api.46elks.com/a1/sms', { method: 'POST', headers: { 'Authorization': `Basic ${b64Credentials}`, 'Content-Type': 'application/x-www-form-urlencoded' }, body, }); // → { "id": "s8e3a6f0...", "status": "created" }
── Live Demo ──
Enter your phone number. A real SMS gets delivered via a single POST to the 46elks API — no platform, no SDK.
── API CALL THAT JUST RAN ──
Rate limited · No data stored · One message per hour
── About ──
I'm Adham. I build on telecom infrastructure and document what I find — what works, what breaks, and what the API actually looks like when it's doing real work.
API-first. Telecom-native.
More about me →