Français

English

Français

English

Appearance

Skill IA : revue des requêtes avant recette ​

Avant que ton intégration ne passe par la phase de test ("recette") décrite dans Démarrage, tu peux faire tourner ce skill avec ton propre agent IA pour te relire d'abord. Il inventorie tous les appels à l'API Resamania présents dans ton code, les vérifie par rapport à nos conventions, et produit un rapport à partager avec notre équipe API — le moyen le plus rapide de réduire les allers-retours pendant la revue.

Cela ne remplace pas la revue de Resamania avant l'ouverture des endpoints en production ; cela permet de lever les problèmes les plus fréquents avant que cette revue ne commence.

Ce qu'il vérifie ​

  1. Inventaire des endpoints — chaque endpoint appelé, son usage métier, et où il est utilisé, sous forme de tableau.
  2. Paramètres obligatoires — chaque champ requis (d'après la spec OpenAPI) est systématiquement fourni.
  3. Audit PII / sécurité — aucune donnée personnelle qui fuiterait dans les logs, l'analytics ou des requêtes tierces.
  4. Appels back-end uniquement — l'API n'est jamais appelée directement depuis un navigateur ou une application mobile.
  5. En-têtes client_credentials — x-user-club-id et x-user-network-node-id sont toujours tous les deux présents quand ce grant type est utilisé.
  6. Enchaînement des workflows — les flux métier (vente, mandat/signature, inscription, réservation...) respectent l'ordre d'appel documenté, sans étape obligatoire oubliée.
  7. Contrôles complémentaires — bon grant type, usage des IRI, idempotence des paiements, pagination, gestion du rate limiting, hygiène des identifiants, configuration des webhooks.

Comment l'utiliser ​

Option A — l'enregistrer comme skill réutilisable. Si ton agent IA supporte les fichiers de skill (ex. Claude Code), enregistre le bloc ci-dessous dans .claude/skills/resamania-api-review/SKILL.md dans le dépôt de ton intégration, puis demande à ton agent de l'exécuter (ex. /resamania-api-review).

Option B — prompt ponctuel. Colle directement le même bloc dans la conversation de ton agent IA, en le pointant sur le code de ton intégration.

Le bloc ci-dessous est volontairement en anglais : c'est le même, mot pour mot, que celui de la version anglaise de cette page, afin de garantir un comportement identique quel que soit l'agent utilisé et d'éviter que les deux versions ne divergent avec le temps.

markdown
---
name: resamania-api-review
description: Pre-submission review of a Resamania API partner integration — endpoint inventory, required-parameter check, PII/security audit, backend-only enforcement, client_credentials header check, and workflow-sequencing check against doc.resamania.com. Use before requesting Resamania's test/recette phase.
---

You are reviewing a partner integration with the Resamania API (doc.resamania.com) before it is
submitted to Resamania's API team for the test ("recette") phase. Work only from what is actually
in this codebase — do not assume a call exists because the documentation describes it.

Source of truth: fetch https://doc.resamania.com/for-agents first, then the specific pages it
points to for the domains this integration touches (sale, auth, contacts, booking, webhooks,
API reference).

Perform the following checks, in order:

1. Endpoint inventory. Find every HTTP call this codebase makes to the Resamania API / API
   Gateway. For each one, produce a row in a markdown table: Method, Path (with placeholders,
   e.g. `/{clientToken}/sales/{id}/payments`), Business purpose (what it does for the end user /
   club, in plain language), Where it's called from (file:function), and the doc page it
   corresponds to. This table is meant to be shared as-is with Resamania's API team.

2. Required parameters. For each endpoint in the inventory, open the matching OpenAPI spec under
   /api-reference/ and list its required request parameters. Confirm the code always supplies
   every one of them — flag any call site where a required field is conditionally omitted,
   defaulted to null, or only set on some code paths.

3. PII / security audit. Flag anywhere the integration might leak personal data: names,
   addresses, phone numbers, emails, IBAN/payment details, or health/fitness data appearing in
   logs, analytics events, error trackers (Sentry, etc.), or third-party requests. Confirm
   responses are trimmed to only the fields the integration actually needs before being
   forwarded, stored, or logged. Confirm anonymised contacts (`isAnonymous: true`) are handled
   correctly and never re-populated with stale personal data.

4. Backend-only enforcement. Confirm the Resamania API / Gateway is only ever called from
   server-side code. Flag any call originating from a browser bundle, mobile app binary, or any
   code path where the request (and therefore its `x-gravitee-api-key` / OAuth credentials) would
   be visible to an end user's device. Every such call must instead go through the partner's own
   backend, which then exposes a filtered response to the client.

5. client_credentials headers. For every token obtained with `grant_type=client_credentials`,
   confirm that literally every subsequent API call using that token sets both `x-user-club-id`
   and `x-user-network-node-id` explicitly — this grant is generic/non-personalized and carries no
   implicit context. Flag any call that omits either header, even if it currently "works" (e.g.
   single-club tenants where the header is normally optional) — for `client_credentials` both must
   always be present.

6. Workflow sequencing. For each business flow implemented (e.g. selling to an existing contact,
   mandate/contract/signature, online registration, cancellation, booking), compare the actual
   call sequence in the code against the documented sequence on the corresponding page (linked
   from https://doc.resamania.com/for-agents). Flag any missing mandatory step (e.g. no debt check
   before a sale, no `GET .../check` before settling payment, no contract display before
   requesting a signature, missing catalog-context filters, no idempotency guard on payment
   calls).

7. Additional hygiene checks.
   - Correct grant type for each use case (no `client_credentials` where a contact- or
     club-scoped grant is actually required, or vice versa).
   - IRIs used consistently (no bare numeric IDs passed where an IRI is expected).
   - Payment calls (`POST .../sales/{id}/payments`) are protected against duplicate submission on
     retry/timeout.
   - Pagination is handled correctly (no hardcoded assumption of a fixed page size, no unbounded
     loops).
   - Rate-limit handling: exponential backoff on `429`, no tight polling loop where a webhook
     subscription would do.
   - No OAuth `client_secret`, access tokens, or refresh tokens hardcoded, committed, or logged in
     plaintext.
   - Sandbox and production credentials are kept in separate configuration, never mixed.
   - If webhooks are used: the endpoint validates the `X-User-Club-Id` /
     `X-User-Network-Node-Id` headers and a distinct URL is configured per environment
     (prod/sandbox/overseas).

Output: a single markdown report containing the endpoint inventory table from check 1, and a
pass/fail list for checks 2-7, each failure with a file/line reference and a one-line fix
suggestion.

Après l'avoir exécuté ​

Partage le rapport obtenu avec l'équipe API de Resamania ([email protected]) en même temps que ta demande de phase de test.

Pourquoi ce skill reste à jour ​

Ce skill pointe vers doc.resamania.com plutôt que d'embarquer les règles métier en dur — si un en-tête requis ou un workflow documenté change, la mise à jour de la page concernée suffit à garder tous les partenaires utilisant ce skill synchronisés automatiquement.