# Connections

> What a connection carries, why an API key cannot create one, and the two settings that decide whether it gets scored.

A connection is one platform, wired to one client and one agent. It is what turns a delivery from that platform into a conversation with a score.

## No API key creates one

A connection is made by a signed-in admin, not by a key. There is no admin scope, so a key sent to a connection route gets `403` and the words `dashboard session required`. [What each key scope reaches](/docs/api/authentication)

Make it on the connect form instead: **Integrations**, then **Connect a platform**. One press creates the client, the agent and the connection together. [The six steps a new workspace needs](/docs/finish-setup)

## What a connection carries

| | |
|---|---|
| Platform | Which of the platforms we read. It fixes the credential fields the form then asks for |
| Client | Whose customers these conversations are. **Every client** is the other choice, and it is the trap below |
| Agent | Which agent the conversations are scored as, stored as `agent_id`. It must belong to the client above |
| Credentials | The platform's own keys and signing secret. We store the field names and never hand a value back |
| On or off | One connection per platform per client may be on. A second is refused rather than left to guess |

## The agent has to be under the client

Naming another client's agent is refused. Nothing else would catch it: one client's conversations would be scored against another client's rules, and every number after that reads as real.

Moving a connection to another client re-checks it, so a move that leaves the old client's agent behind is refused rather than kept.

## A connection for every client scores nothing

> **Note:** A connection whose client is **Every client** puts no client on its conversations, so no agent is resolved and no rules apply. Every conversation under it lands unscored. Give each client a connection of its own.

## Is it delivering

The connection's own page, under **Integrations**, answers that from its own deliveries. It counts what arrived, how much we read into conversations, and what we refused at the door.

| | |
|---|---|
| Delivering | Deliveries arrived and we read them into conversations |
| Arriving, not readable | Deliveries arrived and none could be read, so none of it reached a score |
| Every delivery refused | An unusable secret, or a switched-off connection, turned every one away at the door |
| Nothing yet | The address is live and nothing has ever been posted to it |
| Quiet | It delivered cleanly and then stopped, which no other state says |
| Switched off | A delivery is refused rather than queued |

Two warnings sit beside the counts: a webhook with no signing secret, where the address itself is the only credential, and a stored API base we now refuse to dial.

---

Source: https://evidova.com/docs/api/connections