Limites et tarification

Plans publics workspace

Ce tableau est une vue dérivée du product kernel canonique dans packages/shared/src/lib/product-kernel.ts.

	Gratuit	Starter	Pro	Enterprise
Prix mensuel	0 €	7 € HT	24 € HT	Sur devis
Sites inclus	3	10	50	Sur mesure
Événements inclus / mois	25 000	100 000	1 000 000	Sur mesure
Utilisateurs inclus	1	3	10	Sur mesure
Rétention publique cible	60 jours	13 mois	24 mois	Sur mesure
Événements supplémentaires	Non	2 € / million	2 € / million	Sur mesure
Utilisateurs supplémentaires	Non	3 € / utilisateur / mois	3 € / utilisateur / mois	Sur mesure
Overage public automatique sur les sites	Non	Non	Non	Non

Ces limites correspondent au packaging public des workspaces utilisé par le pricing, les messages d’upgrade et les surfaces de consommation du dashboard.

Politique API self-serve

Ce tableau est dérivé du même kernel. Il reste distinct du packaging public workspace ci-dessus pour les familles de routes, les caps d’unités et les rate limits. La rétention API, elle, suit la même grille canonique de plan et reste distincte seulement du réglage technique de rétention disponible dans Settings > Sites > Collecte.

	Gratuit	Starter	Pro
Disponibilité de l'API	Non inclus	Limité	Standard
Rétention de lecture API (dérivée)	Non inclus	395 jours	730 jours
Unités API mensuelles incluses	Non inclus	100 000	1 000 000
Hard cap API (mensuel)	Non inclus	250 000	2 000 000
Rate limit API	Non inclus	15 req/s	30 req/s
Intervalle horaire API	Non	Oui	Oui
Endpoints rapports	Non	Non	Oui
Endpoints objectifs	Non	Non	Oui
Endpoints tenant	Non	Non	Oui
Dimensions tenant	Non	Non	Oui

Starter conserve une surface API volontairement limitée. Les routes rapports, objectifs et tenant restent indisponibles tant que la politique API active ne les autorise pas.

La surface runtime transporte maintenant cette politique explicitement :

• GET /v1/me expose la politique produit workspace dans product
• GET /v1/sites expose la politique effective au niveau site dans product_configuration
• les lectures analytics profile-aware exposent un objet availability et peuvent retourner 409 quand une famille de routes Extended-only est requise hors de son enveloppe de donnees compatible

Les miroirs de compatibilité comme plan_id ou retention_days restent dérivés de cet objet canonique, mais ils sont maintenant explicitement dépréciés. Les nouvelles intégrations doivent lire product.runtime_plan_id et product.product_retention.api_retention_days. Aucune suppression n’interviendra avant 2026-07-03T00:00:00Z.

Classes de routes actuelles :

• Strict-safe : /v1/reports/content, /v1/metrics/timeseries standard, /v1/metrics/breakdown standard
• Mixed : /v1/reports/overview, /v1/reports/acquisition, /v1/reports/actions
• Advanced / gated : /v1/goals/conversions, metriques tenant-scope et breakdowns tenant. Ces routes dependent du plan, de l’acces API tenant et de la compatibilite de configuration ; elles ne doivent pas etre relues comme une nature de collecte unique.

Pour les routes mixtes, la reponse reste en 200 en Strict pour le sous-ensemble strict-safe, utilise availability.readModel pour expliciter ce socle et utilise availability.sections pour marquer les sections d’attribution ou d’actions avancees qui restent verrouillees.

Règle de lecture : en Strict, le sous-ensemble non marqué constitue la lecture complète du socle pour cette route. Les sections signalées correspondent à un détail Extended optionnel, pas à un manque dans le socle de base.

Le même modèle vaut aussi dans le dashboard : Audience reste utile en Strict pour les dimensions techniques d’audience, tandis que les slices de type campagne restent enrichies.

Modes du rapport Content

GET /v1/reports/content expose deux formes de réponse sélectionnées par include :

Mode	Période UTC inclusive	Réponse
summary	1–365 jours	Totaux et un point global quotidien de pages vues ; jours vides mis à zéro
full	1–90 jours	Totaux, détails par page, tendance par page, entrées et sorties
details (alias déprécié)	1–90 jours	Normalisé vers full ; utiliser include=full pour les nouvelles intégrations

Sans include, les périodes jusqu’à 90 jours utilisent full ; celles de 91 à 365 jours utilisent summary. La comparaison est limitée à 30 jours dans les deux modes. limit n’a aucun effet en summary.

La série temporelle summary est dense et ordonnée par date UTC : elle contient exactement un point pour chaque jour demandé et sa somme de pages vues est égale à totals.pageviews. Elle ne contient ni chemins ou lignes détaillées par page, ni listes d’entrées ou de sorties au niveau supérieur.

Les réponses Content détaillées synchrones et les exports CSV restent limités à 90 jours. Un export détaillé plus long nécessiterait un futur traitement asynchrone ; l’API actuelle n’en expose aucun.

Modèle de coût

Chaque requête de métriques réussie (/v1/metrics/timeseries ou /v1/metrics/breakdown) consomme des unités. Les endpoints non métrés (/v1/me, /v1/sites, /v1/usage/*) sont gratuits.

Les unités sont calculées ainsi :

unites = base x interval x range x limit x dimension x metric

Facteur	Valeur
base	2 (timeseries) ou 4 (breakdown)
interval	1 (jour) ou 3 (heure)
range	ceil(jours / 30)
limit	ceil(limit / 100) — breakdown uniquement
dimension	2 (page) ou 1 (autre) — breakdown uniquement
metric	2 (pageviews, sessions) ou 1 (events)

Le metering du rapport Content conserve ses facteurs de base et de durée dans les deux modes. summary n’applique pas de facteur limit ; full et l’alias déprécié details conservent le facteur existant. Un hit du cache final reste facturable.

Budget de réponse

Chaque réponse de rapport, y compris un hit du cache final, est contrôlée avec un budget dur de 5 MiB sur la réponse proxy sérialisée. Aucune réponse n’est tronquée. Si la réponse candidate dépasse le budget, l’API renvoie HTTP 422 avec REPORT_RESPONSE_TOO_LARGE et fournit include, range_days, measured_bytes et max_bytes dans error.details. La requête rejetée consomme zéro unité et n’est pas écrite dans le cache final de réponse.

Exemples

Requête	Calcul	Unités
Timeseries, pageviews, 7 jours, quotidien	2 x 1 x 1 x 1 x 1 x 2	4
Timeseries, pageviews, 60 jours, horaire	2 x 3 x 2 x 1 x 1 x 2	24
Breakdown par referrer, sessions, 30 jours, limit 100	4 x 1 x 1 x 1 x 1 x 2	8
Breakdown par page, pageviews, 90 jours, limit 500	4 x 1 x 3 x 5 x 2 x 2	240

Soft overage

Quand used_units > included_units, les requêtes continuent normalement. Les métadonnées de réponse indiquent l’overage :

{
  "meta": {
    "units_charged": 4,
    "billable_overage": true,
    "usage": {
      "used_units": 104,
      "overage_units": 4,
      "included_units": 100,
      "hard_cap_units": 250
    }
  }
}

Ces chiffres sont uniquement illustratifs. Les valeurs réelles d’included units et de hard cap viennent du plan actif dans le product kernel. Surveillez le flag billable_overage pour alerter avant d’atteindre le hard cap.

Hard cap

Quand le hard cap est atteint :

• HTTP 402 avec code d’erreur HARD_CAP_REACHED
• Aucune consommation supplémentaire n’est enregistrée
• Réinitialisation au début de chaque période de facturation (1er du mois, UTC)

Rate limit

Les rate limits par token sont appliquées dans des fenêtres glissantes de 60 secondes :

• HTTP 429 avec code d’erreur RATE_LIMITED
• Headers : X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset
• Attendez X-RateLimit-Reset avant de réessayer

Surveiller votre consommation

• Les utilisateurs dashboard peuvent lire la consommation globale depuis Settings > Consommation.
• Le détail d’un site et ses réglages de capture vivent dans Settings > Sites > Collecte.
• GET /v1/usage/current — consommation de la période en cours
• GET /v1/usage/history — historique mensuel (jusqu’à 24 mois)

Ces endpoints sont gratuits et accessibles aux tokens avec le scope metrics:read ou usage:read.