Beta: these routes may change without notice.

Most projects go live on their own when a run lands. These routes let you do the same steps from your own code. The [Apps](/docs/apps) page tells the story in plain words. The reference pages list every field.

Paths here start with `https://api.syndai.ai/api/v1/external/coding/customers/{customer_id}`. `GET /me` returns your `customer_id`. Publishing works only for projects Syndai hosts. A GitHub project ships through its own pipeline.

## 1. Publish

`POST .../repositories/{coding_repository_id}/publish` puts the default branch online after a content check. It answers `202` while the deploy runs. Then poll `GET .../repositories/{coding_repository_id}/publication` until `state` settles.

- A second call while one is going returns the same deploy.
- `409 PUBLISH_IN_FLIGHT` means one is already going.
- `422 PUBLISH_UNSUPPORTED_REPO` means the project is not one Syndai hosts.
- `422 VERIFY_FAILED` means the content check failed, or the site is suspended.

Publishing costs nothing. Hosting past the included use is billed only while the owner has turned on `hosting_paid_on`. See [Publish a repository's app](/docs/api/apps/publish-app).

## 2. Watch it

| call | returns |
|---|---|
| `GET .../apps` | every app in the workspace, with its link and state |
| `GET .../apps/{publication_id}/deployments` | the last ten deploys, with each `status` and error |
| `GET .../apps/{publication_id}/runtime` | missing secrets, AI spend, jobs, visits and taps |

## 3. Settings

`PATCH .../repositories/{coding_repository_id}/publication` changes one or more settings, such as `auto_redeploy` or `visitors`. The spend settings, `hosting_paid_on` and `site_languages_paid_on`, need a signed-in owner or admin. A key gets `403 HUMAN_APPROVAL_REQUIRED`. The same goes for `PUT .../apps/{publication_id}/ai-cap`, the monthly limit on the app's AI.

## 4. Your domain

`POST .../apps/{publication_id}/domain` with `{"hostname": "www.example.com"}` adds your address. Then poll `GET .../apps/{publication_id}/domain`:

- `pending`: add the CNAME in `records` at your DNS host. `domain_connect_url`, when it is there, adds it in one tap.
- `active`: the site serves there, and its syndai.app address sends people to it.
- `failed`: the records never showed up. Add the domain again.

`DELETE .../apps/{publication_id}/domain` moves the site back to its syndai.app address. The [domain reference](/docs/api/apps/add-app-domain) lists every refusal.

## 5. On Google or off

`POST .../apps/{publication_id}/visibility` shows a site on Google, or hides it. It saves the choice in the project and publishes again. Like a text edit, it waits for runs: `409 RUN_IN_FLIGHT` names the run that holds the site. See [Show a site on Google, or hide it](/docs/api/sites/set-site-visibility).

## 6. Take it offline

`DELETE .../repositories/{coding_repository_id}/publication` takes the app offline in the background. It answers `202`. Poll the publication for its final `state`. Your key needs `coding:apps:unpublish`, which a browser login never grants.

## App stores

The [Store](/docs/api) routes ship an app to the App Store and Google Play: connections, builds, the listing in each language, screenshots and releases. The [Sites](/docs/api) routes connect a website to Google Search Console and check how AI assistants answer about it. Start from those reference pages.