---
title: "Set Connection Dataset"
method: POST
path: "/api/v1/integrations/{provider}/connection/dataset"
tags: ["integrations"]
---

# Set Connection Dataset

`POST /api/v1/integrations/{provider}/connection/dataset`

## Request

- Base URL: `https://api.aws.cognee.ai` (the document declares no server; this is the origin it was published from)
- URL: `https://api.aws.cognee.ai/api/v1/integrations/{provider}/connection/dataset`
- Auth: API key in header `X-Api-Key`

Choose or clear this connection's target dataset. Owner-only (CLO-1014).

Takes effect on the *next* sync only — an already-dispatched or
in-flight sync keeps ingesting into whatever it was handed, the same
as changing the resource selection does; a sync already in flight
answers 409 unconditionally instead (finding #7), not only when
``delete_old_target`` is set — a target changing under GitHub's clone
directory mid-sync is unsafe regardless of whether anything is also
being deleted.

``payload.dataset_id`` is checked against
:func:`~.flow.list_writable_datasets`, never trusted from the
request body alone — that list is also where a name shaped like some
connector's own default has already been excluded (finding #1), and
this route stores *that* list's own name for the id, never
``payload.dataset_name`` (finding #2): a client-supplied name is
cosmetic only, until it is replaced with the one the pod itself
reports for that id.

**Write, then delete, never the other way round (finding #6).** The
new target is recorded first, under the row's own lock, with an
optimistic check that nobody moved the target from under this
request between the read above and the write; only once that has
committed does a requested ``delete_old_target`` run. A delete that
then fails leaves the connection pointed at its new target with the
old one's content merely undeleted — recorded in ``previous_targets``
for a later retry — rather than the reverse order's failure mode,
where a successful delete followed by a failed write would leave the
connection believing it still owns content that is already gone.

## Path parameters

- `provider` string, required

## Query parameters

- `tenant_id` string, uuid, required
- `account_id` string, nullable

## Request body

- IntegrationsGetConnectorsRouterSetTargetDatasetPayload: Body for ``POST /{provider}/connection/dataset`` (CLO-1014). ``dataset_id=None`` clears a chosen target and returns the connection to the connector's own default — the same "explicit null, not a removed key" contract :class:`ResourceSelection`'s own ``null`` carries, for the identical reason (the write path is a merge). ``dataset_name`` is required alongside a non-``None`` ``dataset_id``: it is display data only (the id is what ``remember()`` actually resolves against), but a bare id with nothing to show is a connection view that cannot say where its own content lands. ``sweep_previous_only`` (CLO-1069) switches the whole route into a distinct, explicit mode - see the field's own docstring - rather than leaving a retry to be inferred from a same-target body, which a stale frontend snapshot can get wrong in a way that moves the target.
  - `dataset_id` string, uuid, nullable
  - `dataset_name` string, nullable
  - `delete_old_target` boolean
  - `sweep_previous_only` boolean

## Response `200`

Successful Response

- unknown

## Other responses

- `422`: Validation Error

---

[API](https://skmtc.dev/cognee/apis/cognee-api.md) - [All operations](https://skmtc.dev/cognee/apis/cognee-api/llms.txt) - [OpenAPI document](https://skmtc.dev/cognee/apis/cognee-api/revisions/a7b6c6cb8212?raw)