> For the complete documentation index, see [llms.txt](https://developer.mediarithmics.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.mediarithmics.io/advanced-usages/plugins/creation/destinations-and-authentication.md).

# Destinations & Authentication

## Destinations & Authentication

The **Destinations** model is the framework that allows a connector plugin to manage authenticated connections to a partner platform in a structured, reusable way. Understanding it is required before implementing any connector that supports self-service authentication.

### Key concepts

Data activation on the platform follows a four-level hierarchy:

```
Connector  →  Destination  →  Preset  →  Feed
```

From a developer's perspective, each level maps to a concrete artefact:

| Level           | What it is                                                         | Who manages it               |
| --------------- | ------------------------------------------------------------------ | ---------------------------- |
| **Connector**   | The plugin itself (a specific plugin version)                      | mediarithmics connector team |
| **Destination** | An authenticated instance of the connector for one partner account | The customer, self-service   |
| **Preset**      | A reusable configuration built on top of a destination             | The customer                 |
| **Feed**        | A concrete delivery instance tied to an audience segment           | The customer                 |

A single connector (plugin) can have many destinations (one per partner account), each with many presets, each with many feeds.

### Authentication flag

Each plugin version has an `auth_flag` boolean that controls whether authentication is managed by the plugin.

| `auth_flag` value | Effect                                                                                                                                                                                            |
| ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `true`            | The platform enforces the authentication flow. The destination status follows the state machine described below. The plugin must implement the methods corresponding to the configured auth type. |
| `false`           | Authentication is skipped. The destination status is set to **Unknown** and no credential flow is triggered. Use this for migration or connectors that do not require authentication.             |

This flag is set in the Computing Console on the plugin version configuration page.

### Authentication types

When `auth_flag` is `true`, the plugin version must declare one of the following authentication types:

| Type             | Description                                                                                                                          | Typical use case                             |
| ---------------- | ------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------- |
| `OAUTH2`         | OAuth 2.0 redirect flow. The user is redirected to the partner login page. A refresh token is stored securely in the platform vault. | LinkedIn, Google, Amazon Ads                 |
| `TOKEN`          | A single secret string input (API token or access key).                                                                              | Facebook                                     |
| `LOGIN_PASSWORD` | A pair of string inputs: one non-secret (login) and one secret (password).                                                           | Batch CEP                                    |
| `NO_AUTH`        | No authentication required. The destination creation modal skips the auth step.                                                      | Migration connectors, unsupported connectors |

The auth type controls which UI fields are displayed to the user during destination creation and which plugin methods the platform calls.

### Destination status state machine

When `auth_flag = true`, a destination follows this lifecycle:

```
User creates destination
        │
        ▼
  Status: Not Ready
        │
        ├── User authenticates ──► Plugin returns success ──► Status: Ready
        │
        └── Plugin returns error ──► Status: Connection Error
                                            │
                                            └── User re-authenticates ──► (back to choice above)
```

When the destination status is **Connection Error**, the platform prevents new presets or feeds from being created on top of that destination. The error is surfaced to the user in the interface so they can re-authenticate without contacting support.

### In this section

* [Configuring a plugin version](/advanced-usages/plugins/creation/destinations-and-authentication/configuring-a-plugin-version.md) - Set up the auth type, layout, and property levels in Computing Console.
* [Authentication methods](/advanced-usages/plugins/creation/destinations-and-authentication/authentication-methods.md) - Implement the SDK methods that handle the credential flow in your plugin code.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://developer.mediarithmics.io/advanced-usages/plugins/creation/destinations-and-authentication.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.