> ## Documentation Index > Fetch the complete documentation index at: https://docs.goosybear.ai/llms.txt > Use this file to discover all available pages before exploring further. # Create, undo and schedule > Create a site, read its saved checkpoints, undo and redo changes, restore a checkpoint, schedule a publish, and switch tracking, all through the API. These calls take the usual `site_id` and optional `workspace` ([Which workspace](https://docs.goosybear.ai/api/pages.md#which-workspace)). A call that changes what visitors see, or that spends credits, answers in **two calls**: send it without `confirmation_id` to see what would happen (nothing changes), then send the same arguments with the `confirmation_id` once a person approves. The second call needs a member's own API key; a service-account key can propose but never approve. ## Create a site `page.create` makes a new site, built with Astro, from a starter with a home page, an about page and a contact page, working navigation and the search and AI discovery files. It answers in two calls. The first spends nothing, and the second charges what the same request charges in Goosy. | Field | What it is | | - | - | | `name` | Optional. Up to 80 characters. Leave it out for the default. | | `intent` | Optional. What the site is for, up to 2,000 characters. Leave it out and you get the starter's own copy with no generated writing. | | `blueprint_id` | Optional. Which starter to begin from: one of ours, or a template saved in your workspace. | | `inspiration_url` | Optional. A full `https://` link to take the structure of. We never reuse its wording or offers. It is ignored when `blueprint_id` is given. | When you give an `intent`, the brief and the brand's own kit go to our model provider to write the copy. A new site that needs people to sign in or data to be saved is a different kind of site, built in Goosy; this call builds the website kind. ## Read what has changed `page.checkpoint` reads a site's recent changes, newest first, with what was asked for each, when, and which files it touched. It also says whether undo and redo have anywhere to go, and where the source stands: the checkpoint it is at, the list of checkpoints with each one's build status and revision, and the newest build, with the end of its failure log when it failed. Every change to the site's files, and every save, makes a checkpoint. Pass `site_id`; it changes nothing. ## Undo, redo and restore These work on the site's **draft**. The live site is untouched until you publish. | Call | What it does | | - | - | | `page.undo` | Puts the draft back to how it stood before its latest change and rebuilds the preview. The undone change stays in the history. | | `page.redo` | Puts back the change you last undid. A fresh change after an undo clears what can be redone. | | `page.restore_checkpoint` | Takes `source_ref`, a checkpoint from `page.checkpoint`, and restores the draft to it, then rebuilds. The restore is recorded as a new change, so `page.undo` steps back from it. A checkpoint whose archive is gone is refused; pick another. | `page.undo` and `page.redo` need no approval and answer in one call. To step from exactly what `page.checkpoint` last reported, pass its `history_revision`. A change is undone or redone only when the answer says so. `page.restore_checkpoint` also answers in one call and runs under the key holder's membership. To change what visitors see, publish ([Pages API](https://docs.goosybear.ai/api/pages.md#publish-one-exact-revision)) or put a previous build back live ([Put a previous build back](https://docs.goosybear.ai/api/pages.md#put-a-previous-build-back)). ## Publish at a set time `page.schedule_publish` puts the site's built version live at a time you choose. It answers in two calls. * `at` is an ISO-8601 time **with its UTC offset**, such as `2026-09-08T09:00:00-06:00`. Never send a bare local time. * It must be at least five minutes away and within the next year. * If a time was already set, the new one replaces it and the answer says `replaced`. `page.cancel_scheduled_publish` calls off the scheduled publish. It takes only `site_id`. When `cancelled` is `false`, nothing was waiting (it may have already published or been cancelled) and the site won't publish on a timer either way. The live site keeps what it serves. ## Switch tracking `page.set_tracking` changes which forms count as conversions and whether one tracking pixel runs on this site. Send either part: * `conversion_forms`: a list of form names (each by the lowercase name it submits as its `form` field). Only those forms' leads are reported to the ad platforms as conversions. `null` puts every form back. * `provider` with `enabled`: turns one pixel off for this site (`false`) or back on (`true`). Take the provider from `page.read`'s pixel list. Which pixels exist at all comes from the workspace's connections. The change is saved and reaches the live site within about a minute. Nothing needs republishing. It answers in one call. To switch the cookie consent banner or all the ad pixels together on an imported site, use `page.set_platform_properties` (`consent_banner`, `ad_pixels`, `consent_mode`; see [Bringing your own site](https://docs.goosybear.ai/api/bringing-your-own-site.md)). ## Where to go next * [Pages API](https://docs.goosybear.ai/api/pages.md) * [Who can open a site](https://docs.goosybear.ai/api/pages-access.md) * [Videos on a site](https://docs.goosybear.ai/api/pages-videos.md) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.