> 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

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

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.
