Disconnect a source | Context Link

llm prompts Wire up disconnect Tell deleting apart from a dead grant

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.

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

Request fields

uidstring

Required, in the path. The customer id you provisioned the account with. An unknown uid is a 404.

connection_uidstring

Required, in the path. The uid you chose when you connected the 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 instead.

A connection.disconnected webhook 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 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.

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

require "net/http"

uri = URI("https://context-link.ai/api/v1/api_accounts/tf-cust-8841/connections/acme-gdrive")

request = Net::HTTP::Delete.new(uri)
request["Authorization"] = "Bearer #{ENV.fetch("PROVISIONING_TOKEN")}"

response = Net::HTTP.start(uri.hostname, uri.port, use_ssl: uri.scheme == "https") do |http|
  http.request(request)
end

puts response.body

import os
import requests

url = "https://context-link.ai/api/v1/api_accounts/tf-cust-8841/connections/acme-gdrive"

headers = {
    "Authorization": f"Bearer {os.environ['PROVISIONING_TOKEN']}",
}

response = requests.delete(url, headers=headers, timeout=30)
print(response.text)

// Runs on your server only: the token must never reach the browser.
const url = new URL("https://context-link.ai/api/v1/api_accounts/tf-cust-8841/connections/acme-gdrive");

const response = await fetch(url, {
  method: "DELETE",
  headers: {
    "Authorization": `Bearer ${process.env.PROVISIONING_TOKEN}`,
  },
});

console.log(await response.text());

// Runs on your server only: the token must never reach the browser.
async function main() {
  const url = new URL("https://context-link.ai/api/v1/api_accounts/tf-cust-8841/connections/acme-gdrive");

  const response = await fetch(url, {
    method: "DELETE",
    headers: {
      "Authorization": `Bearer ${process.env.PROVISIONING_TOKEN}`,
    },
  });

  console.log(await response.text());
}

main();

← Back to Docs Raw markdown guide for AI