Deployments

Deployments in the active organization, paginated, newest-started- first. Matches list_services' (app/api/v1/services.py) own page/per_page + filter shape.

Query Parameters

Response Body

Create a deployment. org_id comes only from org (the authenticated principal's resolved organization) — see this module's schema, app.schemas.deployment, for why the request body has no field for it at all.

Replaying the same (source, idempotency_key) returns the existing row unchanged with 200 OK rather than creating a second one, which is why the status code is set explicitly below instead of relying on the decorator's default 201. See DeploymentRepository.create_or_get for how replay is enforced.

Response Body

The marker-overlay hot path (#876's own reason to exist as a separate endpoint from GET "" — see module docstring). Registered ahead of GET "/{deployment_id}" so "markers" is never parsed as a UUID path parameter.

to before from is rejected the same way services.py::_validate_range rejects it. The window-too-wide case is DeploymentRepository.get_marker_window's own DeploymentMarkerWindowTooWide, caught here and turned into a 400 — matching get_service_signals' SignalsRangeTooWide handling.

Query Parameters

Response Body

What shipped for service between the deployment before an anchor and the anchor itself (#885, epic deployment-attribution, M09) — the deployment-attribution half of "changed since last deploy"; the objectives half is out of scope (epic.md's Dependencies section).

The anchor is given directly (deployment_id) or resolved from a point in time (at) — exactly one of the two, or a 400. DeploymentRepository.get_change_window does the resolution; see that method's docstring for exactly how each input maps to an anchor, and for why from_deployment (the "lower bound") comes back None for the first-ever deployment of a service rather than an empty range.

Registered ahead of GET "/{deployment_id}" for the same reason /markers is: deployment_id's uuid.UUID path-param type does not stop FastAPI matching "changed-since" against that pattern first if it were registered later — it would 422 attempting to parse the literal segment as a UUID rather than falling through to this route.

Commit range comes from CommitLinkService.resolve_commit_range (#881) — never called at all for the first-ever-deployment case (there is no from_deployment to diff against), and returns None (not an error) when the service has no connected source repo. See DeploymentChangedSinceResponse's docstring for the four shapes this produces and how a caller tells them apart without inferring anything from an absence.

Query Parameters

Response Body

One deployment by id, within the active organization. 404 across tenants, matching finish_deployment's own get_by_id precedent.

Path Parameters

Response Body

Finish a deployment: sets finished_at and a terminal status. 404 across tenants, matching SilenceRepository.get_by_id's own org-scoped lookup precedent. 409 when the deployment already has a finished_at — a rollback is reported as a new deployment (its own POST, its own idempotency key), never a second PATCH here; see DeploymentAlreadyFinishedError.

Path Parameters

Response Body

Issues whose first occurrence was attributed to deployment_id. 404s if the deployment itself is not in this org — checked first, via DeploymentRepository.get_by_id's own org-scoped precedent — so a cross-org deployment id and one that does not exist at all read identically, before the issue query ever runs.

Attribution is a candidate, not a verdict (epic architecture decision): this is exactly Issue.deployment_id == deployment_id, the same column the forward read exposes, never a confidence-ranked or causally- asserted subset. A deployment nothing has attributed to yet returns a clean empty page, not an error — the normal case for a fresh deploy.

Path Parameters

Query Parameters

Response Body