Custom Inbound

Custom Inbound lets you expose your own domain as the entry point of the AI Gateway, instead of the default domain provided by Sensedia. This page explains how to point your domain's DNS to your tenant's gateway and how to configure the inbound host under Virtual Hosts > Inbound Address.

NOTE

This page covers the host configuration (protocol and domain) and enabling mTLS on that host. Edge certificate registration is done under Virtual Hosts > Certificates, and the Trust CAs used by mTLS are registered under Virtual Hosts > Trust Stores. The Audit Log records for certificate operations (Virtual Hosts > Certificates), for Trust CA operations (Virtual Hosts > Trust Stores), and for changing the inbound host (Virtual Hosts > Inbound Address) are documented on this page, as are the Certificates permissions and the Trust Stores permissions.

Quick links

Learn how to:

• Review the prerequisites
• Point your DNS to the tenant NLB
• Configure the inbound host
• Change the protocol
• Register the Trust CA and enable mTLS
• Review the Audit Log record
• Review the form fields
• Common errors
• Review the Certificates permissions
• Review the Trust Stores permissions
• Review the Inbound Address permissions

Before you start

• A domain you control (for example, api.yourcompany.com), to create the DNS record.
• For the HTTPS or HTTP and HTTPS protocols, an edge certificate already registered in the AI Gateway (under Virtual Hosts > Certificates) — it will be referenced by the Certificate field in Step 3.
• If you plan to enable mTLS (see Register the Trust CA and enable mTLS), at least one Trust CA already registered under Virtual Hosts > Trust Stores — or register it as part of the same flow.
• Your tenant's default hostname in the AI Gateway, provided by Sensedia during onboarding:

This hostname resolves to your tenant's Network Load Balancer (NLB) in the AI Gateway.

Point your DNS to the tenant NLB

In your domain's DNS provider, create a CNAME record for the domain you want to use as inbound (for example, api.yourcompany.com) pointing to your tenant's default hostname (see the table above).

NOTE

DNS propagation can take a few minutes. Before configuring the inbound host, confirm the CNAME already resolves — for example, with dig +short api.yourcompany.com.

Configure the inbound host

The Add certificate and Add Trust Store shortcuts are inside the panel, on the Certificate and Trust stores fields. The permissions for each one are in the Shortcuts in the panel row of Inbound Address permissions.

When you save, the AI Gateway starts accepting traffic on the configured domain. Your tenant's default endpoint (table in the previous section) keeps working normally.

Change the protocol

You can reconfigure the inbound host as many times as needed — for example, switching from HTTP and HTTPS to HTTPS to disable your domain's HTTP port. Selecting HTTP automatically clears the Certificate field, which disappears from the form. Selecting HTTP also turns off mTLS, if it was enabled, and clears the Trust CAs selected in Trust stores — once saved, the client-certificate requirement no longer applies to the entire gateway. The saved configuration always replaces the previous one.

Register the Trust CA and enable mTLS

mTLS (mutual TLS) requires the client to present a valid certificate, signed by a registered Trust CA, to connect to the gateway — an additional requirement on top of the server validation already provided by the certificate configured in Step 3. mTLS can only be enabled when the host's Protocol is HTTPS or HTTP and HTTPS.

MTLS APPLIES TO THE ENTIRE GATEWAY, NOT ONLY TO THIS HOST

Enabling mTLS requires a valid client certificate on every HTTPS host on this gateway, not only on this custom host. This includes the *.sensedia.com HTTPS URL hosted by Sensedia for this tenant (table in Before you start), which will start rejecting clients that do not present a certificate trusted by one of the selected Trust CAs. There is no per-host or per-domain isolation for mTLS — only enable it once you have confirmed that every client currently accessing your tenant's default endpoint can also present a valid certificate.

To disable mTLS, click Edit on Virtual Hosts > Inbound Address, turn off the Enable mTLS switch in the Update Inbound Address panel and save. The client-certificate requirement is removed from every HTTPS host on the gateway, and validation goes back to server-only (standard TLS), as it was before enabling mTLS.

Audit Log record

Registering, editing, or deleting a certificate (in Virtual Hosts > Certificates) generates a record you can query in the Access Control Audit Log, filtering by Certificate — with the date, the author, the outcome of the operation, and the object's content. Registering, editing, or deleting a Trust CA (in Virtual Hosts > Trust Stores) also generates a record, filtering by Trust Store, with the same date, author, and outcome data; the object's content is specific to each type. Viewing, listing, or opening the detail of a certificate or of a Trust CA doesn't generate a record: only write operations are audited.

The private key never appears in the certificate's record, regardless of the outcome. On success, the record usually carries the certificate's identifier, the type, the name, the expiration date, and whether a private key was submitted on the operation — this field only indicates that a key came in on the request, not that it changed; resubmitting the same key also marks it. A write refused during processing also generates a record, with a failure outcome, carrying the reason for the refusal and the configuration that was attempted.

The CA material never appears in the Trust CA's record, regardless of the outcome. On success, the record usually carries the Trust CA's identifier, the name, and how many CA certificates that Trust CA's PEM holds — the content after the operation on registration and editing, and the content read before removal on deletion. The count refers only to that Trust CA, not to the Trust CAs selected on the host, and doesn't tell which certificates make up the chain. A write refused during processing also generates a record, with a failure outcome, carrying the reason for the refusal and the configuration that was attempted, without the material that was sent.

A request refused right at the entry point (for example, a required field that is missing or blank) generates no record at all. From the moment the operation is processed, both success and failure generate a record: deleting a certificate that is in use by an active configuration and deleting a certificate that no longer exists both show up in the trail as a failure. The same holds for Trust CAs, and it holds even when the refusal comes from the content that was sent: deleting a Trust CA that is in use by an active mTLS configuration, passing an identifier that no longer exists, saving with a name that is already registered, and sending a PEM that is malformed or above the size limit all show up in the trail as a failure — including the ones answered as an invalid request, because that check happens inside the operation.

Saving the inbound host (in Virtual Hosts > Inbound Address) also generates a record, always a change: this configuration is unique per tenant, so there is no create or delete, only replacing the address. The record is queryable by filtering by Inbound Address; combine that filter with Product = AI Gateway, because the Inbound Address value is reused from API Platform and the change-type list isn't scoped by product (without the product filter, the search also returns API Platform records). On the Audit Logs screen, the Name column shows, on success, the host saved in lowercase; on a failure, the host exactly as it was sent in the request. On success, the record's content is the configuration after saving: protocol, host, the selected certificate, the selected Trust CAs (by identifier), and whether mTLS is enabled, never the certificate or CA material. The record only shows whether mTLS is on or off for this host; remember that setting applies to the whole gateway, as described in Register the Trust CA and enable mTLS. A write refused during processing also generates a record, with a failure outcome, carrying the reason for the refusal and the configuration that was attempted, with the same fields as a success record.

A request refused right at the entry point (a missing or blank protocol or host, a missing header, a Host, certificate identifier, or Trust CA identifier longer than 253 characters, or more than 100 selected Trust CAs) generates no record. From the moment the operation is processed, both success and failure generate a record: an invalid host format, a missing certificate with HTTPS or HTTP and HTTPS, a Trust CA selection that is incoherent with mTLS, 9 to 100 selected Trust CAs, or a referenced Trust CA that no longer exists all show up in the trail as a failure. Querying the current host configuration doesn't generate a record either.

Querying the Audit Log uses the Audit List (access-control.audits.list) and Audit View (access-control.audits.view) permissions, which already govern that screen.

Form fields

The table below covers all fields visible in the form, grouped in the Address and Security blocks.

Common errors

Certificates permissions

Access to each action on the Virtual Hosts > Certificates screen depends on its own permission. Without the corresponding permission, the screen element does not appear; it is never shown merely as disabled.

Permissions are granted in Access Control, on the Roles screen, under the AI Gateway product. The table below lists each one exactly as Access Control displays it.

A control without its permission is not rendered; a Certificates screen reached directly by URL without its permission lands on the AI Gateway's own access denied screen, not on Access Control's.

EDITING REQUIRES VIEWING

The Edit button only exists inside the Certificate details screen. Because of that, a user holding Create and Update Certificates but not View Certificate has no path to edit an existing certificate. This is expected platform behavior, not a bug.

THE PRIVATE KEY NEVER APPEARS IN THE DETAILS

The Certificate details screen never displays the certificate's private key, regardless of the granted permission.

Trust Stores permissions

Access to each action on the Virtual Hosts > Trust Stores screen depends on its own permission. Without the corresponding permission, the screen element does not appear; it is never shown merely as disabled. The exception is the Delete icon of a Trust CA that is in use, described below.

Permissions are granted in Access Control, on the Roles screen, under the AI Gateway product. The table below lists each one exactly as Access Control displays it.

A control without its permission is not rendered; a Trust Stores screen reached directly by URL without its permission lands on the AI Gateway's own access denied screen, not on Access Control's.

EDITING REQUIRES VIEWING

The Edit button only exists inside the Trust store details screen. Because of that, a user holding Create and Update Trust Stores but not View Trust Store has no path to edit an existing Trust CA. This is expected platform behavior, not a bug.

Trust CA in use by mTLS

The Trust Stores listing has an Inbound Address column. It shows In use when the Trust CA is selected in the Inbound Address with mTLS enabled, and Not in use otherwise. The same information appears in the Inbound Address field of Trust store details.

A Trust CA that is in use cannot be deleted. The Delete icon stays visible on the row but is locked: the tooltip shows In use by the Inbound Address mTLS and, when clicked, the screen shows This trust store validates client certificates in the Inbound Address mTLS. Remove it from the inbound selection before deleting it. No deletion is sent. To delete it, open Virtual Hosts > Inbound Address and select another Trust CA in its place in the Trust stores field, or turn mTLS off. The field cannot be empty while mTLS is on.

Knowing that a Trust CA is in use requires View Inbound Address, in addition to the Trust Stores permissions. Without it, the column shows — (and so does the details field), with a hint that the link is unknown, and the Delete icon is not locked. If you try to delete a Trust CA that is in use under that condition, the server refuses the deletion when you confirm. The server refusal applies in every case: the lock on the screen is a convenience.

THE TRUST CA IS PUBLIC MATERIAL

The Trust store details screen shows the Trust CA (PEM) in read-only mode. The field holds certificates only, never a private key. A certificate is public material, so View Trust Store exposes no secret.

Inbound Address permissions

Access to the Virtual Hosts > Inbound Address screen depends on its own permissions. Without View or Update, the corresponding button or screen does not appear. The list permissions of other groups (certificates and Trust CAs) do not stop the screen from opening: they disable Save changes and the selects, with the reason visible, and hide the Add certificate and Add Trust Store shortcuts, as described below.

Permissions are granted in Access Control, on the Roles screen, under the AI Gateway product. The table below lists each one exactly as Access Control displays it.

This screen also uses permissions from two other groups. The certificate ones, List Certificates and Create and Update Certificates, are in Certificates permissions. The Trust Stores ones, List Trust Stores and Create and Update Trust Stores, are in Trust Stores permissions.

Without Update Inbound Address, the empty screen (no host configured) does not show the Configure inbound host button; it shows a line saying that configuring the host requires that permission.

The names of the certificate and of the Trust CAs depend on permissions from other groups:

When the select of a required field is unavailable, the Save changes button is disabled, with the reason visible. This applies to Certificate with the HTTPS or HTTP and HTTPS protocol, and to Trust stores with mTLS enabled. Without List Certificates or List Trust Stores, the matching select is still rendered, disabled and empty; what stops appearing are the shortcuts, as set out in the Shortcuts in the panel row of the actions table. A route reached directly by URL without its permission lands on the AI Gateway's own access denied screen, not on Access Control's.

EDITING REQUIRES VIEWING

The /inbound-address/edit route requires View Inbound Address before it checks Update Inbound Address. A user with Update Inbound Address but without View Inbound Address lands on the access denied screen when opening /inbound-address/edit, even by typing the URL directly — so they cannot reach the edit panel, either through Edit or through Configure inbound host. This is expected platform behavior, not a bug.