hosting

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

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

Ìfàṣẹ́pọ̀

Fi bọ́ọ̀lù (bearer token) ranṣẹ gẹ́gẹ́ bí kọ́kọ́rọ́ API. Kọ́kọ́rọ́ náà gbọ́dọ̀ ní ìyọ̀ǹda hosting.deploy.manage; a ó kọ̀ ọ́ silẹ pẹlu 403, kii ṣe 404, ti kọ́kọ́rọ́ náà kò bá ní i.

Ojú abánisọ̀rọ̀ yìí kò gba id ajọ kankan. Kọ́kọ́rọ́ rẹ ti mọ ajọ ti o jẹ ti e, a o si fèsì nipa rẹ̀.

Gbiyanju rẹ

Rọ́pọ̀ èyíkéyìí nínú àwọn àmì ìtọ́ka < > pẹ̀lú iye tirẹ̀, àti àmì ìdánimọ̀ bọ́tìnnì náà pẹ̀lú bọ́tìnnì kan láti inú dásibọ̀ọ̀dù rẹ.

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> }'

Ṣé o ti wọlé? Iwọ̀n api ní nú ìgbékalẹ̀ rẹ kún id àjọ gidi rẹ ati bọtini tirẹ, o si nṣiṣẹ ibeere na lòdì si api gidi ki o le rii esi gidi na. Ṣí ojú abáná yìí sílẹ̀ nínú kọnsólù API

Àwọn kúlẹ̀kúlẹ̀

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`.

Àwọn ìpìlẹ̀

Orúkọ	Iru	Tí a nílò	Kini o jẹ
`siteId (path)`	`Uuid`	Bẹẹni	Site ID (UUIDv7).

Akoonu ibeere naa

Orúkọ	Iru	Tí a nílò	Kini o jẹ
`provider`	`string`	Bẹẹni	—
`owner`	`string`	Bẹẹkọ	—
`repo`	`string`	Bẹẹni	—
`branch`	`string`	Bẹẹkọ	—
`build_mode`	`BuildMode`	Bẹẹkọ	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`	Bẹẹkọ	—
`output_dir`	`string`	Bẹẹkọ	—
`publish_branch`	`string`	Bẹẹkọ	—
`auto_deploy`	`boolean`	Bẹẹkọ	—

Idahun

Orúkọ	Iru	Tí a nílò	Kini o jẹ
`site_id`	`Uuid`	Bẹẹni	UUIDv7 identifier — sortable by creation time (docs/02 §8).
`provider`	`string`	Bẹẹni	The git provider — `github` or `gitlab`. A machine identifier.
`owner`	`string`	Bẹẹni	The account or namespace the repository lives under.
`repo`	`string`	Bẹẹni	—
`full_name`	`string`	Bẹẹni	`owner/repo`, or just the repo when the account owns its namespace.
`branch`	`string`	Bẹẹni	The branch a push deploys from.
`build_mode`	`BuildMode`	Bẹẹni	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`	Bẹẹni	Blank in `publish` mode — a stored command nothing runs would read as a build.
`output_dir`	`string`	Bẹẹni	Which directory is published. Blank means the repository root.
`publish_branch`	`string`	Bẹẹni	Where CI commits the built output in `ci` mode.
`auto_deploy`	`boolean`	Bẹẹni	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`	Bẹẹni	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`	Bẹẹni	Whether a provider-side hook actually exists. False here with a connection present means pushes are NOT being watched.
`last_delivery_at`	`object`	Bẹẹni	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`	Bẹẹni	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`	Bẹẹni	The label of the credential connection this repository is read with.

Awọn aṣiṣe ti ibudo ipari yii le da pada

401 · 403 · 404 · 422 · 429

PUT /v1/sites/{siteId}/repo