# Endpoint Connections & Partners


When you [activate an audience](/guides/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.

{{< callout type="error" >}}
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.
{{< /callout >}}

See [Activate an Audience](/guides/activate-an-audience) for the full request and
the credentials field,
[Deliver to a Partner Endpoint](/guides/deliver-to-a-partner-endpoint) for the
step-by-step per-partner walkthrough, and [Errors](/concepts/errors) for the
`422` cases.