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.
NOTEThis 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 record for certificate operations (Virtual Hosts > Certificates) is documented on this page.
Learn how to:
api.yourcompany.com), to create the DNS record.Environment | Tenant's default hostname |
|---|---|
| Production | <tenant-alias>-ai-gateway.sensedia.com |
| Testing / Staging | <tenant-alias>-ai-gateway-tst.sensedia-eng.com |
This hostname resolves to your tenant's Network Load Balancer (NLB) in the AI Gateway.
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).
NOTEDNS propagation can take a few minutes. Before configuring the inbound host, confirm the CNAME already resolves — for example, with
dig +short api.yourcompany.com.
In the sidebar, go to Virtual Hosts > Inbound Address. The form is always shown: blank when no custom host is configured, and pre-filled with the current configuration when one exists.
Fill in the form fields (see Form fields). In the Security block, the Certificate field is only shown when the selected Protocol is HTTPS or HTTP and HTTPS.
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.
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.
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 2. 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 HOSTEnabling mTLS requires a valid client certificate on every HTTPS host on this gateway, not only on this custom host. This includes the
*.sensedia.comHTTPS 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.
Go to Virtual Hosts > Trust Stores and click Create Trust Store. Enter a Name to identify the Trust CA and paste (or upload) the CA certificate in PEM format in the Trust CA (PEM) field — the field accepts a single certificate or a chain of up to 10 concatenated certificates. Save to complete the registration. Repeat for each Trust CA that should be accepted — mTLS accepts 1 to 8 Trust CAs per host.
To disable mTLS, turn off the Enable mTLS switch 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.
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. The inbound host (in Virtual Hosts > Inbound Address) isn't audited yet. Viewing, listing, or opening the detail of a certificate or of a Trust CA doesn't generate a record either: 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, or a missing author header — 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.
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.
The table below covers all fields visible in the form, grouped in the Address and Security blocks.
Block | Field | Type | Required | Rules |
|---|---|---|---|---|
| Address | Host | Text | Yes | The domain pointed in the DNS step (placeholder shown in the field: api.customer.com). Do not include a scheme (http:///https://) or a path (/) — hostname only. |
| Address | Protocol | Selectable cards | Yes | HTTP (port 80, no TLS certificate), HTTPS (port 443, requires a TLS certificate), and HTTP and HTTPS (exposes both ports; HTTPS requires a certificate). |
| Security | Certificate | Select | Required when Protocol is HTTPS or HTTP and HTTPS | Lists the edge certificates already registered under Virtual Hosts > Certificates; the Add certificate shortcut opens the registration form. The field is not shown when Protocol is HTTP. |
| Security | Enable mTLS | Switch | No | Requires a valid client certificate, signed by one of the selected Trust CAs, on every HTTPS host on the gateway — see the warning in Register the Trust CA and enable mTLS. Can only be turned on when Protocol is HTTPS or HTTP and HTTPS. |
| Security | Trust stores | Multiselect | Required when Enable mTLS is on | Lists the Trust CAs already registered under Virtual Hosts > Trust Stores; the Manage trust stores shortcut opens the registration form. Accepts 1 to 8 Trust CAs; the client certificate is accepted if signed by any of the selected ones. Disabled and empty while Enable mTLS is off. |
Situation | Behavior |
|---|---|
Host with a scheme (http:///https://), with a /, or an invalid format | The configuration is rejected; the previously configured inbound host is not changed. |
| HTTPS or HTTP and HTTPS protocol without a selected certificate | The configuration is rejected; the previously configured inbound host is not changed. |
| Enable mTLS turned on without any Trust CA selected in Trust stores | The configuration is rejected; the previously configured inbound host is not changed. |
| Trust stores has one or more Trust CAs selected while Enable mTLS is off | The configuration is rejected; the previously configured inbound host is not changed. |
| More than 8 Trust CAs selected in Trust stores | The configuration is rejected; the previously configured inbound host is not changed. |
| A selected Trust CA no longer exists at save time (for example, removed by another user) | The configuration is rejected; the previously configured inbound host is not changed. |
| Enable mTLS with Protocol set to HTTP | The switch is disabled in the interface; this state cannot be reached through the form. |
We use cookies to enhance your experience on our site. By continuing to browse, you agree to our use of cookies.Learn more