If you have used BizTalk adapters or Logic Apps connectors, the mental model carries over almost unchanged. An adapter is the unit that knows how to talk to a specific kind of system, HTTP, SQL, SFTP, a mail server, a queue, and it is the unit you bind to a port to make that conversation happen.

The differences are in two places only, both covered below: how iQBus names adapters (Listener on the receive side, Caller on the send side) and how it handles scheduling (a separate Scheduler adapter for most transports, with the three file Listeners owning their own interval).

Adapters are configured on either a receive port or a send port, and iQBus's architecture rule is that the adapter's name signals where it belongs, a Listener suffix on the receive side, a Caller suffix on the send side. The same underlying protocol becomes two different adapter objects because listening and calling are two different jobs:

That is why the receive-side HTTP adapter is called API Listener rather than just API, and the send-side counterpart is the API Caller. The two are different adapters; one listens, one calls.

Whether an adapter is intended for the receive side or the send side, and what kind of response it naturally produces, is decided adapter by adapter. The matrix below plots each shipping adapter into the cell that describes its natural shape. A practical wrinkle on the send side: every send port can be configured in two-way mode regardless of which adapter is bound; what varies is whether the response carries the adapter's real payload, or only an empty acknowledgement that lets the integration thread continue downstream.

BizTalk historically embedded scheduling into receive-side transport adapters, the SQL adapter on a receive location, for example, carries its own polling interval. iQBus factors scheduling out into a single, purpose-built adapter that any other adapter can be triggered by. The exception is the three file Listeners, which own their own polling interval, for the reason given below.

The Scheduler adapter is a one-way receive adapter. You configure the cadence (repeat every N seconds / minutes / hours / days) once on a receive port, optionally gate it by a date range and a daily clock-time window, and the firing message it produces is published to the bus. From there, any send port subscribed to that message picks it up and runs its adapter:

An adapter does not carry its own credentials. Whatever it needs to reach its endpoint, a connection string, an API key, a certificate, an SFTP key, lives in a separate Authentication object that the adapter references by name.

The pairing is one-to-one at the type level: every adapter type defines exactly one Authentication shape, and an adapter cannot consume an Authentication that belongs to a different adapter type. A SQL Caller adapter pairs with a SQL Authentication, an API Caller adapter pairs with an API Authentication, and so on. The fields each Authentication exposes are determined by its adapter type.