Card dependencies

A dependency is a directed edge between two cards: "this card depends on that card." It is a plain relationship — declaring one does not block moving, completing, or archiving either card. Dependencies live at the workspace level: the two cards can be on the same board or on any two boards in the workspace, as long as you have access to both.

Endpoints

Operation	Endpoint
Read a card's dependencies and dependents	GET /cards/{card_id}/dependencies
Declare a dependency	PUT /cards/{card_id}/dependencies/{depends_on_card_id}
Remove a dependency	DELETE /cards/{card_id}/dependencies/{depends_on_card_id}

Declaring and removing are desired-state, like assignees and applied labels: a PUT ensures the edge exists, a DELETE ensures it does not, both are naturally retryable, and neither takes Idempotency-Key or If-Match.

One edge, two projections

PUT /cards/{card_id}/dependencies/{depends_on_card_id} stores a single directed edge: card_id depends on depends_on_card_id. GET /cards/{card_id}/dependencies reads that same graph from the requested card's point of view, split into two lists:

• dependencies — cards that this card depends on (edges pointing away from it);
• dependents — cards that depend on this card (edges pointing at it).

Each entry (CardDependencyItem) carries enough to render without a follow-up call: card_id, identifier, title, board_id, board_name, a workstream summary, and archived_at.

Self, duplicate, and cycle rules

• Self-dependency is rejected. A card cannot depend on itself: 422 validation_error.
• Duplicates are a no-op. Declaring the same edge twice returns 200 both times and changes nothing — that is the point of desired-state semantics.
• Cycles are rejected. If depends_on_card_id already depends on card_id, directly or transitively, the write fails with 409 conflict instead of creating a cycle. The dependency graph is always a DAG.

Visibility filtering

GET /cards/{card_id}/dependencies only returns edges where the other card is currently visible to you. If a counterpart card's board access is revoked (or it otherwise stops being visible), its edge is silently omitted from both lists — the underlying relationship is untouched and reappears if visibility is restored. This is the same pattern attachments and covers use — see File attachments.

Dependencies are informational

Setting a dependency has no side effect on either card: it does not block completion, archiving, moving, or deletion, and — unlike assignees, labels, subtasks, and comments (see Collaboration resources) — it is not part of either card's version-tracked representation. Use dependencies to communicate sequencing to humans and downstream tooling, not to enforce a workflow.

For a worked example that declares a dependency across two boards, see Organize work with workstreams.