Instructions for AI coding agents

This page is the fast path for an AI coding agent (Claude Code, Cursor, OpenCode, or similar) building a partner integration with the Resamania API. Treat it as the source of truth for defaults and conventions, and follow the linked pages for full detail on any topic below.

What Resamania is

Resamania (by Xplor Technologies) is a multi-tenant SaaS for managing fitness/sports clubs: members (CRM), access control, class scheduling & booking, online sales, billing (card, SEPA, BACS), and marketing campaigns. The public REST API (OAuth2-secured, Symfony / API Platform) is what this site documents. The member-facing mobile app is called Xplor Active.

Non-negotiable facts

• Go through the API Gateway. As of June 2026, direct calls to the Resamania API are no longer supported — every request goes through the API Gateway. See API Gateway.
• Every URL is tenant-scoped. Requests are shaped https://{gateway_base_url}/{clientToken}/... — the clientToken identifies the Resamania client (club or club chain) you're integrating with. Never invent or guess it; it's provided when the partner application is registered.
• IDs are IRIs, not raw numbers. Reference other resources by their full IRI (e.g. /{clientToken}/clubs/22), never a bare integer.
• Required headers on every call: authorization: Bearer {access_token}, x-gravitee-api-key, and x-user-club-id. Add x-user-network-node-id whenever the client operates a club chain. Full breakdown: components of a request.
• Call the API from your backend only. The Resamania API must never be called directly from a browser or mobile app. Your server holds the credentials and talks to Resamania; it then exposes only what your own front end needs. See Security and partner responsibilities.
• client_credentials is generic, not personalized. When grant_type=client_credentials is used, the resulting token carries no implicit club/user context — every subsequent request made with that token must explicitly set both x-user-club-id and x-user-network-node-id, even for single-club tenants where the second header is normally optional. See the "client_credentials" method.
• Sandbox ≠ production. Sandbox contains test data only; never expect or request real member data there. Production access is opened only after Resamania's team reviews your test-phase calls — see Getting started.

Picking an authentication method

Resamania supports several OAuth2 grant types — pick based on who is acting, not by default:

Grant type	Use when
client_credentials	Server-to-server, non-personalized access (your backend acting as itself)
code	An end user authorizes your app interactively
password	You directly collect a Resamania end-user's credentials (legacy/limited use)
http://clubclientcredentials	Server-to-server access scoped to a specific club context
http://contactclientcredentials	Access acting on behalf of a specific contact/member
refresh_token	Renew an existing session without re-authenticating

Full detail: Authentication.

Implementing a business workflow

Don't improvise the call sequence — each domain has a documented, mandatory order. Read the relevant page before writing code, not after:

• Selling to an existing member: Sell to an existing contact — identify the contact → check debt → fetch the catalog → create the cart → add items → check validity → settle the payment.
• Contract / direct-debit mandate / electronic signature: Contract, mandate, signature — mandate → display contract → SMS signature request → complete signature.
• Online registration of a new member: Online registration.
• Booking a class: Retrieve the schedule, Book a class.
• Cancellation: Online cancellation.
• Club chains / multi-club: Working with club chains.

Full OpenAPI reference, one spec per business domain (catalog, club, contact, accounting, sale, planning...): API Reference.

Sensible defaults when the partner hasn't specified

• Prefer webhooks over polling for change notification (see Webhooks); if you must poll, respect the rate limiting policy and back off on 429.
• Treat payment-creation calls (POST .../sales/{id}/payments) as non-idempotent and dangerous to retry blindly — a naive retry after a timeout can create a duplicate payment. Guard against this explicitly.
• Never persist or log card, IBAN, or other payment data beyond what's required in-flight.
• Treat member data as personal data under GDPR / UK GDPR: collect only what the integration needs, and honor the anonymisation signal (isAnonymous) by anonymizing your own copy too.

Before asking for production access

Run the pre-submission review skill against the integration you've built. It produces an endpoint inventory and a checklist report you can hand to Resamania's API team — the fastest way through the test phase described in Getting started.

Full site index

For anything not covered above, fetch llms.txt for a condensed index of every page on this site, or browse the sidebar. A French version of this documentation set is available under /fr/.