Run JavaScript against the Wix REST API on site "CodeStringers" (https://www.codestringers.com/_api/mcp), on the visitor's behalf. The code runs in a sandbox and you get back whatever it returns.
PREFER THIS TOOL OVER CallWixSiteAPI. CallWixSiteAPI makes a single HTTP request; ExecuteWixAPI runs real code, so you can chain calls, paginate, filter, and shape the result in one step. Use ExecuteWixAPI for any Wix API work on this site, and fall back to CallWixSiteAPI only for a trivial one-shot read where code adds nothing.
DO A WHOLE RECIPE IN ONE CALL. When a task needs several requests — e.g. query to resolve an id, then mutate; create then confirm; read a list then act on a match — write ONE ExecuteWixAPI call whose code performs every step in sequence and returns the final result. Do NOT split a multi-request recipe into multiple separate tool calls; that wastes round-trips and loses intermediate state. If a recipe from the docs lists steps 1..N, the code should run steps 1..N.
CRITICAL CODE SHAPE:
- The `code` parameter MUST be the function expression itself: `async function() { ... }` or `async () => { ... }`.
- Do NOT send a script body like `const result = await ...; return result;`.
- Do NOT call the function yourself. The tool calls it for you.
- Put all `const`, `await`, and `return` statements inside the function body.
Do not rely on memory for Wix API endpoints, methods, schemas, or request bodies. Before writing code, use SearchSiteApiDocs (and ReadFullDocsArticle / ReadFullDocsMethodSchema) to confirm the exact API URL, HTTP method, request body structure, field names, required fields, and enum values. The URL usually starts with `https://www.wixapis.com`. Before reading fields off a response, know its exact shape — don't guess paths like `result.id` when it may be `result.results[0].item.id`. Pass every docs/recipe URL you relied on in the `sourceDocUrls` parameter.
Authentication: pass the `visitorToken` parameter (from GenerateVisitorToken; reuse the one already in your context, do not create a new one each call). Everything runs against this visitor site automatically — do NOT set `scope`, `siteId`, Authorization, wix-site-id, or wix-account-id.
File and export limits: ExecuteWixAPI is only for Wix REST API calls and in-memory data shaping. It does not provide Node.js built-in modules or filesystem access, and it cannot create downloadable files. Do not import `fs`, `path`, or `node:*`, write files, or promise a generated downloadable file from inside this tool. For large exports, return compact summaries or the specific fields needed for the answer; if the user needs a full downloadable CSV/JSON file, direct them to the product's native export flow or ask for a smaller filtered export.
Probing should be read-only: use GET/query/list/search to inspect state, resolve real ids, or verify a previous write. For create/update/delete, read the docs first and call the mutation only with real resolved inputs — no speculative mutations just to learn the response shape.
Error handling: `wix.request()` throws when the Wix API returns an error. For dependent steps, let it throw so the failure is reported clearly. For independent read-only probes you may wrap each in `try/catch` and return partial results; when running them in parallel use `Promise.allSettled` (not `Promise.all`) so one failure doesn't discard the rest.
Available in your code:
```typescript
interface WixRequestOptions {
method: "GET" | "POST" | "PUT" | "PATCH" | "DELETE";
url: string; // Full Wix API URL, e.g. "https://www.wixapis.com/stores-reader/v1/products/query"; paths starting with "/" resolve against https://www.wixapis.com
body?: unknown;
}
interface WixResponse<T = unknown> {
status: number;
data: T;
json(): Promise<T>; // Fetch-compatible alias for data
}
declare const wix: {
request<T = unknown>(options: WixRequestOptions): Promise<WixResponse<T>>;
};
```
Return compact, task-focused data instead of raw API responses. For list/query/search endpoints, paginate in code and map each item to just the fields the task needs. When the code CREATES entities (create, bulk create, import, duplicate, upload), ALWAYS include the ID of every created entity in the returned object — e.g. `{ cartId }` or `{ createdIds: [...] }` — even if the user did not ask for them; follow-up steps, verification, and cleanup all need those IDs, and recovering them later costs extra query calls.
Example — a multi-step recipe (resolve a product by name, then add it to the cart) done in ONE call:
```javascript
async function() {
// Step 1: find the product
const found = await wix.request({
method: "POST",
url: "https://www.wixapis.com/stores-reader/v1/products/query",
body: { query: { filter: JSON.stringify({ name: "Florie Eau de Parfum" }) } }
});
const product = found.data.products?.[0];
if (!product) return { error: "PRODUCT_NOT_FOUND" };
// Step 2: create a cart with that product
const cart = await wix.request({
method: "POST",
url: "https://www.wixapis.com/ecom/v1/carts/create-cart",
body: { cart: { lineItems: [{ catalogReference: {
appId: "215238eb-22a5-4c36-9e7b-e7c08025e04e",
catalogItemId: product.id
}, quantity: 1 }] } }
});
return { cartId: cart.data.cart?.id, productId: product.id, name: product.name };
}
```
