Terms of Service · API & Plateforme

01 Préambule

Les présentes Conditions Générales d'Utilisation de l'API et de la Plateforme (ci-après les « Conditions API ») régissent l'accès et l'utilisation des interfaces de programmation applicative (API), des composants techniques, des intégrations et des services connexes proposés par VECTRYS SAS (ci-après « VECTRYS ») aux personnes physiques ou morales développant ou exploitant une application tierce intégrant ces capacités (ci-après le « Développeur » ou le « Client B2B »).

Les présentes Conditions API constituent un complément technique aux Conditions Générales de Vente (CGV), à la Politique de confidentialité et, le cas échéant, à l'Accord de Traitement des Données (DPA) conclu au titre de l'article Art. 28 RGPD. En cas de contradiction entre les présentes et les CGV, les CGV prévalent pour les conditions strictement commerciales (prix, modalités de paiement, durée du contrat), et les présentes Conditions API prévalent pour toute disposition technique d'usage de l'API.

L'utilisation effective de l'API VECTRYS — caractérisée par toute requête authentifiée à un endpoint productif — emporte acceptation pleine et entière des présentes Conditions API. Toute personne n'acceptant pas l'intégralité des stipulations doit immédiatement révoquer ses jetons d'accès et cesser tout usage.

02 Définitions techniques

Les termes ci-dessous, commençant par une majuscule, ont la signification suivante :

03 Accès à l'API

3.1 · Inscription développeur

L'accès à l'API requiert la création d'un compte développeur sur la console mise à disposition par VECTRYS. Cette inscription est gratuite et conditionnée à : (i) l'acceptation des présentes Conditions API ; (ii) la fourniture d'informations exactes (raison sociale, numéro SIREN pour les personnes morales, adresse email valide, coordonnées de contact technique et juridique) ; (iii) la vérification d'adresse email par lien d'activation ; (iv) le cas échéant, la signature électronique d'un DPA Art. 28 RGPD pour tout usage productif traitant des données personnelles.

3.2 · Création d'une Application Développeur

Après inscription, le Développeur crée une ou plusieurs Applications Développeur dans la console. Chaque application reçoit :

• client_id : identifiant public OAuth 2.0, partageable ;
• client_secret : secret confidentiel, à protéger comme un mot de passe, jamais exposé côté client (navigateur, application mobile décompilable) ;
• redirect_uris : liste exhaustive des URIs de redirection autorisées pour le flux Authorization Code ;
• scopes : périmètres OAuth par défaut autorisés pour l'application.

3.3 · Obtention d'un Bearer Token

L'obtention d'un Bearer Token suit le flux OAuth 2.0 Authorization Code avec PKCE (RFC 7636) :

# 1. PKCE code_verifier + code_challenge généré côté client
curl -X POST "https://api.vectrys.fr/v1/oauth/token" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=authorization_code" \
  -d "client_id=app_a1b2c3d4e5" \
  -d "code=AUTH_CODE_FROM_REDIRECT" \
  -d "redirect_uri=https://app.example.com/callback" \
  -d "code_verifier=43_TO_128_CHAR_VERIFIER"

const tokenResponse = await fetch('https://api.vectrys.fr/v1/oauth/token', {
  method: 'POST',
  headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
  body: new URLSearchParams({
    grant_type: 'authorization_code',
    client_id: process.env.CLIENT_ID,
    code: authCode,
    redirect_uri: 'https://app.example.com/callback',
    code_verifier: codeVerifier
  })
});
const { access_token, refresh_token, expires_in } = await tokenResponse.json();

import requests, os

response = requests.post(
    "https://api.vectrys.fr/v1/oauth/token",
    data={
        "grant_type": "authorization_code",
        "client_id": os.environ["CLIENT_ID"],
        "code": auth_code,
        "redirect_uri": "https://app.example.com/callback",
        "code_verifier": code_verifier,
    },
    timeout=10,
)
response.raise_for_status()
tokens = response.json()
access_token, refresh_token = tokens["access_token"], tokens["refresh_token"]

# Flux complet OAuth 2.0 Authorization Code avec PKCE (RFC 7636)

# Étape 1 · Client génère code_verifier (43-128 char) puis code_challenge
code_verifier  = base64url(random(32 bytes))
code_challenge = base64url(SHA256(code_verifier))

# Étape 2 · Redirection utilisateur vers VECTRYS pour autorisation
GET https://auth.vectrys.fr/v1/authorize?
    response_type=code
    &client_id=app_a1b2c3d4e5
    &redirect_uri=https://app.example.com/callback
    &scope=read:reservations write:reservations
    &state=RANDOM_NONCE
    &code_challenge=BASE64URL(SHA256(verifier))
    &code_challenge_method=S256

# Étape 3 · VECTRYS redirige avec code
<-- https://app.example.com/callback?code=AUTH_CODE&state=RANDOM_NONCE

# Étape 4 · Échange code → tokens (cf. exemples cURL/Node/Python)
POST https://api.vectrys.fr/v1/oauth/token

# Étape 5 · Appel API authentifié
GET  https://api.vectrys.fr/v1/reservations
     Authorization: Bearer eyJhbGciOiJSUzI1NiIs...

3.4 · Rotation et révocation

Le Développeur peut révoquer un Bearer Token ou un Refresh Token à tout moment depuis la console. Une rotation périodique des client_secret tous les douze (12) mois est recommandée. Toute compromission présumée d'un secret impose une régénération immédiate par le Développeur ; VECTRYS se réserve le droit de révoquer unilatéralement tout secret suspecté de compromission.

04 Limites de débit & quotas

Afin de garantir la stabilité de la plateforme pour l'ensemble des Développeurs, les limites de débit ci-dessous s'appliquent par défaut. Elles sont mesurées par client_id et fenêtre glissante de soixante (60) secondes. Tout dépassement provoque l'émission d'une réponse HTTP 429 Too Many Requests assortie d'un en-tête Retry-After indiquant le délai en secondes avant nouvelle requête.

4.1 · En-têtes informatifs

Chaque réponse API contient les en-têtes suivants permettant un usage proactif des limites :

X-RateLimit-Limit:     1000            # Limite par minute du tier courant
X-RateLimit-Remaining: 847             # Requêtes restantes fenêtre courante
X-RateLimit-Reset:     1748295600      # Timestamp UTC reset fenêtre
X-RateLimit-Burst:     250             # Tolérance burst restante
Retry-After:           42              # Présent uniquement si 429 retourné

4.2 · Gestion du throttling côté client

Le Développeur est tenu d'implémenter une stratégie de backoff exponentiel avec jitter en cas de réception d'un statut 429 ou 503 :

async function requestWithRetry(url, options, maxRetries = 5) {
  for (let attempt = 0; attempt < maxRetries; attempt++) {
    const response = await fetch(url, options);
    if (response.status !== 429 && response.status !== 503) return response;
    const retryAfter = Number(response.headers.get('Retry-After')) || 1;
    const jitter = Math.random() * 0.3;
    const delay = (retryAfter * (2 ** attempt) + jitter) * 1000;
    await new Promise(r => setTimeout(r, delay));
  }
  throw new Error('Max retries exceeded');
}

05 Endpoints disponibles

L'API VECTRYS expose deux interfaces complémentaires :

• REST API v1 · stable, versionnée, URI racine https://api.vectrys.fr/v1 ;
• GraphQL · en bêta, URI racine https://api.vectrys.fr/graphql, introspection activée en sandbox uniquement.

La liste exhaustive et structurée des opérations supportées est consultable ci-dessous. Toute opération s'effectue sous TLS 1.2+ et requiert un Bearer Token valide assorti des scopes appropriés.

5.1 · Format des réponses

Sauf indication contraire, toutes les réponses sont au format JSON encodées en UTF-8, avec en-tête Content-Type: application/json; charset=utf-8. Le schéma global est :

{
  "data": { ... },
  "meta": {
    "request_id": "req_a1b2c3d4e5f6",
    "timestamp": "2026-05-26T15:32:18.421Z",
    "pagination": {
      "page": 1,
      "per_page": 50,
      "total": 324,
      "next_cursor": "eyJpZCI6Ijc4OSJ9"
    }
  },
  "errors": []
}

5.2 · Codes d'erreur normalisés

Les erreurs respectent les codes HTTP standards (RFC 9110) et incluent un objet error structuré conforme à RFC 7807 (Problem Details for HTTP APIs) :

{
  "type":    "https://docs.vectrys.fr/errors/rate-limit-exceeded",
  "title":   "Rate limit exceeded",
  "status":  429,
  "detail":  "Limit of 1000 req/min reached for tier Pro",
  "instance": "/v1/reservations",
  "request_id": "req_a1b2c3d4e5f6"
}

06 Webhooks

Les webhooks permettent à VECTRYS de notifier en temps quasi-réel le système du Développeur de la survenance d'événements métier (création de réservation, annulation, transition de statut mission, paiement reçu, etc.).

6.1 · Configuration

• URI de réception obligatoirement HTTPS (TLS 1.2 minimum) — toute URI HTTP non sécurisée est rejetée ;
• Filtrage par type d'événement (souscription granulaire à un sous-ensemble) ;
• Secret de signature partagé (HMAC SHA-256), rotation recommandée tous les six (6) mois ;
• Possibilité de configurer une URI de réception secondaire en bascule (failover) en environnement Enterprise.

6.2 · Signature HMAC SHA-256

Chaque webhook est signé pour garantir l'authenticité et l'intégrité. Le Développeur DOIT vérifier la signature avant tout traitement :

X-Vectrys-Event:        reservation.created
X-Vectrys-Delivery-Id:  d_a1b2c3d4e5f6
X-Vectrys-Timestamp:    1748295600           # Unix epoch UTC
X-Vectrys-Signature:    v1,sha256=4f8c2e...   # HMAC-SHA256(secret, timestamp + "." + body)

import crypto from 'crypto';

function verifyWebhook(rawBody, headers, secret) {
  const ts        = headers['x-vectrys-timestamp'];
  const signature = headers['x-vectrys-signature'];

  // Anti-replay : timestamp doit être < 5 minutes
  if (Math.abs(Date.now()/1000 - ts) > 300) return false;

  const expected = 'v1,sha256=' + crypto
    .createHmac('sha256', secret)
    .update(ts + '.' + rawBody)
    .digest('hex');

  return crypto.timingSafeEqual(
    Buffer.from(signature),
    Buffer.from(expected)
  );
}

6.3 · Politique de retry

• Retry exponential · 5 tentatives maximum, intervalles 1 min · 5 min · 30 min · 2 h · 6 h ;
• Time-to-live · 24 heures à compter de la première tentative ;
• Codes de succès · réponse HTTP 2xx (idéalement 200 ou 204) sous 10 secondes ;
• Codes considérés en échec · 4xx (sauf 408/429) marquent l'événement non rejouable ; 5xx et timeouts déclenchent un retry.

07 Authentification & autorisation

7.1 · OAuth 2.0 PKCE (RFC 7636)

L'API VECTRYS implémente exclusivement le grant type Authorization Code avec PKCE pour les flux interactifs (clients publics navigateur ou mobile) et Client Credentials pour les flux machine-to-machine (M2M). Le grant type Implicit, déprécié par OAuth 2.1 draft, n'est pas supporté.

Les scopes OAuth disponibles sont :

• read: · accès en lecture seule sur la ressource (properties, reservations, missions, guests, billing, webhooks, usage, audit) ;
• write: · création et modification (properties, reservations, missions, webhooks) ;
• admin: · opérations sensibles incluant suppression et droit à l'effacement (properties, guests, webhooks) ;
• basic · introspection et révocation de tokens ;
• public · endpoint /v1/health uniquement, sans authentification.

7.2 · JWT (RFC 7519)

Les Bearer Tokens sont des JWT signés en RS256 (clés publiques rotatives, exposées via https://api.vectrys.fr/.well-known/jwks.json). Structure des claims :

{
  "iss":   "https://api.vectrys.fr",                # Émetteur
  "sub":   "usr_98765",                              # Sujet (utilisateur final)
  "aud":   "app_a1b2c3d4e5",                         # Audience (client_id)
  "exp":   1748299200,                                # Expiration (TTL 1h)
  "iat":   1748295600,                                # Issued At
  "jti":   "j_a1b2c3d4e5f6",                         # JWT ID unique (anti-replay)
  "scope": "read:reservations write:reservations",
  "tenant_id": "ten_xy789"
}

7.3 · Conformité OWASP API Security Top 10 (2023)

L'infrastructure VECTRYS est conçue pour adresser les dix risques majeurs identifiés par l'OWASP API Security Top 10 édition 2023. Les mesures techniques principales sont rappelées ci-dessous :

7.4 · Mesures complémentaires

• Mass Assignment · validation explicite des champs acceptés en entrée (Zod / JSON Schema côté serveur), rejet 422 sur champs inconnus en mode strict ;
• Improper Inventory · documentation OpenAPI 3.1 auto-générée et publiée pour chaque release ; endpoints internes jamais exposés ;
• Audit trail · journalisation horodatée et immuable de toute opération sensible, accessible via /v1/audit/events.

08 Usage acceptable & interdictions

8.1 · Usages autorisés

Le Développeur peut utiliser l'API pour intégrer les capacités fonctionnelles de VECTRYS dans son propre produit, son back-office, ou ses outils internes, dans la limite des scopes autorisés à son application et dans le strict respect du contrat commercial associé.

8.2 · Interdictions expresses

Sans préjudice de tout recours, sont expressément prohibés :

• Scraping massif · toute extraction automatisée à grande échelle dépassant les besoins fonctionnels documentés ;
• Revente de données · cession ou commercialisation à un tiers de tout ou partie des données accessibles via l'API, sans autorisation expresse écrite de VECTRYS ;
• Competing service · usage de l'API pour bâtir un service concurrent réplicant les capacités de la plateforme ;
• Reverse engineering · décompilation, désassemblage ou tentative de reconstitution des algorithmes propriétaires sous-jacents, protégés au titre du secret des affaires · L.151-1 C. com. ;
• Contournement · de toute mesure de sécurité, de limitation de débit ou de contrôle d'accès ;
• Usage frauduleux · création multiple de comptes développeur pour additionner des quotas gratuits ;
• Atteinte à la plateforme · toute action visant à dégrader la disponibilité, l'intégrité ou la confidentialité du service (DoS, injection, etc.) ;
• Usage illégal · toute finalité contrevenant aux lois et règlements applicables, notamment en matière de données personnelles, de droit du tourisme ou de concurrence déloyale.

8.3 · Protection des algorithmes propriétaires

Les composants algorithmiques, modèles, briques techniques et savoir-faire intégrés dans la plateforme constituent des secrets des affaires au sens de l'Article L.151-1 du Code de commerce, transposant la Directive (UE) 2016/943 par la Loi n° 2018-670 du 30 juillet 2018. Toute tentative d'extraction, de reconstitution ou de divulgation est strictement interdite et engage la responsabilité civile et pénale du contrevenant.

Le code, les schémas API, les structures de données et les libellés exposés via la documentation sont également protégés au titre du droit d'auteur · Art. L.111-1 et L.122-4 CPI.

8.4 · Sanctions

Tout manquement aux interdictions ci-dessus pourra entraîner, sans mise en demeure préalable et sans préjudice de tout recours :

• Suspension immédiate de l'accès à l'API (révocation tokens, blocage client_id) ;
• Résiliation de plein droit du contrat commercial associé ;
• Action en réparation du préjudice subi (technique, commercial, réputationnel) ;
• Poursuites pénales pour les manquements caractérisés (atteinte à un système de traitement automatisé de données — Art. 323-1 et s. C. pén.).

09 Niveaux de service (SLA)

9.1 · Engagements de disponibilité

VECTRYS s'engage à fournir l'API en production avec les taux de disponibilité mensuels suivants :

9.2 · Mesure et exclusions

La disponibilité est mesurée sur l'endpoint /v1/health par sondage externe toutes les minutes. Sont exclus du calcul :

• Les maintenances programmées annoncées avec un préavis ≥ 72 heures (limité à 4 h cumulées / mois maximum) ;
• Les indisponibilités causées par un cas de force majeure (Art. 1218 C. civ.) ;
• Les indisponibilités causées par le Développeur lui-même (dépassement de quotas, requêtes malformées, abus) ;
• Les indisponibilités affectant exclusivement l'environnement Sandbox.

9.3 · Crédits SLA

En cas de non-respect du SLA contractuel, le Développeur bénéficie de crédits SLA appliqués sur la facture du mois suivant, selon le barème :

Les crédits SLA constituent le recours unique et exclusif du Développeur en cas de non-conformité aux engagements de niveau de service, sans préjudice du droit de résiliation prévu à la section 13.

10 Logs & audit

10.1 · Journalisation

VECTRYS journalise l'ensemble des appels API à des fins de sécurité, de facturation, de support et de conformité réglementaire. La nature et la durée de conservation des logs sont les suivantes :

10.2 · Registre des traitements

Conformément à l'Article 30 RGPD, VECTRYS tient un registre des activités de traitement, accessible sur demande motivée des autorités de contrôle ou du Développeur dans le cadre d'un audit prévu au DPA.

10.3 · Accès aux logs par le Développeur

• Console développeur · accès consultation logs d'accès 30 derniers jours, filtrable par endpoint, statut, request_id ;
• API d'audit · endpoint /v1/audit/events pour consommation programmatique (rétention 30 jours rolling) ;
• Export sur demande · les Développeurs en tier Business ou Enterprise peuvent demander un export CSV/JSON sur une période étendue (max 12 mois) avec un délai de 5 jours ouvrés.

11 Versionnement de l'API

11.1 · Stratégie semver

L'API VECTRYS suit le versionnement Semantic Versioning 2.0.0 (semver). La version majeure est exposée dans l'URI (/v1, /v2...) ; les versions mineures et patch sont rétro-compatibles et publiées dans l'en-tête de réponse X-Vectrys-API-Version.

• v1 · stable · production-grade ;
• v2 · bêta · ouverte sur opt-in ; API contractuellement instable jusqu'à promotion stable ;
• GraphQL · bêta · introspection activée sandbox uniquement.

11.2 · Dépréciation

Toute version dépréciée bénéficie d'une période de grâce minimum de douze (12) mois entre l'annonce officielle et le retrait effectif. Pendant cette période :

• Un en-tête Deprecation: true est ajouté à toutes les réponses des endpoints concernés ;
• Un en-tête Sunset indique la date butoir au format RFC 9745 ;
• Une communication écrite est adressée par email aux contacts techniques de chaque Application Développeur utilisant la version dépréciée ;
• Un guide de migration détaillé est publié dans la documentation au plus tard à l'annonce.

11.3 · Changements breaking

Les modifications suivantes sont considérées comme breaking et déclenchent un incrément de version majeure : suppression d'endpoint, suppression de champ obligatoire dans une réponse, modification d'un format de champ existant, changement de sémantique d'un code d'erreur, durcissement de validation entraînant un rejet d'entrées précédemment acceptées.

Les modifications suivantes sont non-breaking et publiées en version mineure : ajout d'un nouvel endpoint, ajout d'un champ optionnel dans la réponse, ajout d'un nouveau code d'erreur, élargissement de validation acceptant davantage d'entrées.

12 Données développeur

12.1 · Distinction des rôles RGPD

Aux fins du Règlement (UE) 2016/679 (RGPD) :

• Données Développeur · données techniques et personnelles relatives au Développeur lui-même (identifiants console, logs d'appel, IP source, identités des contacts techniques et juridiques) — VECTRYS agit en qualité de responsable de traitement ;
• Données Utilisateurs Finaux · données traitées via l'API au profit des utilisateurs finaux du Développeur (clients, voyageurs, propriétaires, prestataires) — le Développeur agit en qualité de responsable de traitement, VECTRYS en qualité de sous-traitant au sens de l'Article 28 RGPD.

12.2 · Accord de Traitement des Données (DPA)

Tout usage de l'API en production traitant des Données Utilisateurs Finaux nécessite la signature préalable d'un DPA conforme à l'Article 28 RGPD, incluant notamment :

• Objet, durée, nature et finalité du traitement ;
• Catégories de données et de personnes concernées ;
• Engagements de sécurité (Art. 32 RGPD) ;
• Liste des sous-traitants ultérieurs et procédure d'information préalable ;
• Modalités d'assistance pour la mise en œuvre des droits des personnes ;
• Procédure de notification de violation (72 heures · Art. 33 RGPD) ;
• Modalités de restitution ou destruction en fin de traitement.

12.3 · Transferts internationaux

Les Données Développeur sont hébergées au sein de l'Union européenne (datacenters en France, infrastructure souveraine). Aucun transfert vers un pays tiers n'est effectué par défaut. Tout transfert exceptionnel encadré par un sous-traitant ultérieur fait l'objet de Clauses Contractuelles Types (CCT) approuvées par la Commission européenne par décision 2021/914.

13 Résiliation de l'accès à l'API

13.1 · Résiliation à l'initiative du Développeur

Le Développeur peut résilier son accès à tout moment, depuis la console développeur, avec un préavis de trente (30) jours. Pendant ce préavis, l'accès demeure pleinement fonctionnel afin de permettre la migration des intégrations dépendantes. À l'expiration du préavis, l'ensemble des tokens, secrets et webhooks sont révoqués automatiquement.

13.2 · Résiliation à l'initiative de VECTRYS

VECTRYS peut résilier l'accès à l'API d'un Développeur en respectant un préavis de quatre-vingt-dix (90) jours, par notification écrite, sans motif, dans le cadre d'une évolution stratégique de la plateforme ou d'une décision commerciale. Pendant ce préavis, l'accès est maintenu en l'état.

13.3 · Résiliation immédiate pour faute

VECTRYS peut résilier immédiatement, sans préavis ni indemnité, et sans préjudice de tout recours, l'accès à l'API en cas de :

• Manquement grave aux interdictions de la section 8 (scraping massif, reverse engineering, contournement, etc.) ;
• Atteinte avérée à la sécurité de la plateforme ou aux données d'autres Développeurs ou utilisateurs ;
• Procédure collective ouverte à l'encontre du Développeur (sauvegarde, redressement, liquidation) ;
• Défaut de paiement persistant après mise en demeure, conformément aux CGV ;
• Violation caractérisée des secrets des affaires VECTRYS au sens de l'Art. L.151-1 C. com..

13.4 · Conséquences de la résiliation

• Révocation immédiate de l'ensemble des tokens et secrets ;
• Désactivation des webhooks ;
• Conservation des logs réglementaires conformément à la section 10.1 ;
• Restitution ou destruction des Données Utilisateurs Finaux selon les modalités du DPA (Art. 28 § 3 g) RGPD) ;
• Survie des stipulations relatives à la propriété intellectuelle, aux secrets des affaires, à la confidentialité, à la responsabilité et aux litiges.

14 Litiges & juridiction

14.1 · Loi applicable

Les présentes Conditions API sont soumises au droit français, sans considération de ses règles de conflit de lois. Pour les Développeurs établis dans un État membre de l'Union européenne autre que la France, les dispositions impératives du droit local des consommateurs ou des entreprises, le cas échéant applicables, demeurent réservées.

14.2 · Tentative de résolution amiable

Préalablement à toute action contentieuse, les parties s'engagent à tenter une résolution amiable du différend pendant une durée raisonnable de trente (30) jours à compter de la notification écrite du litige. Les parties peuvent désigner d'un commun accord un médiateur professionnel inscrit sur les listes de la Cour d'appel de Paris.

14.3 · Juridiction compétente

À défaut de résolution amiable, et nonobstant pluralité de défendeurs ou appel en garantie, compétence exclusive est attribuée au Tribunal de commerce de Paris pour tout litige relatif à la formation, l'interprétation, l'exécution ou la résiliation des présentes Conditions API.

14.4 · Arbitrage optionnel

Par exception et sur accord exprès des deux parties, tout litige peut être tranché définitivement selon le Règlement d'arbitrage de la Chambre de Commerce Internationale (CCI) de Paris, par un ou trois arbitres nommés conformément audit règlement. Le siège de l'arbitrage est fixé à Paris, France. La langue de l'arbitrage est le français. L'option d'arbitrage est subordonnée à un montant de différend supérieur à 100 000 € HT.