Purchase Domain

One document, three parts. Section numbers carry their part's letter, so every reference names the part it points into — §S2, §P3, §R4.2.

Before any API call, read Part R. It holds every endpoint, product ID, URL template, site-resolution rule and error rule used by both of the other parts. Do not guess a URL or a field name — look it up there.

Part S — Search

Part S takes a request to buy a domain to the point where one chosen domain is known to be buyable, then goes to §P1. Covers US-03 – US-12 for the purchase path.

The user wants to buy, register or get a domain, or ideas for one. Typical openers: "buy me a domain", "I want to purchase a domain", "get me mybusiness.com", "I need a domain for my pancakes restaurant".

⛔ Availability checks are never done by this recipe. Every check of whether a domain is available goes through Check Domain Availability. Read that skill, run the check as it describes, then come back with the result: §R4.1 maps it. Never call the availability endpoints from this recipe.

The limits on a taken domain — no WHOIS, no owner, no broker or valuation advice — are Connect Domain §A1.1, and they hold here too.

UX rule for everything below: keep it natural, never expose internal mechanics, and reveal information only when it changes what the user has to do next. See §R9.

S1. Do We Have a Domain? (US-03, US-04)

Take the first row that matches, reading top-down. A domain the user named wins over everything else in this table — including a site they named in the same breath.

The user answering with a description rather than a domain ("Something with 'cozycuts' in it") is normal — treat it as a query and go to §S3.

⚠️ A named domain is checked before anything else happens, and the answer is the first thing the user hears. No site resolution, no fetching list of sites, no plan check and no list of sites comes in front of it. "I want to buy mybakery.com for my Wix site" names a site, and the site waits its turn: the check runs, the user is told "mybakery.com is available!" or "mybakery.com is already registered.", and only then does §P1 resolve the site. Asking which of ninety-three sites to use before saying whether the domain can even be bought answers a question the user has not reached yet.

S1.2 The User Pointed at a Site but Named No Domain

This section is only for a message that named no domain, with PURCHASE intent. A user who has a domain to connect goes to Connect Domain instead. If a domain was named as well — "buy mybakery.com for my wix site" — §S1's named-domain row owns it: the check runs first, and the site is resolved afterwards by §P1. Resolving a site here would put a list in front of the availability answer.

"I want a domain for my wix site" names no domain, and it is not nothing. Two things arrive with it, and the old reading of this row threw both away:

• The site question is already answered. They want the domain on a site, so §R3's Case D question — "Would you like to connect this domain to one of your Wix sites?" — must not be asked. Asking it back is asking them to repeat themselves.
• The site's name is brand context. §S3 takes free text, and a site called Green Sprout Bakery is exactly the query it wants. Never make the user type a business name the account already knows.

So resolve the site now, before the domain, and let it do both jobs:

Copy when a single site is resolved — §S3's list with its own opening:

⚠️ A site name is not always a business name. Auto-generated names (Evl 99faa20b7b2b, My Site 3, a bare hex string) and placeholders carry no brand signal, and querying §S3 on one returns noise. When the name has no real words in it, treat it as no context: keep the resolved siteId, then ask "What domain do you have in mind?" — the site still gets used for the plan check and the auto-connect line, just not for suggestions.

⚠️ This is the one place the purchase path resolves a site before the domain, and only because the user put the site in the request. §P1.1's rule — do not fetch list of sites unless the user asked about a site — is satisfied here, not bypassed. Carry the resolved siteId into §P1; the site is already settled, so the plan check is the next step and the question is never re-asked.

S2. The Domain Is Available (US-08)

Say, verbatim:

Then:

• Now go to §P1 and follow it. If a siteId is already in context, do not send "…is available!" on its own — continue straight into the site + plan outcome (§P1) in the same message.

When no siteId is in context but the user did ask for a site, the availability answer and §P1's site question belong in the same message — the answer first, the question behind it:

One turn instead of two, and the ordering is still answer-then-question.

⚠️ Suppressing the standalone line is a merge, never a deletion. The user is told in plain language that the domain can be bought — exactly once, in the first message that follows the check. Both continuations carry it, and the merged forms live in §P1.3a and §P2.3, Premium and Free respectively. If you are about to send a message that offers a plan, a price or a bundle and the user has not yet heard "{displayName} is available!", the line was dropped rather than merged. Say it.

S3. Suggestions (US-04, US-05, US-06)

First page — exactly 3

Always paging.limit=3. Three options is the contract — never dump ten.

Query construction:

Keep the query short — roughly 12–15 characters works best. Drop filler words (thebestflowershopintown → bestflowers), collapse repetition (gevageva… → geva), abbreviate (professional → pro).

Present them as a plain bulleted list of suggestions[].domain, then invite both a pick and more:

When the suggestions come from business context rather than a typed domain, open with "Here are a few available options based on your business name:" instead.

Rules:

• Every suggestion returned is already available. Never re-check one. (US-06)
• Never show a "premium" column or flag premium suggestions.
• If the user stated a TLD preference, call out the fitting ones (.com general, .shop / .store e-commerce, .me personal branding).
• No suggestions returned → ask the user for different or broader keywords.

"Show more" (US-05)

Offer more only when pagingMetadata.hasNext is true. To actually fetch them, repeat the same query and paging.limit=3 and add paging.cursor={pagingMetadata.cursors.next} from the previous response. hasNext alone does not page — without the cursor you get page 1 again.

Repeat with each new cursor for as long as the user keeps asking.

After a pick

The picked domain is the chosen domain. Do not check its availability.

Now go to §P1 and follow it. A user who came from a connect request is now picking a domain to buy: treat it as a purchase.

S4. Unsupported TLD (US-10, US-11)

Detected as an HTTP 400 body with details.applicationError.code === "DOMAINS_UNSUPPORTED_TLD" — there is no availability object on this response. See §R4.1.

Fetch 3 alternatives with the SLD only as the query (§S3) and show them in the same message:

User picks one → skip the availability check → Now go to §P1 and follow it.

A user who wanted to connect that domain, not buy one, is answered by Connect Domain §A6b.

Part P — Purchase Path

Entry preconditions — you arrive here from Part S, or from Connect Domain, with:

1. A single chosen domain, already normalized, and
2. Confirmation it is buyable — either available: true from the availability check, or it came from the suggest endpoint (suggestions are always available, never re-check one).

If either is missing, go back to §S1–§S4 and settle it first.

Terminal states — this path ends in exactly one of:

Read Part R before any call. Endpoints, product IDs and URL templates all live there.

Covers US-18 – US-32.

P1. Site and Plan Outcome (US-18, US-19)

P1.1 Resolve the site

Domain purchase does not require a Wix site. Apply the site-resolution rules in §R3 — Case A (siteId in context), Case B (logged in → fetch list of sites), Case C (not logged in → inline login prompt), Case D (logged in, ask once).

Do not fetch list of sites unless the user asked about a site or answered yes to the question.

• No site resolved → skip §P1.2 and §P2 entirely. No premium check, no voucher check, no upgrade pitch. Go to §P3 as a standalone purchase.
• Site resolved → keep siteId and the site's display name; go to §P1.2.

P1.2 Check the site's plan

Read payload.premiumState. allowedDomain = premiumState !== "FREE".

Do this silently. Record whether the site was Premium or Free here — §P7 compares against it.

P1.3a Premium site (US-18)

Say, verbatim:

When the site was already known from context — which is exactly when §S2 suppressed the standalone "is available!" line — merge the two into one message:

Go to §P3.

P1.3b Free-tier site → §P2.

P2. Free-Tier Offer (US-19, US-20, US-21, US-22, US-23)

The site exists but has no Premium plan. The user gets a real choice: upgrade and take the domain as part of the plan, or buy the domain on its own.

P2.1 Is the TLD coupon-eligible? (US-20)

The "free for the first year" promise is TLD-dependent — never promise it blindly.

coupons_applicable: true → eligible. Anything else → not eligible. If the call is unavailable, fall back to the static TLD list in §R7.

P2.2 Is a Premium plan on sale? (US-21)

The getPremiumSale context call (wix.premium.store.v1.sales/GetSale) runs automatically.

• Returns saleDetails with data → a sale is active. Useful fields: saleDiscount, saleEndDate, remainingDays.
• Returns empty / no saleDetails → no sale. Say nothing about sales.

P2.3 Present the offer

If a siteId was in context, this message owes the user the availability line. §S2 held back the standalone "{displayName} is available!" so it could be merged into the site + plan outcome, and this is the branch that merges it — §P1.3a does the same job on a Premium site. Lead with it and let the rest of the copy stand:

The not coupon-eligible variant takes the same opener. The just-logged-in variant does not — that user came through the login prompt, which only ever appears after "is available!" has already gone out on its own.

Coupon-eligible TLD — verbatim:

Not coupon-eligible — the free-year clause would be false, so drop that clause and keep the rest:

If a sale is active, append one line to whichever version you used:

If the user just logged in or created an account in response to the connect prompt (§R3 Case C), they have already said yes to connecting. Skip the question and deliver the offer with the link in the same message — the connect constraint still gets stated:

P2.4 User accepts the bundle (US-23)

Use the full domain in domainName, the resolved siteId in siteGuid. When the TLD is not coupon-eligible, use the label [Get your site live at this domain] instead — do not promise a free year.

This is a terminal state. Stop here. Do not continue to §P3, do not build a cart.

P2.5 User declines the bundle (US-22)

Reply "No problem." and continue to §P3 as a standalone purchase. Do not re-pitch the upgrade.

Do not restate the connect constraint here either. §P2.3 put it in front of the choice, which is where it changes a decision. Repeating it after the user has decided is a second pitch wearing a warning's clothes.

Keep the siteId in memory — §P7 re-checks the plan, and the user may upgrade in another tab. But treat the purchase as standalone for now: no msid on the checkout link unless §P7 changes it.

P3. Registration Period (US-24)

Include the leading dot in tld.

• Save products[0].productId — the cart needs it in §P8. Never hardcode it.
• Render every entry in products[0].pricingDetails[] as a table, and only those entries.

Valid cycles are a subset of 1, 2, 3, 5 and 10 years, and the subset varies by TLD — some start at 2, some stop at 3, some go to 10. Do not add a row the API did not return, and do not drop one it did.

Sort the rows ascending by cycle.cycleDuration.count. The API does not return them in order — .org and .biz both come back 10, 5, 2, 3, 1. Rendering the array order gives the user a jumbled table.

Which fields — exactly three per row

Each pricingDetails[] entry carries several price objects. Read these and no others:

Always formattedAmount — it arrives with the currency symbol and the right number of decimals. Never take amount and format it yourself, and never do arithmetic on either.

renewalPrice.total is the charge for the same period again — for a 2-year row it is the next 2-year charge, not a yearly rate. The header wording is what carries that; if it ever proves confusing, fix the header, do not add a footnote after the table.

⛔ Do not read these, all of which are in the same response and all of which will produce a wrong or unexplainable number: catalogPrice (the undiscounted list price — showing it next to "You pay now" invents a discount claim), initialPurchasePrice (identical to finalPrice.total in every row observed — if it ever differs, that is new information to check, not a free choice), lowestCyclePrice (its name and its value are consistent with two different meanings in the data observed, so it is unverified), and any monthly* or subtotal* variant. savings appears on some rows and not others — never render it.

Message shape — one row per returned pricingDetails[] entry and no other rows:

(Open with "No problem." only when the user has just declined a site or a bundle. Otherwise open with "How many years would you like to register it for?".)

That closing line is fixed and it is required — this is the first place the user sees a price, and every message that shows one carries it. Wording and the full rule: §R10.

Ask the user to pick. If they have no preference, default to the shortest available period.

⛔ Never invent a price

Every number in that table comes from this response and this response only. There is no fallback price list anywhere in this skill or in your own knowledge. A .com does not have a price you already know.

That last row is the one that bites. When the offering call is unavailable, the tempting move is to show a plausible table and carry on — a fabricated price the user may act on. A missing price ends the flow; it never gets filled in from memory.

If you find yourself about to write $7.90, $14.95, or any other specific figure that did not arrive in an API response during this conversation, you are hallucinating pricing. Stop.

P4. Contact Details (US-27, US-28)

Address fields are flat on each contact — streetAddress, city, country, postalCode. There is no nested address object.

P4.1 Contacts exist (US-27)

Show them and ask for explicit confirmation. Never skip this — never assume.

• Confirmed → §P5.
• Wants different details → collect as in §P4.2.

P4.2 No contacts (US-28)

Ask for every field, one per line:

Field rules:

• Phone — +{countryCode}.{number}, e.g. +1.5551234567, +972.533456789.
• Country — accept a full name and convert to the 2-letter ISO code before saving ("Israel" → IL, "United States" → US).

The user may answer in a single line ("Alex Johnson, alex@cozycuts.com, +1.5032218800, 310 Oak Ave, Portland, US, 97201") — parse it, do not make them re-enter field by field.

P5. Save Contacts (US-29)

Do this immediately once contacts are confirmed or collected — before asking about privacy — so validation problems surface while the user is still thinking about their details.

Generate a random UUID as sessionId (wsess). It links the contacts to the cart; keep it, §P8 needs the same value.

Use the same contact for registrant, admin and tech — standard for individual registrations.

Validation errors (US-29)

Name only the fields that are actually wrong, in plain language. Never show the raw error, a field path, or a code.

Take the correction, retry the upsert, and carry on. Some TLDs need extra fields — .com.br an identification number, .it an entity type. If the error is about a TLD-specific requirement, explain what is needed and ask for it.

On success, go to §P6.

P6. Privacy Protection (US-25, US-26)

The options come from the offering call with the addon product type (§R4.2), scoped to the domain's TLD — the same body shape as §P3, leading dot included:

⛔ Never call it without the tld. The paid addons vary by TLD — .com.au, .com.br, .info and .biz, for example, have no Privacy + DNSSEC. An unscoped answer is not an answer for this domain.

Match each entry in products[] by its ID against the product-ID table at the end of this section. Offer only the paid addons whose IDs came back. "No protection" is always offered.

⛔ Never put an addon product ID in the cart that this TLD-scoped call did not return. An addon the response left out is not offered at all — not without a price, not as "recommended", not on request. Checkout rejects it (MissingDomainBundleMetadata) and the user is left with a cart that cannot be paid.

The addon response has the same shape as §P3's — one pricingDetails[] entry per cycle, with finalPrice and renewalPrice on each. The registration period is already chosen by the time you get here, so read the row whose cycle.cycleDuration.count matches the chosen term and take finalPrice.total.formattedAmount from it. Never sum, never divide, never take the 1-year row and multiply.

Message shape — one line per option the response allows, built from the table above. The full form, when both paid addons came back:

When Privacy + DNSSEC did not come back, its line is gone and Privacy only takes the recommendation:

The currency note is required here too (§R10). It qualifies the {price} figures and not "Free" — free is not a currency amount. So it appears only when at least one priced option is shown; a message with no price in it carries no note.

{price} carries the term, and the term is whatever the user picked:

⛔ /yr on a multi-year term is wrong here for the same reason it is wrong in §P9. The addon figure is the charge for the whole period — verified live: Privacy + DNSSEC comes back $12.90 for the 1-year cycle and $38.70 for the 3-year one. Writing "$38.70/yr" triples the price in the user's head. (Those two figures illustrate the shape and are never printed to a user — §P9's closing rule.)

{price} is whatever the addon offering call returned for that product ID. "No protection" is the only one whose price is known ahead of time — it is Free. A paid addon is shown only because the response returned it, so its price comes from that same entry. If a returned addon has no row for the chosen term, do not offer it. The same rule as §P3 applies — a figure you did not receive in this conversation is a fabrication, and the wording above is a template, not a price list.

Addon product type for all three: b3d86a1d-9db3-4f69-bd54-c132808856b1.

The user may pick any option shown (US-26) — recommend, never push. "No protection" is a legitimate answer; accept it without a warning.

P7. Pre-Cart Premium Re-Check (US-30)

Run this only when a siteId was resolved in §P1 and the site was Free at that point. Skip it for standalone purchases with no site, and for sites already Premium.

The user may have upgraded in another tab while answering the questions above. Re-check silently, just before building the cart:

When it flipped to Premium, add one line to the final message — after "Setting up your order..." and before the summary:

Never mention the check itself, and never mention it when nothing changed.

P8. Build the Cart (US-32)

Use CallWixSiteAPI (with siteId) when a site is in play, otherwise ManageWixSite. Both carry Wix session auth — add no headers.

Three calls, in order, silently:

1. Cancel the existing cart — POST https://manage.wix.com/_api/premium-cart/v1/carts/active/cancel · Body {} Succeeds even when there is no active cart. This is what stops leftovers from an earlier session ending up in the user's order.
2. Get a fresh cart — GET https://manage.wix.com/_api/premium-cart/v1/carts/active
3. Add items — PATCH https://manage.wix.com/_api/premium-cart/v1/carts/active/add-items

• The addon cycle duration must match the domain's.
• core: "true" goes on the domain line item only.
• Include the addon line item for whichever option the user picked in §P6, including "No protection" — it is a product, not an absence. The one exception is an ID the TLD-scoped addon call did not return: that line item is left out, and so is the whole addon line when §P6 skipped the question.
• ⛔ Never add an addon product ID the TLD-scoped call in §P6 did not return — checkout fails on it.
• Never announce any of these three calls. The only thing the user sees is "Setting up your order...".

P9. Checkout Link (US-30, US-31)

Final message:

The currency note sits between the summary and the link, so the link is still the last thing in the message (§R10). This is the screen the user actually reads before paying, so it is the one place the note matters most.

For "No protection", the second line reads - **No protection** — Free. It has no renewal clause — $0.00 does not renew at anything worth saying. When the cart has no addon line item (§P8), the summary has no second line.

The renewal clause — two forms, and only two

renewalPrice.total is the charge for the same period again, not a yearly rate. So the suffix depends on the term:

⛔ Never write /yr on a multi-year term. For a 3-year .biz the renewal figure is $107.50 — the next three-year charge. "renews at $107.50/yr" overstates it threefold. This is the single most likely way to get this section wrong, and it is wrong in the direction that scares a user off a purchase they were about to complete.

Where the two figures come from

Both are the ones §P3 already fetched for the chosen cycle — finalPrice.total.formattedAmount and renewalPrice.total.formattedAmount from the pricingDetails[] row the user picked. Reuse them:

• Never re-request. The offering call already ran; calling it again is a second chance to get a different answer.
• Never recompute. §P3's ban on arithmetic holds here — no dividing a 3-year renewal by three, no multiplying a 1-year figure up.
• Never estimate. If §P3 rendered a blank renewal cell for the chosen row, the summary line drops the clause entirely and shows the price alone. A blank stays blank; it does not get filled in at checkout time.

The privacy addon line

The addon carries renewalPrice too — verified live against the addon product type (b3d86a1d-9db3-4f69-bd54-c132808856b1), same pricingDetails[] shape as the domain, one row per cycle. So the addon line gets the same treatment as the domain line: same two term forms, same prohibition on /yr for a multi-year term, same reuse rule (§P6 already read the row for the chosen cycle).

One observed difference, and it is not a reason to change the shape: on all three addon products the renewal figure equals the first-term figure — Privacy + DNSSEC is $12.90 now and $12.90 at renewal, Privacy only $9.90 and $9.90. Unlike the domain, the addon has no introductory discount. Print the clause anyway. "$12.90 (renews at $12.90/yr)" is the useful answer to "does this one jump too?", and suppressing it whenever the numbers match would make its absence look like missing data rather than a flat price.

⛔ Every figure in this section is an observation about shape, not a price. $107.50, $12.90, $9.90, $7.90, $35.90 — all of them are here to show which period a number covers and how far a renewal can step. None of them is ever printed to a user. §P3's rule is the whole rule: a figure that did not arrive in an API response during this conversation is a fabrication, and that applies to numbers read out of this document exactly as it applies to numbers read out of your own knowledge.

The user's only remaining step is payment; say nothing more.

Terminal state. Stop here.

P10. Forbidden Actions

❌ Never:

• Promise "free for the first year" without confirming coupon eligibility (§P2.1).
• Present the Free-tier choice without the connect constraint. "Want a bundle link?" on its own is an upsell; the same question with "connecting a domain requires one" in front of it is a decision. US-19 asks for the second. Both §P2.3 variants carry the clause, including the just-logged-in one.
• State a renewal figure per year for a multi-year term. renewalPrice.total is the charge for the same period again — /yr belongs on a 1-year term and nowhere else (§P3, §P6, §P9).
• Mention a sale that getPremiumSale did not report.
• Skip the contact confirmation in §P4.1 because the details "look right".
• Continue to §P3 after the user accepted a bundle link — that is the end of the flow.
• Put msid on a standalone checkout link, or leave it off when a Premium site is attached.
• Re-check availability for a domain that came from the suggest endpoint.
• Offer, recommend or add to the cart a paid addon the TLD-scoped addon call did not return (§P6).
• Narrate cart operations, contact saving, or the premium re-check.

✅ Always:

• Render exactly the cycles the offering call returned.
• Carry the currency note in the same message as any price the user sees — §P3, §P6 and §P9. Fixed wording, and never a currency name or a conversion (§R10).
• Show what the domain renews at wherever its price appears — the period table (§P3) and the pre-checkout summary (§P9). Same two figures, fetched once.
• Reuse the same wsess across the intent save and both cart line items.
• Keep siteId from §P1 through §P9.

Part R — Reference

Read this part before making any API call. It is the single source of truth for endpoints, product IDs, URL templates, site resolution and error handling. Parts S and P both defer to it — where they disagree with this part, this part wins.

Covers US-13, US-14, US-15, US-16, US-37, US-38, US-39.

A taken domain (US-09, US-40, US-41) is answered by Connect Domain §A4b, which looks it up in the user's account. US-42 – US-46 (putting a domain the account holds on a site, changing its role, moving it) are Assign Domain's. This skill never writes to a user's site.

R1. Domain Normalization

Apply before any API call, every time a domain is read from the user:

• Strip http:// and https://
• Strip www.
• Strip any trailing path, query string or slash (example.com/shop → example.com)
• Lowercase
• If there is no TLD, add .com (example → example.com)

The normalized value is {domain} everywhere below. Always use the full domain in URLs and API calls — never the truncated display form.

R2. Domain Display Truncation

Only the visible label is ever truncated. Two values exist for every domain:

Rule: if the full domain is 20 characters or fewer, displayName = domainName. If it is longer than 20 characters:

R3. Site Resolution

Both paths need to know which Wix site (siteId, also called msid) is in play. The rules are the same; when they run differs:

• Purchase path — a site is optional. Resolve only after the domain is chosen. See §P1.
• Connect path — a site is required. That path is Connect External Domain or Sub Domain, which resolves the site itself, after the availability check.

Case A — siteId already in context (US-13)

The system prompt, environment or dashboard context already provides a siteId / msid.

→ Use it directly. Do NOT fetch list of sites. Do not ask the user to pick a site.

Case B — user is logged in, no siteId in context

→ Fetch list of sites.

More than eight sites. A numbered wall of ninety-three is unusable, and a bare count is worse. Name the total, show five, and leave the door open:

Show the five most recently updated if the response gives you that; otherwise the first five it returned. A name in reply is matched against the whole result you already have — do not fetch list of sites a second time to look it up.

⛔ Never announce the count and stop. "You have 93 sites — would you like me to list them?" asks permission for the step you were already told to take. The user has asked for their domain on a site; the list is what moves that forward and a count moves nothing. It costs a turn and answers nothing.

Case C — user is not logged in (US-16)

Do not ask a yes/no question about sites — the user cannot answer it usefully. Show the optional inline prompt instead, verbatim:

• User logs in → go to Case B (fetch list of sites).
• User declines ("No, I'll just buy it for now") → standalone purchase, no siteId, no premium pitch, no voucher check. Reply "No problem." and continue.

The destination behind [Log in or create a Wix account] is supplied by the host channel's sign-up/login affordance. In a channel with no widget runtime, link to https://www.wix.com/.

Case D — user is logged in and no site was mentioned

Purchase path only. Ask once, verbatim:

• Yes → Case A or B.
• No → standalone purchase, no siteId. Reply "No problem." and continue.

Once a siteId is resolved, remember it for the rest of the conversation and reuse it in the premium check, the bundle link and the checkout link.

R4. API Reference

R4.1 Public — no auth

These are open endpoints. Send a plain GET with query parameters: no headers, no tokens, no scopes. If you get 403 / access_denied, you added auth that does not belong — remove it and retry.

Check domain availability — every check in this flow uses Check Domain Availability (request, response, errors); never call the endpoints from here. In this flow its results map as follows:

availability.premium is a pricing tier of the domain, not the Wix Premium plan of a site. Site Premium comes only from premiumStatus (§R4.2).

Suggest domains

Accepts free text — business descriptions, keywords and brand concepts, not just domain names.

Paging is cursor-based. pagingMetadata.hasNext tells you whether more exist; it does not fetch them. To get the next page, repeat the same query and paging.limit and add paging.cursor=<pagingMetadata.cursors.next>. Never re-issue the same request without the cursor — you will get the first page again.

Every returned suggestion is already available. Never re-check availability for a suggestion. Never show a "premium" column or flag premium suggestions.

R4.2 Authenticated

Use CallWixSiteAPI (with siteId) when a site is resolved, otherwise ManageWixSite. Both carry Wix session auth automatically — do not add headers.

Premium status: read payload.premiumState. allowedDomain = premiumState !== "FREE". allowedDomain: true → Premium site. allowedDomain: false → Free site.

The offering endpoint is the getDomainCycles call — the same one the production get-domain purchase flow uses. Noted for whoever next reconciles this skill against production; it changes nothing about how the call is made.

Both offering variants return the same envelope — products[].pricingDetails[], one entry per cycle, each carrying finalPrice and renewalPrice. Verified live for the domain type and the addon type alike. renewalPrice.total is always the charge for the same period again, never a yearly rate (see §R9).

R5. Product IDs

R6. URL Templates

Use these exactly. Do not invent variants, reorder into a different form, or drop parameters.

Notes:

• The bundle link is the premium-pricing/wix/select-plan form above. An older premium-domains/split-page?domainName=… form also exists — do not use it.
• The connect link and the Premium upgrade links are Connect External Domain or Sub Domain's (§10).

R7. Free-Domain-Coupon TLDs

Used by §P2 to decide whether the "free for the first year" benefit can be promised. Authoritative source is DomainTld/ListTlds → coupons_applicable: true. Use this static list only as a fallback when that call is unavailable:

.com, .com.au, .co.uk, .net, .org, .art, .at, .co.at, .be, .biz, .blog, .ca, .ch, .club, .coach, .com.br, .de, .fit, .fitness, .fr, .fun, .in, .co.in, .org.in, .firm.in, .gen.in, .ind.in, .net.in, .info, .live, .nl, .online, .pictures, .rocks, .site, .space, .shop, .store, .studio, .training, .work, .xyz, .yoga

Extract the TLD greedily from the right: site.co.uk → .co.uk, not .uk.

R8. Error Handling (US-37, US-38, US-39)

Silent retry (US-37)

Any failed call: retry once, silently. Say nothing to the user, before or after. Do not narrate "let me try that again", do not mention that anything failed. If the retry succeeds, continue as if nothing happened.

Escalation ladder

The fallback link appears at stage 2, not stage 1. Do not skip stage 1.

Specific errors

R9. Forbidden Actions

❌ Never:

• Expose internal mechanics — no API names, endpoint paths, tool names, error codes, HTTP status codes, field names, or phrases like "the request failed", "I'm calling the …", "saving to the intent API", "adding line items", "canceling the old cart".
• Narrate work in progress: "Let me check…", "I'll look that up…", "Verifying…", "Hold on…". The only permitted progress line is "Setting up your order..." at cart build.
• Invent a price, a cycle length, a suggestion, or a URL. Every price and cycle comes from the offering response; every suggestion comes from the suggest endpoint; every URL comes from §R6.
• Copy a number out of an example. Every worked example in this document uses {placeholder} braces for exactly this reason. A concrete figure appearing in a template, a transcript, or your own knowledge of what domains usually cost is not data — it is a fabrication with a currency symbol in front of it. If the call that supplies a price could not be made, the flow stops (§P3). It does not continue with a plausible guess.
• Attach a per-year period to a per-period price. Every figure in pricingDetails[] — finalPrice and renewalPrice alike, domain and addon alike — is the charge for one whole cycle. A 3-year row's $107.50 is one three-year charge. /yr is correct on a 1-year term and on nothing else; for anything longer the wording is "every {N} years" or "for {N} years" (§P6, §P9). This is arithmetic the user does in their head, and the error is always in the expensive direction.
• Divide or multiply a price to reach a per-year figure. The response carries monthlyTotal and lowestCyclePrice precisely because someone will be tempted; both are unverified in this skill and neither is a substitute for saying which period the price covers. Print the period, not a rate.
• Re-check availability for a domain that came from the suggest endpoint.
• Run an availability check without Check Domain Availability, or call its endpoints from this recipe.
• Use availability.premium for anything but the premium-domain row in §R4.1, or as the site's Premium status.
• Fetch list of sites when a siteId is already in context. A partial roster the host preloaded is not that — see Case A.
• Announce a site count instead of the sites. "You have 93 sites — want me to list them?" asks permission for a step already required. Show them (§R3 Case B) — all of them up to eight, otherwise five and an invitation to name one.
• Answer a taken domain, or look up whether a domain is the user's. Both are Connect Domain's (§A4b), and so is the "if it's yours" hedge.
• Check availability for a subdomain, or answer one here. A subdomain is not separately registrable; it goes straight to Connect External Domain or Sub Domain.
• Write to a user's site. Putting a domain on a site, changing its role, moving it and taking it off are all Assign Domain's; hand over and let it ask.
• Say "main address" for "primary domain" — or "main domain", "main URL", or any other paraphrase. Root domain is correct only for the domain a subdomain sits under, never for a site's primary domain.
• Step outside the skill's scope on a taken domain. No WHOIS or registrant lookup, no naming the owner, no aftermarket/broker/acquisition advice, no valuation, no trademark opinion, no web browsing. Full boundary: Connect Domain §A1.1.
• Use a tool this skill did not ask for. Having WHOIS, web search, or browsing available is not permission to use them. The information sources are the three in §R4 — that is the complete list.

✅ Always:

• Normalize the domain before every call.
• Reuse the resolved siteId for the rest of the conversation.
• Reveal information only when it changes what the user must do next.
• Say the currency note (§R10) in the same message as any price shown to the user — and never name a currency or convert between two.

R10. Currency at Checkout

Every price this skill shows comes from the offering call as formattedAmount, which arrives with its own currency symbol already attached (§P3). Checkout is a separate surface and may present the charge in the user's own currency, so the figure in the conversation and the figure at the till can differ in currency. The skill cannot tell in advance, so it says exactly that much and no more.

One fixed sentence covers it, and it is the only thing this skill ever says about currency:

It goes in the same message as the prices it qualifies, once, wherever a currency amount is shown to the user — the period table, the privacy options and the pre-checkout summary (§P3, §P6 and §P9). In the summary it sits above the checkout link, so the link stays last.

❌ Never:

• Name a currency, or convert between two. "That's about €7.30" invents a figure and does arithmetic on a price in one move — §R9 forbids both. The sentence hedges precisely because the skill does not know what the checkout will show.
• Reword it. No "approximate", no "excluding taxes", no "prices may vary", and no promise that the figure will be identical. It says what is known; everything else is invention.
• Send it twice in one message, or send it on its own with no price beside it.
• Attach it to "Free", to a percentage discount, or to the free-first-year clause (§P2.3). None of those is a currency amount, so there is nothing to localise.