Your Account Has Its Own Address
Most APIs live at one address for everybody. Infobip gives each account its own hostname, which makes the base URL a piece of configuration rather than a constant — and turns a field most people think of as a username into a web address.
There is an assumption buried in almost every integration ever written: the provider has an address, the address is the same for everyone, and it belongs in the code. It is such a safe assumption that it usually is not written down as one. Infobip does not work that way, and the consequence shows up immediately — as a settings field asking for something that looks nothing like a credential.
A hostname per account
When you open an Infobip account you are given a base address of your own — a subdomain that is yours. Every API call your account makes goes to that address rather than to a shared one.
It is a sensible arrangement for a provider operating at scale across many regions: routing, isolation and regional placement all become properties of where your account lives rather than logic inside a shared endpoint.
For anyone integrating, it means one thing: the base URL is configuration, not a constant. It has to be stored per workspace, alongside the credentials, and it cannot be hardcoded — which is precisely the thing everybody's instinct does first.
A hostname in the code is an assumption that every customer talks to the same server. It is right until it is not, and then it is wrong for everybody.
What people actually paste in
A field asking for a base address gets pasted into from a browser, and what arrives is rarely the bare hostname.
So two things are normalised on the way in. A scheme at the front is stripped, because people copy addresses complete with the part their browser shows. A trailing slash is stripped, because the same copy often includes it and joining a path onto it would produce a doubled separator.
Neither is clever. Both are the difference between a field that accepts what a person naturally supplies and one that requires them to know what shape it wants — with a validation error that says the request was malformed rather than that the value has an extra character.
| What is pasted | What is stored | Without normalising |
|---|---|---|
| The bare hostname | The hostname | Works |
| With the scheme in front | The hostname | A doubled scheme in the URL |
| With a trailing slash | The hostname | A doubled separator in the path |
| Both | The hostname | Both problems at once |
This is a small, general habit worth naming: normalise at the boundary, once, where the value enters. The alternative is defending against the variations at every point of use, which is more code in more places and gets missed in one of them.
A scheme that is not the one you expect
The authorisation header here does not use the keyword almost every other API in this series uses. Infobip has its own, and sending the conventional one produces a rejection that reads as an invalid key rather than as a wrong scheme.
That failure mode is worth flagging because it sends people in exactly the wrong direction. The reported problem is authentication; the natural response is to regenerate the key, paste the new one, and get the same result — and to do it twice before questioning the header itself.
It is one more instance of the thread running through this whole series. Every provider has a handful of places where it differs from the convention, none of them is difficult, and all of them fail in a way that points somewhere else. Reading the provider's own documentation for the specific thing you are about to assume is the entire technique.
One call, many destinations
Infobip takes a list of destinations inside a single message object, so a notification to twelve people is one request.
That is the third distinct shape across the three SMS providers in this system, and the three are genuinely different rather than stylistic variations.
-
A comma-joined list in one call
One provider takes the numbers as a single joined value and returns a status per recipient inside the response.
-
One request per recipient
Another wants each send separately, which is why it can report a reason per number.
-
A structured destinations array in one call
Infobip takes a list of destination objects inside one message, which is a cleaner shape than joining strings and still a single request.
Each has a real consequence for what can be reported afterwards, which is why the three connectors return slightly different things — and why a shared abstraction over all three would have to report the least of them.
An error three levels down
When a request is refused, the useful sentence is nested three levels inside the response document. It is read from there, with the raw response kept as a fallback for anything that does not match that shape.
The fallback is the part worth defending. A deep path into somebody else's response format is a guess about their structure, and it is a guess that will be wrong for some error one day — a gateway failure, a rate limit page, a maintenance response that is not their normal error shape at all.
Without a fallback, the reported reason on those days is empty. An empty error message is the worst possible diagnostic: it says something failed and withholds the only thing you needed. The raw response is uglier and always says something.
What is in place, layer by layer
The Infobip connector as it stands
A per-account base address
Your own Infobip hostname is stored as configuration rather than assumed, because on this provider it genuinely differs per account.
The address normalised on entry
A pasted scheme and a trailing slash are stripped once, where the value enters, rather than defended against at every point of use.
The provider's own authorisation scheme
The header keyword Infobip specifies rather than the conventional one, which would be refused in a way that reads as an invalid key.
One request for the whole list
Recipients travel as structured destinations inside a single message, which is the shape this API is designed around.
A refusal before the call
A missing address or key produces a message naming both, rather than a network round trip and a provider error about authentication.
The nested reason extracted
The human-readable sentence is read from where Infobip puts it, several levels inside the response document.
A raw fallback behind it
Anything that does not match that shape falls back to the whole response, because an empty error message is worse than an ugly one.
Credentials encrypted at rest
Stored on the row for one workspace, never in configuration or environment, and never written into a log line.
Your own Infobip account
Your address, your key, your registered sender, your billing. The relationship with the provider is yours.
The base address is on the same settings screen as the other two SMS providers and in the same stored field, which is why that field's label changes with the provider you pick.
Three positions held on purpose
- A provider's address is treated as configuration where the provider makes it one. Hardcoding a hostname is an assumption that every customer reaches the same server, and it is the kind of assumption nobody writes down until it is wrong.
- Input is normalised once at the boundary. Accepting what a person naturally pastes is a few characters where the value enters; the alternative is defending against the variants everywhere the value is used, and missing one.
- Every extracted error path has a raw fallback. A deep path into somebody else's response format is a guess about their structure, and the day it is wrong is a day you need the message most.
Five questions about a provider with per-account endpoints
Is the API address configurable?
A good answer sounds like
Yes, per workspace.
What ours actually is
Stored alongside the credentials, because on this provider it genuinely differs per account.
What if I paste the whole URL from my browser?
A good answer sounds like
It is handled.
What ours actually is
A scheme and a trailing slash are stripped once, where the value enters.
Why is my key being rejected?
A good answer sounds like
Check the scheme, not the key.
What ours actually is
This provider uses its own authorisation keyword; the conventional one is refused in a way that reads as a bad key.
How are several recipients sent?
A good answer sounds like
One call.
What ours actually is
As structured destinations inside a single message, which is what this API is built for.
What if the error is not in the usual place?
A good answer sounds like
You still see something.
What ours actually is
The raw response is the fallback, because an empty error message is worse than an ugly one.
Our take
Building the third connector for the same job is where you find out which parts of the first two were the problem and which were just that provider. Twice is a coincidence; three times is a shape. Here it was the base address — hardcoded without a thought in the first two, because a provider having one address is so obviously true that it never presents itself as a decision. The general lesson is not that hostnames should always be configurable. It is that the assumptions worth examining are the ones you did not notice making, and the reliable way to find them is to build the same thing against a provider that disagrees.
Send through the account you already have
Your Infobip address, your key, your registered sender. Three providers, one settings screen, and each handled the way it actually works.
Talk through SMS alertsFrequently asked questions
Where do we find our Infobip base URL?
It is shown in your Infobip account alongside the API key — a subdomain that belongs to your account rather than a shared address. Paste it however it appears; a scheme at the front or a trailing slash is handled.
Our API key keeps being rejected. What should we check?
The base address first, and then whether the key was copied whole. Infobip uses its own authorisation scheme rather than the conventional one, so a request built on the wrong assumption is refused in a way that reads as an invalid key — which sends people regenerating a key that was fine.
Can we send to several countries?
Yes — recipients travel as a list of destinations in one message, and Infobip routes each. What may appear as the sender is decided by market and operator rules rather than by the connector, so a registered sender is worth having where you send regularly.
Why is the base URL stored in a field called username?
Because the three SMS providers share one stored shape, and each reads those fields with its own meanings. The labels on the settings screen follow the provider you choose, so the field asks for the right thing even though the underlying storage is shared.
What happens if Infobip returns an error we do not recognise?
The whole response is reported instead. The usual reason is read from a specific place in their error document, and anything that does not match that shape falls back to the raw response — because a failure with an empty message is the least useful thing a system can tell you.
