Connector Interfaces

A connector interface is a single delivery endpoint that an installed connector app exposes. When you deliver data to a destination, you don’t connect a dataset to the connector as a whole—you connect it to one of the connector’s interfaces. The distinction matters because delivery is decided at the interface level. An interface defines which dataset schemas it will accept, how often it refreshes, and which settings you can supply. A dataset that one interface accepts, another may reject.

​

Apps, interfaces, and connections

A connector is installed as an app, identified by an app_id. Each installed app exposes one or more interfaces, each identified by an interface_id. The pair (app_id, interface_id) addresses a specific destination endpoint. A connection binds a dataset to one accepted (app_id, interface_id) pair and routes that dataset’s data to the destination. Before a connection can be created, the dataset’s schema must be compatible with the interface.

​

What an interface contains

Each interface carries three things that govern how data reaches the destination:

• Collaboration policies — the rules that decide which datasets the interface accepts. An interface carries zero, one, or several JSON-Schema policies over dataset schemas. This is where a destination’s identifier and column requirements live: the supported identifiers on each connector page are the human-readable form of these rules. A dataset that fails produces a schema-incompatible error. With no policy at all, the interface accepts any dataset — that’s how file destinations like Amazon S3 work.
• Metadata — tags that determine where the interface is offered (Audience Studio, for example, shows only interfaces tagged audience_delivery), and an optional refresh window. When set, the window’s max is the longest the destination will tolerate between refreshes, and it becomes the upper bound on the source dataset’s refresh schedule.
• Quick-settings schema — a JSON Schema describing the connector-specific settings you supply when you create the connection (for example, a destination account or list name). You fill in a quick_settings object that conforms to this schema.

​

How you use it

Through the API you don’t pick an interface by name—you ask which interfaces accept a given dataset and connect to one of them. (In the platform UI, compatible interfaces are offered to you by name once you’ve selected a connector.) A connection is created from the dataset, an enabled profile for the destination app (the profile holds the credentials), and a quick_settings object built from the interface’s quick-settings schema. The interface isn’t passed as a separate id; its type field inside quick_settings is what tells the connector which interface you chose. Checking compatibility first returns the accepted (app_id, interface_id) pairs a connection will succeed against. For the exact API calls behind this flow, see the connection creation flow in the MCP server reference. For the per-connector identifier requirements that drive compatibility, see the connector reference.

​

Why it works this way

Deciding acceptance at the interface level keeps governance close to the destination. The collaboration policy is the enforcement point: it guarantees that only data with the right shape and identifiers reaches a platform, rather than relying on the person configuring the connection to get it right. Checking compatibility before creating a connection turns a delivery-time failure into an answerable question—“which destinations can receive this dataset?”—that you can resolve up front.

​

Related content