An Azure communication platform for deploying applications across devices and platforms.
You haven't missed anything. There's no field for the Infobip API key because Azure doesn't store it. It goes in each send request instead. From the Messaging Connect docs:
"Microsoft doesn't retain any credentials used to access external Messaging Connect partners. Partner API keys are used only to process each message request and are immediately discarded after the request is complete."
That's why there's no setting for it in the portal.
The phone number is the real issue, and I think it comes down to how you bought it.. The flow is meant to start on the Azure side rather than at Infobip. You open your ACS resource, go to the Messaging Connect blade, pick Infobip, accept the terms, and Azure hands you off to Infobip to buy the number. Infobip provisions it, syncs it back, and it appears in your resource automatically.
Going straight to Infobip skips the part that ties your Infobip account to your ACS resource, which is almost certainly why nothing is showing. Before you buy a second number, walk through the blade and then ask Infobip support whether they can attach the one you already have. Their integration guide covers their side of it.
Two things worth knowing before you get much further.
It's still public preview, and the docs recommend against building production workloads on preview features. Worth factoring in for something you're planning to run as a service.
You'll also need the preview SDKs, and Python and Java aren't supported yet. .NET and JavaScript both have preview packages with MessagingConnect in them.
You also need the send-with-options overload rather than the plain send. The docs give this example:
smsClient.Send(
from: "<YOUR-ACS-NUMBER>",
to: ["<RECIPIENT-NUMBER>"],
message: "Hello",
options: new SmsSendOptions(true)
{
MessagingConnect = new MessagingConnectOptions("<YOUR-INFOBIP-API-KEY>", "infobip")
});
Two smaller things. Provisioning isn't instant, and the timing is Infobip's rather than Microsoft's, so a delay doesn't necessarily mean something has gone wrong. When the number does appear it'll carry an Operator Name label, which is how you tell Messaging Connect numbers apart from ones provisioned directly by Azure.
And since you mentioned forwarding, make sure you're getting a Long Code (VLN). Alphanumeric sender IDs can only send, they can't receive.
Help make this community better for everyone: if this answer resolved your issue, please accept it or leave an upvote. If not, share more details in a comment so we can continue the discussion and find the right solution.