Import or replace a site from an archive
Uploads one ZIP archive and either creates a site or replaces the code of an existing one. The service classifies the archive from its CONTENTS — a prebuilt bundle is staged immediately, a supported source project is queued for the build rail — and validates any pages.deploy.json it carries against the published PagesDeployManifest schema, returning the manifest it resolved on every success. The archive must be no larger than 41943040 bytes.
A push onto a site that already holds a code project shows the diff first. With siteId set and a current project on that site, the call answers 202 with data.outcome: "pending_confirmation", the diff against the current project and a handle — nothing is written. Send the SAME archive again with ?confirm=<handle> to apply it (200, outcome: "ingested"). Byte-identical bytes answer 200 with outcome: "unchanged" and write nothing — and where the site's stored source had no build that came up, that same answer carries a buildRunId, because re-pushing an unbuilt project queues its build rather than leaving the site dark. Once such a project has spent the rail's build attempts, the answer stays 200 unchanged and carries buildBlocked instead: re-pushing an identical archive is never an error, so an idempotent deploy stays green, and the field is where a person is told that only a changed file will build. A first upload proceeds directly. The replaced set is the code project only: the site's database, its storage, its media and its data tables are never touched by a push.
Request
- Base URL: https://app.goosybear.ai
- URL: https://app.goosybear.ai/api/pages/ingest
- Auth: HTTP bearer
Query parameters
Which workspace to act in — its slug or id. The SAME argument every workspace-scoped tool takes, resolved the same way: an account-wide key may select any workspace its holder currently reaches, a workspace-pinned key may only name its own, and a call that names nothing falls through to your default. It is a QUERY parameter rather than a body field on purpose: this endpoint's body is a multipart upload, and reading a field out of it would decode that body before the bearer and the rate limiter had run. With more than one reachable workspace and no default, the call is refused as workspace_ambiguous and the choices are listed. Ignored for a signed-in session, whose workspace comes from its own claims.
The handle a previous 202 answered with. Present ⇒ apply the diff that handle was issued for: the archive must be byte-identical to the one the diff was shown for, and the site's current project must still be the base it was shown against, else 400 (confirmation_stale). Ignored on a first upload.
Response
The archive was applied, or was identical to the current project. Read data.outcome first: ingested (then data.kind tells a staged upload from a queued build) or unchanged (nothing was written).
Changes
No recorded changes to this operation across all 4 revisions of this API.