Endpoints

System integration solutions communicate by sending messages over a physical transport, such as an HTTPS API, a file share, or a queue. Nodinite documents each of these transport channels as an Endpoint, so you always know where a message went and how it travelled.

• ✅ Pinpoint the exact URL, file path, or queue behind every logged message
• ✅ Build the catalog automatically from logging, with no manual data entry
• ✅ See traffic per Endpoint with built-in, perpetual statistics
• ✅ Find every affected Integration when infrastructure changes
• ✅ Track Dev, Test, and Prod variations of the same Service

Start now: See the Add or manage Endpoint user guide.

What is an Endpoint?

An Endpoint identifies the physical location and protocol where messages are sent or received. Endpoints are the "where physically" of your integration architecture:

• Integrations document "what" (business scenarios like "Order-to-Cash")
• Systems identify "who" (participants like SAP, BizTalk, Dynamics 365)
• Services define "how logically" (the connection, with direction and contracts)
• Message Types specify "which format" (XML invoices, JSON orders)
• Endpoints pinpoint "where physically" and "how technically" (HTTPS URLs, file paths, queue names, and their protocols)

How an Endpoint fits in. Purple: the logging side, where a Log Agent or a Log API call sends a Log Event that the Logging Service processes. Blue: the System and Service you document. Orange: the Endpoint (where and how). Green: the Message Type (which format). Together, an Endpoint and a Message Type form a Transport Contract, the log point that ties a logged message to its Service.

Every Nodinite Log Event carries information about its Endpoint. An Endpoint has a user-friendly name and an address, and it is unique by the combination of these five fields:

• Name – A user-friendly name for the Endpoint.
• URI – The actual address used on the wire.
• Direction – Receive, Send, Two-way Receive (your solution answers a request), or Two-way Send (your solution calls). Avoid Unknown and None.
• Endpoint Type – How the message travels on the wire: the protocol or adapter, such as File, HTTP, SFTP, or Service Bus.
• Log Agent – The logging source that reported the Endpoint.

An Endpoint can also hold a description, a link to a web site with further documentation, a Character encoding for its messages, and, for BizTalk Server, a few advanced settings (see Where Endpoints Come From).

An example Endpoint created from the default Log Event sample in the Log API: a File Endpoint receiving from C:\temp\in, with Character encoding inherited from the Message Type.

Examples of Endpoints

• https://api.company.com/orders/v2 – REST API (HTTPS)
• C:\Integrations\Outbound\Orders\*.xml – File system path (FILE)
• msmq://localhost/private$/invoices – MSMQ queue
• sftp://vendor.com:22/inbound/ – SFTP server location
• sb://company.servicebus.windows.net/orders – Azure Service Bus queue
• soap+https://sap.internal:8000/OrderService – SOAP web service over HTTPS

One message exchange often involves two Endpoints. When Service A in one System writes a file to a share and Service B in another System picks it up over SFTP, each side logs its own Endpoint: a Send File Endpoint for Service A and a Receive SFTP Endpoint for Service B.

The Endpoints list, here filtered by the Nodinite BizTalk Server Log Agent, showing Name, URI, Direction, Endpoint Type, and the time of the last logged event.

Tip

The last column shows when Nodinite last logged an event on each Endpoint. An Endpoint that has gone quiet is often the first sign of a broken or retired integration.

How Endpoints Fit into the Integration CMDB

Endpoints are level 6, the most granular layer in Nodinite's integration CMDB: the physical implementation details that make integrations real. See The Integration CMDB Hierarchy for the full chain from Integration down to Endpoint.

Endpoints in Transport Contracts: Half of the Log Point

Endpoints are half of every Transport Contract in a Service. A Transport Contract defines a log point, a specific, observable event in your integration landscape, and needs two pieces:

• Message Type – "Which format?" (XML invoice, JSON order, EDIFACT shipment)
• Endpoint – "Where physically?" (HTTPS URL, file path, queue name)

For example:

• Message Type http://SAP.Invoice/1.0 + Endpoint https://sap.internal:8000/invoices = "SAP XML invoices sent through this HTTPS Endpoint"
• Message Type Orders/1.0#Order + Endpoint C:\Integrations\Orders\*.xml = "Order XML files in this file system location"

The Logging Service matches the Message Type and Endpoint of each logged event against the Transport Contracts to find the Service, System, and Integration the message belongs to. Without accurate Endpoints, this correlation fails. One Service can hold several Transport Contracts, and one Endpoint can serve several Services, such as a shared mailbox that carries different flows. The Services page shows these patterns.

CMDB Capabilities Enabled by Endpoints

• ✅ Compliance Tracking: Document which URLs, file paths, and queues handle regulated data
• ✅ Change Management: When infrastructure changes (new IPs, moved file shares, renamed queues), find every affected Service and Integration
• ✅ Multi-Environment Management: Track Dev, Test, and Prod variations of the same logical Service through their different Endpoints
• ✅ Protocol Governance: Verify that approved protocols are used (HTTPS over HTTP, SFTP over FTP)
• ✅ Troubleshooting: Pinpoint the exact URL or path that has connectivity or permission issues

Where Endpoints Come From

You rarely enter Endpoints by hand. They populate themselves from logging as your integrations run, so the catalog reflects what actually runs in production. This is living documentation.

1. An integration runs and sends or receives a message through an HTTPS URL, a file path, a queue, or similar.
2. Logging occurs: a Log Agent or your own code sends a Log Event that names the Endpoint.
3. The Logging Service processes the event and reads the Endpoint's Name, URI, Direction, Endpoint Type, and Log Agent.
4. The Endpoint is matched or created: if no Endpoint with the same five fields exists, Nodinite creates one.
5. The Endpoint is available in the Endpoints list and for Transport Contracts.

Logging sources include:

• Log Agents – Nodinite logging agents for platforms such as BizTalk Server, IBM Integration Bus, and Azure Logic Apps
• Log API – direct calls from your own applications and services, where your code sets the Endpoint in the Log Event
• Asynchronous Logging – high-volume, queue-based logging for performance-critical scenarios

Info

Every Nodinite Log Event must include its Endpoint and its Message Type.

BizTalk Server

For BizTalk Server, the Logging Service builds Endpoints from the BizTalk tracking data. Two BizTalk-specific settings on the Endpoint's Advanced tab help when the default behaviour isn't enough: a default Message Type on send ports that replaces the generic Unparsed Interchange and Serialized Interchange types from pass-thru pipelines, and re-mapping of dynamic send ports whose type or address changes at runtime. Add or manage Endpoint describes both, and Message Types explains how Nodinite resolves the Message Type for BizTalk messages.

Automated Deployments

You can also create and update Endpoints from DevOps pipelines through the Nodinite Web API, for example to document an Endpoint before the first message arrives.

Endpoints in Daily Operations

Endpoints are more than documentation. Nodinite uses them throughout its operational features.

In Logging

Filter Log Views by Endpoint to troubleshoot one transport channel:

• "Show me all messages sent to https://api.vendor.com/orders"
• "Which Endpoints had failures in the last hour?"
• "Compare this month's message volumes on Endpoint A and Endpoint B"

In Message Processing: Character Encoding

The same Message Type can arrive on different Endpoints in different encodings: an order format may be UTF-8 on a REST API but Windows-1252 from a legacy FTP drop. Each Endpoint therefore has a Character encoding that is Inherit from the Message Type by default and can override it for every message on this Endpoint. ^{New 7.11} The resolved encoding drives processing, re-indexing of Search Fields, the message body view, and Stylesheets. Character Encoding explains the priority order, and Add or manage Endpoint shows where to set it.

In the Integration Landscape and BPM

Endpoints don't appear as boxes in the Integration Landscape; Services and Systems do. Their impact shows anyway:

• Clicking a Service reveals its Transport Contracts, including their Endpoints
• In a BPM, the Services behind each process step carry their Transport Contracts, so you can drill from a step to the Service and its Endpoints

In Alerting

Email and webhook Alarm Plugins can include Endpoint context when errors occur:

• "Message failed at Endpoint sftp://vendor.com:22/inbound/: connection timeout"
• Custom Metadata on the Endpoint (owner, criticality, escalation contact) can travel with the alert, so a ticketing tool behind a webhook can assign the incident to the Endpoint's contact. Who receives the alert from Nodinite is set on the Monitor View's Alarm Plugins.

Statistics

Nodinite keeps perpetual traffic statistics for every Endpoint. They are collected automatically as messages are logged, with no setup, and answer the question "what actually travels through this channel?"

The Statistics of the INT001: Receive Orders Endpoint: a chart of the number of events per Message Type over time, and a table with each Message Type's retention, first and last event, and total number of events.

What the Statistics Show

• Recorded Message Types – every Message Type logged on the Endpoint, including deleted ones when you choose to
• Number of events per Message Type over time – a chart for the date range you pick, showing volume and when traffic happened
• First and last event – when each Message Type was first and most recently seen on the Endpoint
• Retention per Message Type – the Days to keep for events, context, and bodies, so you can see how long the logged data stays available

Why They Matter

• ✅ Is this Endpoint used as designed? An unexpected Message Type, or a generic one such as Unparsed Interchange, points to a misconfiguration
• ✅ Capacity Planning: Spot high-traffic Endpoints and unexpected spikes before they become outages
• ✅ Consolidation and retirement: Find Endpoints with little or no recent traffic
• ✅ Change Impact: Before you move or change an Endpoint, see which formats and volumes depend on it
• ✅ Compliance Reporting: Show auditors real traffic volumes, not estimates

For the other direction, which Endpoints carry a given format, see the Message Type statistics. Add or manage Endpoint shows where to open the Statistics tab.

Who Uses Endpoints?

Custom Metadata

As with all entities in the Nodinite Repository Model, an Endpoint can have any number of Custom Metadata fields, such as owner or criticality.

Custom Fields

An Endpoint can also have any number of Custom Fields assigned.

Next Steps

Add or manage Endpoint – edit an Endpoint, its encoding, and its BizTalk settings
Endpoints Overview – find, filter, and view Endpoints
Manage Endpoints – delete, restore, and permanently delete Endpoints
Services – put Endpoints to work in Transport Contracts
Message Types – the other half of every Transport Contract

Related Topics

Understanding Repository Model Entities

Repository Model – the complete integration CMDB
Integrations – business scenarios that use Endpoints
Systems – participants owning the Services
BPM – business processes built on Services and their Endpoints
Integration Landscape – the visual map of Systems and Services

Endpoint Properties

Endpoint Direction – Receive, Send, and the two-way patterns
EndpointTypes – protocols and adapters such as HTTP, FILE, MSMQ, and SFTP
Character Encoding – override the Message Type encoding per Endpoint
Custom Metadata – add business context to Endpoints
Custom Fields – legacy metadata approach

Logging and Operational Features

Log API – send Log Events with Endpoint information
Logging Service – processes events and creates Endpoints
Log Agents – logging sources that report Endpoints
Log Views – filter Log Events by Endpoint
Asynchronous Logging – high-volume logging
Alarm Plugins – alerts that can carry Endpoint context