This endpoint removes one source a customer connected. Deleting it **purges** everything behind it: the connection, every document indexed from it, and every embedded passage of those documents. The remote session is revoked where the provider supports it.

```bash
curl -X DELETE "https://context-link.ai/api/v1/api_accounts/tf-cust-8841/connections/acme-gdrive" \
  -H "Authorization: Bearer $PROVISIONING_TOKEN"
```

`204 No Content`, no body. A `404` means there is nothing there to delete. On a retried request, treat that as success.

## Request fields

| Field | Type | Description |
|---|---|---|
| `uid` | string | Required, in the path. The customer id you provisioned the account with. An unknown uid is a `404`. |
| `connection_uid` | string | Required, in the path. The uid you chose when you [connected the source](/docs/white-label/connect-source). A uid belonging to another customer is also a `404`. |

There is no request body. Anything you send in one is ignored.

## Response fields

None. A successful delete answers `204 No Content` with an empty body, so there is nothing to parse. The status code is the whole response.

> **This is irreversible.** There is no soft delete and no undo. Re-connecting the same source afterwards re-fetches it from scratch, which for a large mailbox or Drive is hours of crawling.

Content that came from other connections is untouched, as is the customer's account, their token and their memory. To remove the customer entirely, [delete the account](/docs/white-label/delete-account) instead.

A `connection.disconnected` [webhook](/docs/white-label/webhooks) fires as the row goes. A queued job or another instance of your app should react to that webhook rather than to the `204`.

## Deleting is not the same as losing authorisation

The two look similar in a support conversation. Their effects are opposites:

| | What it is | What happens to the content |
|---|---|---|
| `DELETE` | The customer asked for the source to be gone. | Destroyed. Citing a source the customer removed is worse than losing it. |
| `auth_failed` | The grant died: revoked at the provider, password changed, token expired. | Kept. The usual cause is transient, and re-authorising should not mean re-crawling from nothing. |

So a dead refresh token is never a reason to `DELETE`. Send the customer through [re-authorisation](/docs/white-label/connect-source#re-authorising-a-dead-connection) instead, and the index picks up where it left off.

There is one case where content disappears without you asking for it: a **source type being withdrawn from your organisation**. That destroys every connection of that type across your whole fleet and fires a single `connection_type.revoked` webhook. It is always a deliberate, counted action on our side, never an automatic one.