Wix Docs — consulter la documentation de l'API/SDK Wix

Obtiens la vérité exacte sur une API Wix — endpoint, méthode HTTP, corps de la requête/réponse, un champ, une énumération, ou une erreur. Ne jamais inventer un endpoint, chemin, corps ou énumération Wix de mémoire — confirme-le d'abord ici.

Une recherche suit un flux court : trouve la bonne page, puis lis-la. Fais-le avec curl (par défaut, ci-dessous) ou les outils MCP Wix doc si ton agent les a (Lane 2).

Lane 1 — curl (par défaut)

La documentation est un arbre de pages markdown : ajoute .md à n'importe quelle URL https://dev.wix.com/docs/… pour obtenir cette page en markdown. Pas de SDK, pas de MCP.

1. Trouve la page — cherche, parcours ou interroge l'index

Trois façons d'atteindre la bonne page — utilise celle qui convient.

A. Recherche sémantique. Décris ce que tu veux en langage naturel (« laisser un client réserver un rendez-vous »), pas juste des mots-clés ; les résultats reviennent classés par pertinence, chacun avec une url de docs. Deux variantes — ajoute /markdown pour la deuxième :

Même corps JSON : search_term (requis, 1–500), document_type (REST par défaut · SDK · WIX_HEADLESS · BUSINESS_SOLUTIONS · VELO · WDS · BUILD_APPS · CLI), maximum_results (1–20, def 15), lines_in_each_result (1–200, def 20).

# markdown — passe directement au modèle ; supprime /markdown pour JSON et analyse result[].url
curl -sS -X POST 'https://www.wixapis.com/mcp-docs-search/v1/docs/search/markdown' \
  -H 'Content-Type: application/json' \
  --data-raw '{"search_term":"create a booking","document_type":"REST","maximum_results":3}'

B. Parcours l'arbre à partir de la racine, comme un menu. Chaque chemin docs a un jumeau .md, tu peux donc naviguer dans la documentation comme un arbre de menu — pas besoin de chercher. curl https://dev.wix.com/docs/llms.txt est la carte de haut niveau ; les portails en dessous :

Explore comme un menu — ajoute .md à n'importe quel chemin (une section → un menu de liens enfants, une feuille → la page de contenu/méthode) ; tronque pour remonter, étends pour descendre. Lis aussi les articles intro / « À propos de… » / flux des voisins, pas juste la page de méthode. Exemple — explore jusqu'à la méthode create-booking, en grepant chaque menu pour le lien suivant :

curl -sS https://dev.wix.com/docs/api-reference/business-solutions.md            | grep -i bookings   # → .../bookings.md
curl -sS https://dev.wix.com/docs/api-reference/business-solutions/bookings.md   | grep -iE 'bookings|flow'  # → resource/flow pages
curl -sS https://dev.wix.com/docs/api-reference/business-solutions/bookings/bookings.md | grep -i create      # → la feuille de méthode create
curl -sS https://dev.wix.com/docs/api-reference/business-solutions/bookings/bookings/bookings-writer-v2/create-booking.md  # lis-la

Une carte 2 niveaux du portail API-reference (tous les verticaux, un niveau en bas) est dans references/EXTRACTING.md.

C. Interroge l'index API — un appel, structuré. Le endpoint de recherche code-mode exécute une fonction JS sur lightIndex (la spec API REST entière : chaque ressource + méthode avec operationId, httpMethod, menuPath, docsUrl, et publicUrl exécutable). Meilleur quand tu veux énumérer/filtrer des méthodes par programmation — parcourir un vertical, ou grep sur toutes les méthodes — et récupérer docsUrl + publicUrl en un coup, pas de navigation menu :

# cible une méthode par mot-clé sur tout l'index → son docsUrl + publicUrl exécutable
curl -sS -X POST 'https://mcp.wix.com/api/code-mode/search' -H 'Content-Type: application/json' \
  --data-raw '{"code":"async function(){ return lightIndex.flatMap(r=>r.methods).filter(m=>/createBooking$/i.test(m.operationId)).map(m=>({op:m.operationId, httpMethod:m.httpMethod, publicUrl:m.publicUrl, docsUrl:m.docsUrl})); }"}'

Filtre étroitement et retourne seulement les champs dont tu as besoin — l'index est large, donc un dump non filtré est énorme. Champ : méthodes API REST uniquement (pas articles concept/guide, prose headless, ou surfaces SDK uniquement — utilise A/B pour ceux-là). Plus d'exemples (parcourir un vertical entier, marche menuPath, schéma de ressource entière) et le lecteur getResourceSchema → references/API_SPEC_SEARCH.md.

Si le MCP Wix est présent, il expose ces mêmes capacités comme outils natifs (pas de boilerplate curl/JSON) — Lane 2.

2. Lis ce sur quoi tu atterris

Ajouter .md à une URL donne l'une de trois sortes de pages. Sache laquelle tu lis, et gère-la en conséquence :

• Page menu — un chemin de section (depuis la navigation, §1B). Une liste de liens enfants, souvent des dizaines de KB — ne la lis pas entièrement ; grep-la pour l'enfant que tu veux, puis explore cette page :

  curl -sS 'https://dev.wix.com/docs/api-reference/business-solutions/bookings.md' | grep -i 'booking'

• Article / guide — introductions, concepts, pages de flux exemple. Prose markdown, généralement petit — lis-la entièrement :

  curl -sS 'https://dev.wix.com/docs/api-reference/business-solutions/bookings/bookings/introduction.md'

• Page de méthode — une méthode API, et la lourde : elle porte à la fois une section REST et une section SDK JavaScript, le schéma complet requête/réponse, et des exemples de code — souvent 100 KB+. N'avale pas la page entière — carte-la, puis tire la partie dont tu as besoin (les exemples suffisent généralement pour modéliser un appel) :

  curl -sS "$URL.md" | grep -nE '^#{1,3} '                                              # 1. carte le plan
  curl -sS "$URL.md" | awk '/^## REST API/{r=1} r&&/^### Examples/{f=1} /^## JavaScript SDK/{f=0} f'  # 2. juste les exemples REST
  curl -sS "$URL.md" | grep -nE 'name: (selectedPaymentOption|totalParticipants)'       # 3. grep les champs de schéma spécifiques

  Plus de recettes (séparer REST vs SDK, résoudre une énumération) → references/EXTRACTING.md.

  Pour le schéma structuré exact et les valeurs d'énumération, ne découpe pas manuellement le markdown — interroge la spec API avec un curl POST à https://mcp.wix.com/api/code-mode/search (l'équivalent sans MCP du MCP SearchWixAPISpec). Le code est une fonction JS avec lightIndex et getResourceSchemaByUrl(docsUrl) en portée ; retourne seulement ce dont tu as besoin :

  # trouve une méthode par mot-clé → son docsUrl + publicUrl exécutable
  curl -sS -X POST 'https://mcp.wix.com/api/code-mode/search' -H 'Content-Type: application/json' \
    --data-raw '{"code":"async function(){ return lightIndex.flatMap(r=>r.methods).filter(m=>/createBooking$/i.test(m.operationId)).map(m=>({op:m.operationId, httpMethod:m.httpMethod, publicUrl:m.publicUrl, docsUrl:m.docsUrl})); }"}'
  
  # tire le schéma requête/réponse d'une méthode par son docsUrl (résous les refs $circular via s.components.schemas)
  curl -sS -X POST 'https://mcp.wix.com/api/code-mode/search' -H 'Content-Type: application/json' \
    --data-raw '{"code":"async function(){ const u=\"https://dev.wix.com/docs/api-reference/business-solutions/bookings/bookings/bookings-writer-v2/create-booking\"; const s=await getResourceSchemaByUrl(u); const m=s.methods.find(x=>x.docsUrl===u); return { publicUrl:m.publicUrl, requestBody:m.requestBody, responses:m.responses }; }"}'

  Ensemble d'exemples complet (listage de ressources, résolution d'URL partielle, expansion énumération/refs imbriquées) → references/API_SPEC_SEARCH.md.

Lane 2 — Outils MCP Wix doc (seulement si ton agent les a)

Si le MCP Wix est connecté, ceux-ci sont les mêmes backends que Lane 1 (le service recherche-doc et l'index spec API) enveloppés comme outils natifs — schéma validé, taille de réponse gérée, pas de boilerplate curl/JSON. Une commodité par rapport à la lane curl, pas une source de données plus riche ; utilise-les quand présents, reviens à Lane 1 quand absent. Optionnel — saute cette lane si les outils ne sont pas présents.

• Préfère la vue ressource entière (getResourceSchemaByUrl) à une page de méthode unique : une exigence est souvent documentée sur une méthode voisine (p. ex. un memberId requis sur create unique mais omis de la page create en masse). La vue ressource porte les deux.
• Cherche d'abord la page recette/flux du vertical — beaucoup de verticaux publient des recettes opinionnées, multi-étapes sous un nœud …/business-solutions/<vertical>/skills (cherche « <vertical> setup recipe » ou parcours le menu). Une recette donne l'ordre correct, les pièges inter-étapes, et l'un des endpoints groupés qui fait tout le travail — qu'une schema par méthode ne signalera pas.

Le suffixe .md

Ajoute .md seulement quand tu curl-es une page directement. Les outils MCP et le endpoint de recherche prennent l'URL docs simple sans .md — ne passe jamais une URL .md à un outil MCP.

Avant d'écrire le code

Confirme sur la page — pas de mémoire — l'endpoint, le verbe HTTP, la forme du corps de requête, les champs requis, et toute valeur d'énumération. Ensuite écris l'appel. Si tu étends un client livré d'une skill, garde le style transport/helper existant de la skill ; tu ajoutes un appel, tu ne réarchitectures pas.