Share via

How to create custom Inbound Endpoint in Azure IoT Operations

Abby Greentree 271 Reputation points
2026-03-27T18:57:28.3+00:00

I am writing a custom connector for Azure IoT Operations, following this tutorial.

I'd like to add a custom inbound endpoint, that does not required the address field.

I have an inbound endpoint defined in my connector metadata json file as

  ...
  "inboundEndpoints": [
    {
      "endpointType": "Monnit.Gateway",
      "version": "1.1",
      "fields": {
        "address": {
          "input": "optional"
        }
      },
  ...

Despite specifying the address as optional, when configuring the inbound endpoint in the IoT Operations Experience the 'Server URL' which I believe is the address prop, is always marked required.
User's image

Azure IoT Operations
Azure IoT Operations

Azure IoT Operations is a set of modular services enabled by Azure Arc.


Answer accepted by question author

  1. Anshika Varshney 10,145 Reputation points Microsoft External Staff Moderator
    2026-03-30T23:46:10.0533333+00:00

    Hi Abby Greentree,

    In Azure IoT Operations, a custom inbound endpoint always requires an address or server URL, even if your connector metadata marks it as optional. This is because the IoT Operations platform itself expects every inbound endpoint to have a target address so it knows where to connect.

    The connector metadata file mainly controls how the connector is described and displayed, but it does not override the core platform rules. The IoT Operations experience and command line tools will always treat the Server URL field as required when creating an inbound endpoint.

    Because of this, it is not currently possible to create a custom inbound endpoint that truly has no address. If your connector does not logically need a real address, the recommended approach is to provide a placeholder value for the Server URL and then handle that condition in your connector implementation.

    A few practical things to keep in mind while setting this up.

    The inbound endpoint contract in Azure IoT Operations always expects an address. Marking the field as optional in connector metadata does not change this behavior. The UI and tooling will continue to enforce the Server URL field as required. Using a dummy or placeholder address is the supported workaround today.

    In short, custom inbound endpoints without an address are not supported today by the platform. Providing a placeholder value and handling it in code is the expected way to move forward with this scenario.

    I Hope this helps. Do let me know if you have any further queries.

    Thankyou!

    1 person found this answer helpful.
    0 comments No comments

1 additional answer

Sort by: Most helpful
  1. Q&A Assist
    2026-03-27T18:57:44.93+00:00
    AI generated content. This question contains an answer created with AI from Q&A Assist. Learn more

    The address (Server URL) field is required by the Azure IoT Operations inbound endpoint UX and CLI, even when a custom connector’s connector-metadata.json marks the address field as optional. The metadata controls how the connector and its datasets/assets are modeled and rendered, but the platform’s device inbound endpoint contract still expects an endpoint address for connecting to the target system.

    In other words, the "input": "optional" setting in the connector metadata does not override the core requirement that an inbound endpoint must have an address. The operations experience UI therefore always enforces Server URL as required for device inbound endpoints created from connector templates.

    To use a connector that does not logically need a real address, configure a placeholder value that satisfies the required field and handle that case in the connector implementation. The platform currently does not support creating a device inbound endpoint without an address.


    References:

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.