hostinger-api-mcp 3.24.3 → 3.25.0

package/CHANGELOG.md

@@ -4,6 +4,26 @@ Generated at release time from the diff between the previous and current
 build. Tool changes are listed individually; everything else is summarised
 by area.
 
+## v3.25.0 — 2026-11-03
+
+### Operations
+
+- Added `hosting_websites_list-domains` — List website parked (alias) domains and subdomains
+- Added `hosting_websites_add-domain` — Add a parked (alias) domain or subdomain to a website
+- Added `hosting_websites_remove-domain` — Remove a parked (alias) domain or subdomain from a website
+- Added `hosting_websites_create-deprecated` — Create website
+- Hid 8 operations from search (they still run through `execute`): `hosting_websites_start-setup`, `hosting_domains_generate-free-subdomain`, `hosting_domains_list-website-parked`, `hosting_domains_create-website-parked`, `hosting_domains_delete-website-parked`, `hosting_domains_list-website-subdomains`, `hosting_domains_create-website-subdomain`, `hosting_domains_delete-website-subdomain`
+- Changed the title, annotations, description, HTTP method, endpoint path, input schema and auth requirements of `hosting_websites_start-setup`
+- Changed the title, annotations, description, endpoint path and input schema of `hosting_websites_create`
+
+### Also in this release
+
+- Documentation: `README.md`
+- Bundled agent skills: 9 files
+- Request handling and authentication: `src/core/runtime.js`, `src/core/runtime.ts`
+- Other files: `src/core/skills.js`, `src/core/skills.ts`
+- Build and packaging: `types.d.ts`
+
 ## v3.24.3 — 2026-11-03
 
 ### Also in this release

package/README.md

@@ -69,7 +69,7 @@ pnpm update -g @hostinger/mcp
 
 This package installs the following MCP server commands:
 
-- `hostinger-api-mcp` — unified server over every operation (413 total)
+- `hostinger-api-mcp` — unified server over every operation (408 total)
 - `hostinger-agency-hosting-mcp` — 43 operations for agency-hosting
 - `hostinger-agent-readiness-mcp` — 4 operations for agent-readiness
 - `hostinger-billing-mcp` — 10 operations for billing
@@ -77,7 +77,7 @@ This package installs the following MCP server commands:
 - `hostinger-domains-mcp` — 43 operations for domains
 - `hostinger-ecommerce-mcp` — 30 operations for ecommerce
 - `hostinger-horizons-mcp` — 7 operations for horizons
-- `hostinger-hosting-mcp` — 62 operations for hosting
+- `hostinger-hosting-mcp` — 57 operations for hosting
 - `hostinger-mail-mcp` — 39 operations for mail
 - `hostinger-reach-mcp` — 71 operations for reach
 - `hostinger-vps-mcp` — 68 operations for vps
@@ -1905,6 +1905,27 @@ Clear a website's server cache (the hosting server's page cache) and Hostinger C
 - **Method**: `custom`
 - **Path**: `custom`
 
+#### hosting_websites_list-domains
+
+List the extra domains of a website: its parked (alias) domains, which show the same site under another domain name, and its subdomains (e.g. blog.example.com), with each one's root directory. parked items have domain (a domain name or an IP address) and type (domain or ip); subdomains items have domain (the full name), subdomain (the prefix) and root_directory. A list that cannot be read comes back as { error } and the other is still returned. To add or remove one use hosting_websites_add-domain or hosting_websites_remove-domain. Works for Shared and Cloud hosting websites.
+
+- **Method**: `custom`
+- **Path**: `custom`
+
+#### hosting_websites_add-domain
+
+Add a domain to an existing website: type parked adds a parked (alias) domain, a second domain name (or an IP address) that shows the same site; type subdomain creates a subdomain such as blog.example.com with its own directory. For a parked domain the domain must be owned by the account or already point to the website: check a domain from outside the account with hosting_domains_verify-ownership first. www belongs to the main domain: do not add it as a subdomain. To create a new website use hosting_websites_create instead. Works for Shared and Cloud hosting websites.
+
+- **Method**: `custom`
+- **Path**: `custom`
+
+#### hosting_websites_remove-domain
+
+Remove a parked (alias) domain or a subdomain from a website. Pass its name as hosting_websites_list-domains shows it: a parked domain, or a subdomain's full name or prefix; the tool finds which one it is. To delete a whole website use hosting_websites_delete. Works for Shared and Cloud hosting websites.
+
+- **Method**: `custom`
+- **Path**: `custom`
+
 #### hosting_websites_trigger-event
 
 Tell Hostinger that something happened on this website, so Hostinger services such as hPanel can react to it. `event.name` picks the event and decides which `event.params` it takes. The call changes nothing on the website.
@@ -2072,73 +2093,6 @@ requirements.
 - **Method**: `GET`
 - **Path**: `/api/hosting/v1/datacenters`
 
-#### hosting_domains_generate-free-subdomain
-
-Generate a unique free subdomain that can be used for hosting services without purchasing custom domains.
-Free subdomains allow you to start using hosting services immediately
-and you can always connect a custom domain to your site later.
-
-- **Method**: `POST`
-- **Path**: `/api/hosting/v1/domains/free-subdomains`
-
-#### hosting_domains_list-website-parked
-
-Retrieve all parked or alias domains created under the selected website.
-
-Use this endpoint to inspect parked domain configuration for a specific website,
-including the parent domain and root directory assigned to each parked domain.
-
-- **Method**: `GET`
-- **Path**: `/api/hosting/v1/accounts/{username}/websites/{domain}/parked-domains`
-
-#### hosting_domains_create-website-parked
-
-Create a parked or alias domain for the selected website.
-
-Provide a domain name or IP address to park on the website so it serves the same content
-as the parent domain.
-
-- **Method**: `POST`
-- **Path**: `/api/hosting/v1/accounts/{username}/websites/{domain}/parked-domains`
-
-#### hosting_domains_delete-website-parked
-
-Delete an existing parked or alias domain from the selected website.
-
-Use this endpoint to remove parked domains that are no longer needed.
-
-- **Method**: `DELETE`
-- **Path**: `/api/hosting/v1/accounts/{username}/websites/{domain}/parked-domains/{parkedDomain}`
-
-#### hosting_domains_list-website-subdomains
-
-Retrieve all subdomains created under the selected website.
-
-Use this endpoint to inspect subdomain configuration for a specific website,
-including the parent domain and root directory assigned to each subdomain.
-
-- **Method**: `GET`
-- **Path**: `/api/hosting/v1/accounts/{username}/websites/{domain}/subdomains`
-
-#### hosting_domains_create-website-subdomain
-
-Create a new subdomain for the selected website.
-
-Provide a subdomain prefix and, optionally, a custom directory or the
-website public directory to use as the subdomain root.
-
-- **Method**: `POST`
-- **Path**: `/api/hosting/v1/accounts/{username}/websites/{domain}/subdomains`
-
-#### hosting_domains_delete-website-subdomain
-
-Delete an existing subdomain from the selected website.
-
-Use this endpoint to remove subdomains that are no longer needed.
-
-- **Method**: `DELETE`
-- **Path**: `/api/hosting/v1/accounts/{username}/websites/{domain}/subdomains/{subdomain}`
-
 #### hosting_domains_verify-ownership
 
 Verify ownership of a single domain and return the verification status.
@@ -2383,7 +2337,7 @@ website.
 - **Method**: `GET`
 - **Path**: `/api/hosting/v1/onboardings`
 
-#### hosting_websites_start-setup
+#### hosting_websites_create
 
 Starts a website setup on a Web or Cloud hosting order and returns the created setup
 right away; the website itself is provisioned asynchronously. Poll the list website
@@ -2570,34 +2524,6 @@ endpoint instead.
 - **Method**: `GET`
 - **Path**: `/api/hosting/v1/websites`
 
-#### hosting_websites_create
-
-Deprecated: use `POST /api/hosting/v1/orders/{order_id}/onboardings` (start website setup)
-instead. It takes the same `domain` and `datacenter_code`, can also install WordPress, and
-returns the created setup.
-
-Create a new website for the authenticated client.
-
-You must choose which hosting order to create this website on. Pass that
-order as `order_id` together with the domain name. List orders to see
-available IDs; the website is provisioned on that order's hosting plan.
-
-Only Web and Cloud hosting orders are accepted. To create a website on an Agency
-Plan order, use `POST /api/agency-hosting/v1/orders/{order_id}/websites/setups`.
-
-When the order has no hosting account yet, a new hosting account is set up first, in the
-datacenter given by `datacenter_code` or the order's default datacenter when it is omitted.
-Subsequent websites will be hosted on the same datacenter automatically.
-
-Website creation is asynchronous and takes up to a few minutes. Poll the list website
-setups endpoint with the `domain` filter every 10 to 15 seconds and wait for `status:
-completed` before uploading files, deploying or creating databases. While the setup is
-`running`, endpoints that operate on the website may respond with `404` or `409`.
-`is_enabled` on the websites list reflects suspension, not readiness.
-
-- **Method**: `POST`
-- **Path**: `/api/hosting/v1/websites`
-
 #### hosting_websites_delete
 
 This endpoint permanently removes a website and all of its data. This action

package/gemini-extension.json

@@ -1,6 +1,6 @@
 {
   "name": "hostinger-api-mcp",
-  "version": "3.24.3",
+  "version": "3.25.0",
   "description": "Hostinger API — manage domains, DNS, hosting, VPS, billing and more from Gemini CLI.",
   "mcpServers": {
     "hostinger": {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "hostinger-api-mcp",
-  "version": "3.24.3",
+  "version": "3.25.0",
   "mcpName": "io.github.hostinger/hostinger-api-mcp",
   "description": "MCP server for Hostinger API",
   "repository": {

package/server.json

@@ -6,12 +6,12 @@
     "url": "https://github.com/hostinger/api-mcp-server",
     "source": "github"
   },
-  "version": "3.24.3",
+  "version": "3.25.0",
   "packages": [
     {
       "registryType": "npm",
       "identifier": "@hostinger/mcp",
-      "version": "3.24.3",
+      "version": "3.25.0",
       "transport": {
         "type": "stdio"
       },

package/skills/connect-domain/SKILL.md

@@ -28,10 +28,10 @@ dig +short MX DOMAIN; dig +short TXT DOMAIN; dig +short CAA DOMAIN
 
 Shared and Cloud:
 
-- **New website on the domain.** For a domain outside this account run `hosting_domains_verify-ownership` first. When `is_accessible` is false, give the user the `TXT` record it returns to add next to the existing ones, then verify again (propagation takes up to ~10 minutes). Create with `hosting_websites_create` (`domain` without `www.`, `order_id`), then poll `hosting_websites_list-setups` with `domain` every 10–15 s until `status: completed`.
-- **Moving a site off its free subdomain.** Shared and Cloud websites cannot be renamed through the API. Either create a website on the real domain and redeploy the project there (the `deploy-to-hosting` skill) — required for WordPress, which keeps its URL in the database — or, for static sites, park the domain on the existing site with `hosting_domains_create-website-parked`.
-- **Alias** (a second domain showing the same site): `hosting_domains_create-website-parked`.
-- **Subdomain** (`shop.example.com`): `hosting_domains_create-website-subdomain`. `www` belongs to the main domain — do not create it as a subdomain.
+- **New website on the domain.** For a domain outside this account run `hosting_domains_verify-ownership` first. When `is_accessible` is false, give the user the `TXT` record it returns to add next to the existing ones, then verify again (propagation takes up to ~10 minutes). Create with `hosting_websites_create` (`order_id`, `domain` without `www.`), then poll `hosting_websites_list-setups` with `domain` every 10–15 s until `status: completed`.
+- **Moving a site off its free subdomain.** Shared and Cloud websites cannot be renamed through the API. Either create a website on the real domain and redeploy the project there (the `deploy-to-hosting` skill) — required for WordPress, which keeps its URL in the database — or, for static sites, park the domain on the existing site with `hosting_websites_add-domain` (`type: "parked"`).
+- **Alias** (a second domain showing the same site): `hosting_websites_add-domain` with `type: "parked"`.
+- **Subdomain** (`shop.example.com`): `hosting_websites_add-domain` with `type: "subdomain"`. `www` belongs to the main domain — do not create it as a subdomain.
 
 Agency Plan:
 

package/skills/deploy-to-hosting/SKILL.md

@@ -32,7 +32,7 @@ Run it from the project directory: the link is written in the current directory,
 - `.hostinger/site.json` in the project: reuse its `domain` and `username` (or `website_uid`) — only without asking when you or the user wrote it in an earlier deploy; if `git ls-files .hostinger/site.json` lists it, or the project was cloned or downloaded, name the domain and confirm it with the user first. The CLI's `hostinger up` and `hostinger link` write the same file and keep any fields you add while it names the same website (linking another website starts it afresh); its `type` may be `static`, `nodejs` or `php`.
 - Otherwise look the domain up with `hosting_websites_list` (Shared and Cloud; substring match — take the exact entry) and `agency-hosting_websites_list-plan` (Agency; keep `details.uid`).
 - No website yet:
-  - Shared and Cloud: take a domain (the user's own, or `hosting_domains_generate-free-subdomain`) and an `order_id` from `hosting_orders_list`, then `hosting_websites_create`. `datacenter_code` is needed only for the first website on a new plan (first entry of `hosting_datacenters_list`). Poll `hosting_websites_list-setups` with `domain` every 10–15 s until `status: completed` — uploads and deploys return 404 or 409 before that.
+  - Shared and Cloud: take an `order_id` from `hosting_orders_list`, then `hosting_websites_create` with the user's own domain, or without `domain` for a free subdomain (the response carries it). `datacenter_code` is needed only for the first website on a new plan (first entry of `hosting_datacenters_list`). Poll `hosting_websites_list-setups` with `domain` every 10–15 s until `status: completed` — uploads and deploys return 404 or 409 before that.
   - Agency: `agency-hosting_website-setups_create` with `flavor: "php-fpm"` (plus `type: "node-static"` for built frontends), `settings.php.version` from `agency-hosting_php_list-versions-for-order` and `datacenter_code` from `agency-hosting_datacenters_list`. Poll `agency-hosting_website-setups_status` until `completed`; it returns the `website_uid`.
 - Node.js apps run on Business and Cloud plans (`hostinger_business_*`, `cloud_*` in `hosting_orders_list`). On other plans, build locally and deploy the output as a static site.
 

package/skills/headless/SKILL.md

@@ -165,7 +165,7 @@ but an instance existing does **not** mean provision is done or can be skipped.
 which of these cases applies and records it, then provision takes the matching path:
 
 1. **An empty headless shell already exists for the domain (the common onboarding case).** Onboarding
-   creates the website first — an **empty headless shell** (`hosting_websites_start-setup { type:
+   creates the website first — an **empty headless shell** (`hosting_websites_create { type:
    "headless_empty" }`): `website_type` is `headless`, but **no backend is installed** (no WordPress at
    `/cms`, no store). This still goes through provision, which **adopts the shell and swaps it to the
    chosen backend** (the backend is picked in refine first): WordPress is installed into the shell's
@@ -173,14 +173,14 @@ which of these cases applies and records it, then provision takes the matching p
    Ecommerce storefront host. **Never skip provision for a shell, and never create a second site.** See
    the provision router's *Onboarding handoff*.
 2. **No instance exists at all** (the user ran the headless flow without onboarding provisioning
-   anything). Provision creates a fresh headless instance with `hosting_websites_start-setup` using the
+   anything). Provision creates a fresh headless instance with `hosting_websites_create` using the
    chosen backend's own `type`.
 3. **User wants a webapp.** Provision is a plain Node.js app host, not headless — `webapp` ignores
    headless shells entirely and is only reached by experimental actions, never the onboarding flow.
 
 Either way the create/install is asynchronous and returns `queued` immediately, then it's polled
 every ~15 s for a few minutes — **what you poll depends on the path**: a fresh
-`hosting_websites_start-setup` is polled with `hosting_websites_list-setups` until `completed`, while a
+`hosting_websites_create` is polled with `hosting_websites_list-setups` until `completed`, while a
 shell swap (`wordpress_installations_install`) creates no new setup, so it's polled with
 `wordpress_installations_list` until the `/cms` row is `is_valid`. Don't block on that poll. The
 single rule that makes the overlap safe:

package/skills/headless/VERSION

@@ -1,3 +1,3 @@
-version=3.24.3
-commit=486008c7b123
+version=3.25.0
+commit=f6e99e0c7be6
 built=2026-11-03

package/skills/headless/steps/01-check-state/SKILL.md

@@ -130,7 +130,7 @@ Query the Hostinger connector — the local files are never trusted on their own
   - `status: failed` → provisioning stopped before finishing → route to **provision** to self-heal.
 - **Is it an empty headless shell from onboarding?** A `headless` site whose setup is `completed` is
   **not necessarily finished** — onboarding now creates the website *before* the build runs, as an
-  **empty headless shell** (`hosting_websites_start-setup { type: "headless_empty" }`): `website_type`
+  **empty headless shell** (`hosting_websites_create { type: "headless_empty" }`): `website_type`
   is `headless` but **no backend is installed** (no WordPress at `/cms`, no store). Tell a shell from a
   real backend the same way provision does: within 24 h the setup `type` is `headless_empty`; otherwise
   `wordpress_installations_list { username, domain, ownership: "all" }` returns **no** `/cms` row and

package/skills/headless/steps/03-provision/SKILL.md

@@ -46,7 +46,7 @@ Tell the user the backend and its one-line reason before provisioning.
 > that brings its own code and data; it never installs WordPress. PocketBase is not available in this
 > version — refine never proposes it, and there is no `pocketbase/` subfolder; if a brief somehow names
 > it, stop and tell the user rather than improvising it. A **WordPress + Ecommerce** brief (two separate
-> backends — a WordPress site **and** a Hostinger Ecommerce store) has no single combined `start-setup`
+> backends — a WordPress site **and** a Hostinger Ecommerce store) has no single combined `hosting_websites_create`
 > type yet: stop, tell the user it isn't supported as one site, and offer either to continue with just
 > WordPress or just Ecommerce (route to that one subfolder), **or**, if they want content and a store on
 > **one** site, to switch the brief to **WordPress + WooCommerce** — the one-site path, which routes to
@@ -56,22 +56,22 @@ Tell the user the backend and its one-line reason before provisioning.
 
 Onboarding can create the website **before** you ever run, then paste the build prompt into this agent.
 When it does, the domain already has an **empty headless shell**: a website set up with
-`hosting_websites_start-setup { type: "headless_empty" }` — `website_type` is `headless`, but **nothing
+`hosting_websites_create { type: "headless_empty" }` — `website_type` is `headless`, but **nothing
 is installed** (no WordPress at `/cms`, no store). It is the hosting slot only, waiting for a backend.
 
 So provision has **two entry shapes**, and each subfolder's *detect* step picks between them:
 
 - **An empty headless shell already exists for the domain → adopt it and *swap* it to the chosen
-  backend. Never call `start-setup` again, never create a second site.** The swap is backend-specific:
+  backend. Never call `hosting_websites_create` again, never create a second site.** The swap is backend-specific:
   - **WordPress** → install WordPress **into the existing shell's `/cms`** with
     `wordpress_installations_install { type: "headless" }` (it rewrites the root `.htaccess` and marks
-    the site headless-WordPress). Do **not** use `start-setup { type: "headless_wordpress" }` — that is
+    the site headless-WordPress). Do **not** use `hosting_websites_create { type: "headless_wordpress" }` — that is
     only for creating a fresh site.
   - **Ecommerce** → the empty headless shell **is** the storefront host already (a `headless_ecommerce`
     website installs no store engine either). Adopt it as the frontend host and go straight to creating
     the store + custom sales channel.
 - **No site exists for the domain at all → create it fresh, exactly as each subfolder defines today**
-  (`start-setup` with the backend's own `type`).
+  (`hosting_websites_create` with the backend's own `type`).
 
 > **Webapp is not part of this handoff at all.** `webapp` is **not** reached on the usual onboarding
 > flow — it is only triggered by experimental actions — so it **ignores headless instances entirely**:
@@ -107,8 +107,8 @@ asynchronous — fire it, record `provision.in_progress`, and join at the barrie
 > 1. **Exact-match the domain** in `hosting_websites_list` (substring filter — match the exact `domain`).
 > 2. **A `headless` row already exists → adopt + swap it, never create.** Install the backend into that
 >    same site (WordPress → `wordpress_installations_install { type: "headless" }` into `/cms`; Ecommerce
->    → adopt as the storefront host). **Do not call `start-setup` again** — that makes a second site.
-> 3. **No row at all → create one fresh** with the backend's own `start-setup` type. Create it for **this
+>    → adopt as the storefront host). **Do not call `hosting_websites_create` again** — that makes a second site.
+> 3. **No row at all → create one fresh** with the backend's own `hosting_websites_create` type. Create it for **this
 >    build's domain only** — never provision the backend on a different domain than the frontend (the CMS
 >    is the `/cms` path of the same site, never a separate `cms.<domain>`).
 > 4. **A row of a different kind** (`website_type` not `headless`) → **stop and tell the user**; never
@@ -117,7 +117,7 @@ asynchronous — fire it, record `provision.in_progress`, and join at the barrie
 > This is the whole of *Onboarding handoff* above, as one checklist. See it for how to tell an empty
 > shell from an already-provisioned backend.
 
-Follow the chosen subfolder's `SKILL.md` through **detect + create** (its "start-setup" call). The
+Follow the chosen subfolder's `SKILL.md` through **detect + create** (its `hosting_websites_create` call). The
 moment the create is accepted and queued, record it in `state.json` and **return** — do not sit on the
 readiness poll:
 

package/skills/headless/steps/03-provision/ecommerce/SKILL.md

@@ -50,11 +50,10 @@ Same lifecycle as `../wordpress/SKILL.md` Steps 1–2, but `type: "headless_ecom
 1. Detect: `hosting_websites_list` / `hosting_websites_list-setups` (exact-match the domain). `completed`
    → adopt. `running` → poll. `failed` → stop, point at hPanel. If `website_type` is not `headless`
    (plain WordPress, Node.js, …), stop and tell the user — don't overwrite another kind of site.
-2. Create (only if **no** site exists): `hosting_websites_start-setup { order_id, type: "headless_ecommerce", domain }`
+2. Create (only if **no** site exists): `hosting_websites_create { order_id, type: "headless_ecommerce", domain }`
    — **omit `domain`** for a temporary subdomain: the setup generates one itself and returns it (don't
-   call a separate subdomain op first — there's no need in this flow; the API would also accept one you
-   generated via `hosting_domains_generate-free-subdomain`, valid 24 h from the client that made it). The
-   response carries the generated domain; if it differs from the workspace dir, move
+   call a separate subdomain op first — there's no need in this flow). The response carries the
+   generated domain; if it differs from the workspace dir, move
    `~/.hostinger/<old>/` → `<new>/` (if `<new>/` already exists, stop and ask instead of moving
    into it) and update `brief.md`. Poll `list-setups` to `completed`. `website_type` will be `headless`.
 
@@ -63,7 +62,7 @@ Same lifecycle as `../wordpress/SKILL.md` Steps 1–2, but `type: "headless_ecom
 > typically created in onboarding), **adopt it as the storefront host and skip the create.** A
 > `headless_ecommerce` website installs no store engine either, so an empty headless shell *is* the host
 > you need — there is no backend to "swap" on the website side. Record its `username`/`order_id` and go
-> straight to Step 2 (store + custom sales channel). Never call `start-setup` on a domain that already
+> straight to Step 2 (store + custom sales channel). Never call `hosting_websites_create` on a domain that already
 > has a site.
 
 > Don't expect `/cms` or any API on this domain — it serves the storefront you build (Step 6) and

package/skills/headless/steps/03-provision/webapp/SKILL.md

@@ -15,7 +15,7 @@ frontend step builds into and the deploy step ships to as a Node.js application.
 
 All website/database operations below go through the Hostinger connector (`execute`).
 
-> **Fire vs join (background provision).** Steps 1–2 up to `hosting_websites_start-setup` are the
+> **Fire vs join (background provision).** Steps 1–2 up to `hosting_websites_create` are the
 > **fire** half: once the setup is queued, record `provision.in_progress` and return to do prepare work
 > (see the router `../SKILL.md`). The readiness **poll** at the end of Step 2, plus Steps 3–5, are the
 > **join** half — run them when an instance-barrier step needs the backend (or immediately, if the
@@ -29,7 +29,7 @@ All website/database operations below go through the Hostinger connector (`execu
 2. `hosting_websites_list-setups { "domain": "<domain>" }` — exact-match the row:
    - `completed` → already provisioned → skip to Step 3 (adopt it).
    - `running` → skip to Step 2 (poll).
-   - `failed` → tell the user and point them at hPanel; do **not** call start-setup again on your own.
+   - `failed` → tell the user and point them at hPanel; do **not** call `hosting_websites_create` again on your own.
 3. If the site exists but is a different kind (`website_type` is `headless`, or a WordPress/store site),
    stop and tell the user — this domain already hosts something else. **Never create a second site.**
 4. **Only provision a webapp for a `webapp` brief.** A `wordpress` or `ecommerce` brief belongs in those
@@ -46,16 +46,15 @@ All website/database operations below go through the Hostinger connector (`execu
 2. Start the setup as an **empty website** — **omit `type`** (no WordPress, no store):
 
    ```json
-   { "operation": "hosting_websites_start-setup",
+   { "operation": "hosting_websites_create",
      "params": { "order_id": <order_id>, "domain": "<domain>" } }
    ```
 
    `domain` must be a **customer-owned** domain. For a temporary `*.hostingersite.com` subdomain,
    **omit `domain`** — the setup generates one itself and returns it in the response. Don't call a
-   separate subdomain op to make one first: there's no need in this flow. (The API would also accept a
-   subdomain you generated via `hosting_domains_generate-free-subdomain`, valid for 24 h from the client
-   that made it — this flow just doesn't use that.) The response then carries the generated domain: if it
-   differs from the workspace directory name, move `~/.hostinger/<old>/` to `~/.hostinger/<new>/`
+   separate subdomain op to make one first: there's no need in this flow. The response then carries the
+   generated domain: if it differs from the workspace directory name, move `~/.hostinger/<old>/` to
+   `~/.hostinger/<new>/`
    (if `<new>/` already exists, stop and ask instead of moving into it),
    update the domain in `brief.md`, and tell the user the new domain.
 3. Poll `hosting_websites_list-setups { "domain": "<domain>" }` every ~15 s until `completed`

package/skills/headless/steps/03-provision/wordpress/SKILL.md

@@ -19,7 +19,7 @@ adapter, site marked `headless`. **Out:** `site.json`.
 
 All operations below go through the Hostinger connector (`execute`).
 
-> **Fire vs join (background provision).** Step 1, plus the queuing call — `hosting_websites_start-setup`
+> **Fire vs join (background provision).** Step 1, plus the queuing call — `hosting_websites_create`
 > for a fresh site (Step 2) **or** `wordpress_installations_install` to swap an empty headless shell
 > (Step 2b) — are the **fire** half: once the job is queued, record `provision.in_progress` and return
 > to do prepare work (see the router `../SKILL.md`). The readiness **poll** at the end of Step 2 / 2b,
@@ -38,12 +38,12 @@ All operations below go through the Hostinger connector (`execute`).
    (see the router's *Onboarding handoff*): check `hosting_websites_list-setups { "domain": "<domain>" }`
    (exact row) and `wordpress_installations_list { username, domain, ownership: "all" }` (exact row):
    - Setup `running` → provisioning is underway → skip to Step 2's poll.
-   - Setup `failed` → tell the user and point them at hPanel; do **not** call start-setup again yourself.
+   - Setup `failed` → tell the user and point them at hPanel; do **not** call `hosting_websites_create` again yourself.
    - A WordPress install with `directory: "cms"` already present (or setup `type: headless_wordpress`)
      → **already provisioned** → skip to Step 3 (adopt it).
    - A `headless` site with **no** `/cms` install (an **empty headless shell** — setup
      `type: headless_empty`, typically from onboarding) → **swap it to WordPress** (Step 2b). Do **not**
-     call `start-setup` again — the website already exists; you only install WordPress into it.
+     call `hosting_websites_create` again — the website already exists; you only install WordPress into it.
 
 ## Step 2 — Create a fresh headless WordPress site (only when no site exists)
 
@@ -52,16 +52,15 @@ All operations below go through the Hostinger connector (`execute`).
 2. Start the setup:
 
    ```json
-   { "operation": "hosting_websites_start-setup",
+   { "operation": "hosting_websites_create",
      "params": { "order_id": <order_id>, "type": "headless_wordpress", "domain": "<domain>" } }
    ```
 
    `domain` must be a **customer-owned** domain. For a temporary `*.hostingersite.com` subdomain,
    **omit `domain`** — the setup generates one itself and returns it in the response. Don't call a
-   separate subdomain op to make one first: there's no need in this flow. (The API would also accept a
-   subdomain you generated via `hosting_domains_generate-free-subdomain`, valid for 24 h from the client
-   that made it — this flow just doesn't use that.) The response then carries the generated domain:
-   if it differs from the workspace directory name, move `~/.hostinger/<old>/` to `~/.hostinger/<new>/`
+   separate subdomain op to make one first: there's no need in this flow. The response then carries the
+   generated domain: if it differs from the workspace directory name, move `~/.hostinger/<old>/` to
+   `~/.hostinger/<new>/`
    (if `<new>/` already exists, stop and ask instead of moving into it),
    update the domain in `brief.md`, and tell the user the new domain.
    Admin credentials are generated by the platform; never ask the user for a password.
@@ -70,7 +69,7 @@ All operations below go through the Hostinger connector (`execute`).
 
 ## Step 2b — Swap an empty headless shell to WordPress (only when onboarding already made the shell)
 
-The website already exists as an empty `headless` shell, so there is **no `start-setup`** here — you
+The website already exists as an empty `headless` shell, so there is **no `hosting_websites_create`** here — you
 install WordPress straight into its `/cms` directory. This is the onboarding handoff path.
 
 1. Use the shell's `username` and `order_id` from Step 1's row — no new order pick, no new website.