What is an x-header (custom header)
If you’ve ever poked around an API request in Postman, you’ve probably seen headers like X-API-Key or X-Request-ID sitting above the payload. Those are X-headers – custom HTTP headers that don’t belong to any official web standard. Developers add them to pass extra information a request needs – who’s calling, how to trace it, what format to expect back – without touching the URL or the body. The “X-” prefix used to be the go-to naming convention for anything non-standard, and even though it’s technically retired, you’ll see it everywhere.
How does an x-header work
An HTTP request is really just a block of text: a method, a URL, and a set of headers before the body. Standard headers like Content-Type or Authorization are defined in official specs, so every server and client agree on what they mean. An X-header is anything outside that list – you invent the name, you invent the meaning, and the API you’re talking to has to know to look for it. X-API-Key is a common one – it hands over a credential without touching the Authorization header. X-Request-ID lets you tag a single call so you can trace it through logs later, which matters when a request bounces through several services before it fails. Back in 2012, RFC 6648 told developers to drop the “X-” prefix since temporary headers kept turning into permanent standards – think X-Forwarded-For. Most teams kept using “X-” anyway because it’s an easy visual signal for “this one’s custom,” even though it’s not technically required anymore.
How OneXtel helps with custom headers
OneXtel’s REST API, Aura, runs on the same pattern. When you call Aura to send an SMS, trigger a WhatsApp message, or check a delivery report, you authenticate with an API key that’s typically passed as a header alongside your request – the same custom-header approach almost every REST API uses, rather than baking credentials into the URL. That keeps your key out of logs and browser history, and makes it easy to rotate if you ever need to. Custom headers are also handy for your own tracking – if you’re firing off bulk transactional SMS or WhatsApp messages across your DLT-approved templates, tagging outbound calls with your own request-ID header makes it much easier to match what you sent against the per-message delivery reports Aura returns, especially when you’re troubleshooting a batch that partially failed. None of this replaces DLT registration or your Sender ID setup – it just sits at the transport layer, carrying the metadata your integration needs.
Why it matters
Custom headers look like a small detail, but they’re often the difference between an integration that’s easy to debug and one that isn’t. Without something like a request ID, tracing a single failed message through retries, fallbacks, and delivery reports means grepping timestamps and guessing. With one, you search a single value and see the whole story. On the security side, keeping your API key in a header instead of a query string means it’s less likely to end up cached, logged by a proxy, or pasted into a chat channel by accident. For anyone building on a CPaaS API – juggling SMS, WhatsApp, voice, and RCS in one integration – a few well-chosen custom headers are what keep a growing set of API calls organized instead of turning into a debugging headache six months in.