hosting

PUT `/v1/sites/{siteId}/repo`

Connect (or re-connect) a repository to a site.

Authentication

Send an API key as a bearer token. The key must carry the hosting.deploy.manage permission; a key without it is refused with 403, not 404.

This endpoint takes no organisation id. Your key already identifies the organisation it belongs to, and the response is scoped to it.

Try it

Replace anything in angle brackets with your own values, and the key placeholder with a key from your dashboard.

curl -X PUT https://api.zinndigital.com/v1/sites/{siteId}/repo \
  -H "Authorization: Bearer zdk_live_…" \
  -H "Content-Type: application/json" \
  -d '{ "provider": <string>, "repo": <string> }'

Signed in? The API console in your dashboard fills in your real organisation id and your own key, and runs the request against the live API so you can see the actual response. Open this endpoint in the API console

Details

Confirms the repository exists on the connected account, stores the connection, and creates or updates the provider-side push webhook — and, when `build_mode` is `ci`, commits the Zinn® build workflow to the repository. The provider work happens before the row is reported as connected, so a hook that could not be created never leaves a row claiming it was. Requires `hosting.deploy.manage`.

Parameters

Name	Type	Required	What it is
`siteId (path)`	`Uuid`	Yes	Site ID (UUIDv7).

Request body

Name	Type	Required	What it is
`provider`	`string`	Yes	—
`owner`	`string`	No	—
`repo`	`string`	Yes	—
`branch`	`string`	No	—
`build_mode`	`BuildMode`	No	How the published files are produced. `publish` serves the repository's own files — right for plain HTML and for a repo whose generator output is committed. `ci` runs the build…
`build_command`	`string`	No	—
`output_dir`	`string`	No	—
`publish_branch`	`string`	No	—
`auto_deploy`	`boolean`	No	—

Response

Name	Type	Required	What it is
`site_id`	`Uuid`	Yes	UUIDv7 identifier — sortable by creation time (docs/02 §8).
`provider`	`string`	Yes	The git provider — `github` or `gitlab`. A machine identifier.
`owner`	`string`	Yes	The account or namespace the repository lives under.
`repo`	`string`	Yes	—
`full_name`	`string`	Yes	`owner/repo`, or just the repo when the account owns its namespace.
`branch`	`string`	Yes	The branch a push deploys from.
`build_mode`	`BuildMode`	Yes	How the published files are produced. `publish` serves the repository's own files — right for plain HTML and for a repo whose generator output is committed. `ci` runs the build…
`build_command`	`string`	Yes	Blank in `publish` mode — a stored command nothing runs would read as a build.
`output_dir`	`string`	Yes	Which directory is published. Blank means the repository root.
`publish_branch`	`string`	Yes	Where CI commits the built output in `ci` mode.
`auto_deploy`	`boolean`	Yes	Whether a push deploys automatically. Off still records every delivery, so a customer can watch pushes arriving before letting us act on them.
`webhook_url`	`string`	Yes	The URL the provider was told to deliver to. Computed, never stored — a stored copy would keep naming the origin that was current when the row was written. Blank on an environme…
`webhook_registered`	`boolean`	Yes	Whether a provider-side hook actually exists. False here with a connection present means pushes are NOT being watched.
`last_delivery_at`	`object`	Yes	When the provider last delivered anything, or null for NEVER. Null is the single most useful diagnostic on this screen: "connected but never delivered" is what a mis-scoped toke…
`last_delivery_note`	`string`	Yes	What we did with the last delivery, including when we ignored it. Written for every delivery, because "never delivered" and "delivering, ignored" are different problems with dif…
`connected_account`	`string`	Yes	The label of the credential connection this repository is read with.

Errors this endpoint can return

401 · 403 · 404 · 422 · 429

PUT /v1/sites/{siteId}/repo