Authentication

Event Bridge Setup supports six endpoint types and seven authorization methods, but not every combination is valid — the four Azure-native endpoints (Service Bus, Event Hub, Queue Storage, Event Grid) each accept only the authorization methods that make sense for that Azure resource, and Business Central enforces this: picking an unsupported combination on Setup raises an error immediately, before you can save.

Supported combinations

Endpoint	No Auth	Basic Auth	API Key	OAuth 2.0	Azure SAS Token	Storage SAS Token	Event Grid SAS Token
RabbitMQ	⚠️	✅	❌	✅	❌	❌	❌
API endpoint	⚠️	✅	✅	✅	❌	❌	❌
Azure Service Bus	❌	❌	❌	✅	✅	❌	❌
Azure Event Hub	❌	❌	❌	✅	✅	❌	❌
Azure Queue Storage	❌	❌	❌	✅	❌	✅	❌
Azure Event Grid	❌	❌	✅	✅	❌	❌	✅

✅ supported · ⚠️ supported, but not recommended outside local testing — see No Auth · ❌ not supported

Endpoints

Each endpoint's own connection fields (URL, namespace, queue name, and so on) are documented under Setup → Endpoint. This page covers which authorization method each one accepts, and why.

RabbitMQ

Publishes to a RabbitMQ exchange over its HTTP Management API. Accepts No Auth or Basic Auth — a typical Management API user — or OAuth 2.0 if it sits behind a reverse proxy or gateway that issues bearer tokens instead. API Key and Azure SAS Token aren't offered: the RabbitMQ Management API itself has no concept of either, so there's nothing on the receiving end that would ever accept them.

API endpoint

POSTs plain JSON to any URL you specify. Accepts No Auth, Basic Auth, API Key, or OAuth 2.0 — the four general-purpose HTTP authorization schemes — so pick whichever your receiving system expects. The remaining three methods (Azure SAS Token, Storage SAS Token, Event Grid SAS Token) are Azure-specific signing schemes reserved for their own endpoints; see those methods below for why. For a concrete walkthrough, see Zapier, Make.com & Power Automate.

Azure Service Bus

Publishes to a Service Bus queue or topic via its REST API. Azure only accepts OAuth 2.0 (an Entra ID app registration) or an Azure SAS Token (a shared access policy key) for this API — there's no Basic Auth or API key concept on Service Bus itself, so Event Bridge blocks the other authorization methods for this endpoint rather than letting you configure a combination Azure would reject anyway.

Azure Event Hub

Publishes to an Event Hub via the same messaging REST API Service Bus uses — Event Hubs is built on that same protocol, which is why it accepts exactly the same two authorization methods for the same reasons: OAuth 2.0 (an Entra ID app registration) or an Azure SAS Token (a shared access policy key, from the Event Hub namespace rather than a Service Bus one). No Basic Auth or API key concept here either.

Azure Queue Storage

Publishes to a Storage Account queue via its REST API. Azure Storage's data-plane API accepts OAuth 2.0 (an Entra ID app registration with the Storage Queue Data Message Sender role) or a Storage SAS Token (generated for that specific queue) — again, no Basic Auth or generic API key. Azure SAS Token doesn't apply here either: Storage Queues use a differently-shaped SAS token, which is why it's a separate authorization method from the Service Bus/Event Hub one.

Azure Event Grid

Publishes to an Event Grid custom topic via its REST API, wrapping each event in Event Grid's own event schema (id, subject, eventType, eventTime, and a data object holding the payload and headers). Event Grid custom topics accept API Key (Event Grid calls this a "topic key", sent under the aeg-sas-key header — set the Key field to that exact name), OAuth 2.0 (an Entra ID app registration), or Event Grid SAS Token (a time-limited token Business Central generates from a topic access key). No Auth, Basic Auth, Azure SAS Token, and Storage SAS Token don't apply to Event Grid's API.

WARNING

This means your Event Grid Topic must be configured for Event Grid Schema as its input schema. If the topic is set to accept CloudEvents v1.0 instead, publishing will be rejected — the JSON shape Event Bridge sends doesn't match what a CloudEvents-schema topic expects. Check (or set) this on the topic's Event Schema setting in the Azure Portal before pointing Event Bridge at it.

Authorization methods

No Auth

No fields to configure. Requests are sent without an Authorization header — anyone who can reach the endpoint can post events to it, and anyone who can intercept the request can read them, so ⚠️ only use this against an endpoint you trust and control, such as a RabbitMQ instance on a private network, or for local testing. Prefer Basic Auth or OAuth 2.0 otherwise.

Basic Auth

Field	Notes
Username	Sent as the basic-auth username.
Password	Masked once saved — stored encrypted, and there's no way to view it again after entry, only replace it.

API Key

Field	Notes
Key	The HTTP header name the key is sent under.
Value	Masked once saved, same as the Basic Auth password — stored encrypted, replace rather than view.

OAuth 2.0

Business Central acquires an access token via the client-credentials flow and sends it as a Bearer token in the Authorization header. Set this up as an app registration in the target system (Entra ID, for the Azure endpoints).

Field	Notes
Token Endpoint	The OAuth2 token URL, e.g. https://login.microsoftonline.com/<tenant>/oauth2/v2.0/token.
Client ID	The application (client) ID of the app registration used to request a token.
Scope	One or more space-separated scopes to request — see the table below for the value each Azure endpoint expects.
Client Secret	Masked once saved, same as the Basic Auth password — stored encrypted, replace rather than view.

The access token is cached in memory (per session) until shortly before it expires, rather than requested fresh for every event. If a request still comes back 401 Unauthorized — the cached token was revoked or the target system's clock disagrees, for instance — Business Central discards the cached token and retries once with a freshly acquired one before giving up.

Setting up the Entra ID app registration (for the four Azure endpoints — RabbitMQ and the API endpoint can use any OAuth2 provider, so this part doesn't apply to them):

1. In the Azure Portal, go to Microsoft Entra ID → App registrations → New registration. Give it a name (e.g. "BC Event Bridge") and leave the redirect URI blank — this is a client-credentials app, not an interactive sign-in.
2. On the new registration's Overview page, copy the Application (client) ID into Client ID, and the Directory (tenant) ID to build the Token Endpoint: https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/token.
3. Go to Certificates & secrets → New client secret, and copy the secret's Value immediately into Client Secret — it's only ever shown once (the Secret ID next to it is not what you need).
4. Grant the app registration access to the target Azure resource. This happens on the resource's own Access control (IAM) blade in the portal, as a role assignment with the app registration as the member — not on the app registration's own API permissions tab, which is for Microsoft Graph/delegated permissions and doesn't apply here. Which built-in role to assign, and the Scope to set in Business Central, depends on the endpoint:

Endpoint	Role to assign, and where	Scope
Azure Service Bus	Azure Service Bus Data Sender, on the namespace (or narrower, on the specific queue/topic)	https://<namespace>.servicebus.windows.net/.default
Azure Event Hub	Azure Event Hubs Data Sender, on the namespace (or narrower, on the specific Event Hub)	https://<namespace>.servicebus.windows.net/.default
Azure Queue Storage	Storage Queue Data Message Sender, on the storage account (or narrower, on the specific queue)	https://storage.azure.com/.default
Azure Event Grid	EventGrid Data Sender, on the custom topic	https://eventgrid.azure.net/.default

The role is what actually authorizes the request; the scope just tells Entra ID which resource to issue the token for.

Azure SAS Token

Signs each request with a shared access policy from Azure Service Bus or Azure Event Hub — the two share the same messaging REST API, so this method works identically against either: Business Central computes an HMAC-SHA256 signature over the request URL and a 5-minute expiry, and sends it as a SharedAccessSignature Authorization header. This is the same scheme those services' own connection strings use.

Field	Notes
SAS Key Name	The name of the shared access policy, e.g. RootManageSharedAccessKey.
Key Value	Masked once saved, same as the Basic Auth password — stored encrypted, replace rather than view. The primary or secondary key of the shared access policy.

Storage SAS Token

Appends a pre-generated Shared Access Signature token to the request URL as a query string, rather than signing anything itself. Generate the token yourself — scoped to the specific queue and the Add message permission — via the Azure Portal, Storage Explorer, or the Azure CLI, then paste it in whole.

Field	Notes
SAS Token	Paste the full token, with or without the leading ?. It's appended to the request URL as-is and must be renewed before it expires — unlike OAuth 2.0, Event Bridge can't refresh this for you.

Event Grid SAS Token

Unlike Storage SAS Token, you don't generate this token yourself — Business Central builds a fresh, signed token for every request from a long-lived access key, and sends it under the aeg-sas-token header (Event Grid's own scheme, distinct from the generic Authorization header the other methods use).

Field	Notes
Access Key	The topic's primary or secondary access key, from Access keys on the Event Grid topic in the Azure Portal. Masked once saved, same as the Basic Auth password — stored encrypted, replace rather than view.

Each generated token is valid for 60 minutes; Business Central regenerates one for every event, so there's nothing to renew manually.

Who can configure this

Changing Authorization needs the same Event Bridge Admin permission set as the rest of Setup — see Licensing and access.