Skip to content
Endpoint Connections & Partners
.md

Endpoint Connections & Partners

When you activate an audience, you deliver it to a destination. Destinations are modeled as partners and endpoint connections.

Partner

A partner is the platform or service that receives the activated data - a DSP, a data marketplace, an ad platform, and so on. The set of partners available to you is determined by your company. You never invent a partner; you reference an existing one through a connection.

GET /api/v2/analyses/reference/common/endpoint-partners    # company-scoped list

Endpoint connection

An endpoint connection is your company’s configured link to a partner - the saved destination you activate into. It binds a partner to your company and holds the connection’s stored configuration (including, server-side, any stored credentials).

GET /api/v2/analyses/reference/common/endpoint-connections  # company-scoped, secret-free

The reference read returns only { id, name, partner: { id, name } } plus the partner’s input definitions. Credentials and other connection secrets are never returned by any read.

Connections are set up in the console, under Audience Manager - the API reads them and activates into them, but does not create them. If the destination you need is not in the list, your Account Manager sets it up.

How they fit into an activation

At activation time you supply the endpoint_connection_id. The platform resolves the partner, the available pricing models, and the datastreams server-side from that connection. You cannot supply the partner identity yourself - the activation request prohibits partner_id, partner_name, and pricing_model so a caller can never inject a different identity. You pick the pricing_model_id from the connection’s partner’s public pricing models.

GET /api/v2/analyses/reference/common/pricing-models    # the priced delivery options
GET /api/v2/analyses/reference/common/datastreams        # the output streams a partner exposes

Caller-supplied credentials

By default, an activation authenticates to the partner using the stored credentials on the endpoint connection. The Intuizi API also lets you supply credentials per call in the activation request body, for cases where the credentials are not stored on the connection or you want to use a different set for one delivery.

This is a sensitive model. The rules:

  • Precedence. Caller-supplied credentials, when present, override the connection’s stored credentials. When absent, the stored credentials are used.
  • Required somewhere. If neither caller credentials nor stored credentials exist, the activation is rejected with 422 - there is nothing to authenticate the delivery.
  • Never returned. Credentials are write-only. They are never echoed in any create, read, or list response, and never appear in logs.
  • HTTPS only. Send credentials only over HTTPS. Treat the request body as secret material.
  • Server-resolved identity. You supply credentials, but never the partner or pricing identity - those come from the connection.
Caller-supplied credentials are secret material. Send them only over HTTPS, never log them on your side, and never put them in a URL or query string. They are accepted in the request body, used to authenticate the delivery, and never returned by the API.

See Activate an Audience for the full request and the credentials field, Deliver to a Partner Endpoint for the step-by-step per-partner walkthrough, and Errors for the 422 cases.