2sync

Limites de débit et nouvelles tentatives automatiques

Comment 2sync gère les limites de débit API de Notion, Google et Microsoft

2sync communique avec des API externes (Notion, Google, Microsoft, Todoist) à chaque cycle de synchronisation. Ces API imposent des limites de débit pour éviter la surcharge. 2sync gère les limites de débit automatiquement avec des nouvelles tentatives et un backoff progressif, de sorte que vos données se synchronisent de manière fiable sans intervention manuelle.

Que sont les limites de débit ?

Les limites de débit sont des restrictions définies par les fournisseurs d'API sur le nombre de requêtes qu'une application peut effectuer dans une période donnée. Lorsque 2sync atteint une limite de débit, l'API rejette temporairement les requêtes suivantes jusqu'à ce que la limite se réinitialise.

Chaque fournisseur a des limites différentes :

FournisseurComportement
NotionLimite les requêtes par intégration par seconde
GoogleLimite le quota par utilisateur pour Calendar, Tasks, Contacts et Gmail
MicrosoftLimite par application et par utilisateur pour les services Outlook
TodoistLimite les requêtes par utilisateur par minute

Comment 2sync gère-t-il les limites de débit ?

2sync utilise un backoff exponentiel pour toutes les nouvelles tentatives. Lorsqu'une limite de débit est atteinte :

  1. La synchronisation se met en pause pour l'API concernée
  2. 2sync attend un intervalle croissant avant de réessayer (1s, 2s, 4s, 8s, etc.)
  3. Les nouvelles tentatives continuent jusqu'à ce que l'API accepte à nouveau les requêtes
  4. La synchronisation reprend là où elle s'était arrêtée

Ce processus est entièrement transparent. Vous n'avez pas besoin de cliquer sur quoi que ce soit ni de redémarrer votre automatisation.

Les limites de débit ne sont pas des erreurs. C'est un comportement normal des API lors d'opérations à fort volume. 2sync est conçu pour fonctionner automatiquement dans ces limites.

Qu'est-ce qui déclenche les limites de débit ?

Les limites de débit sont plus probables lors de :

  • La synchronisation initiale d'une grande base de données (des centaines ou milliers d'éléments)
  • Des modifications en masse appliquées à de nombreux éléments à la fois
  • Plusieurs automatisations synchronisant le même fournisseur simultanément
  • D'autres applications utilisant le même quota API sur votre compte

Comment le traitement par lots aide-t-il ?

Pour les opérations de synchronisation volumineuses, 2sync regroupe les modifications en lots plutôt que d'envoyer une requête par élément. Cela réduit le nombre total d'appels API et maintient les opérations dans les limites de débit plus efficacement.

Les tailles de lots s'ajustent dynamiquement en fonction du fournisseur et du statut actuel des limites de débit.

À quoi s'attendre pendant les synchronisations volumineuses ?

Lors de la configuration initiale ou après une longue pause, 2sync peut avoir besoin de traiter des milliers d'éléments. Dans ces cas :

  • Les temps de synchronisation peuvent être plus longs que le cycle habituel
  • Le statut de l'automatisation affiche Syncing pendant une période prolongée
  • Tous les éléments finiront par se synchroniser ; aucune intervention manuelle n'est nécessaire

Si vous voyez une erreur "Rate Limited" sur votre automatisation, cela signifie que le cycle de synchronisation en cours a été mis en pause en raison des limites API. La prochaine synchronisation planifiée se déroulera normalement. Aucune donnée n'est perdue.

Comment réduire l'impact des limites de débit ?

Réduisez votre fenêtre temporelle : synchroniser 6 mois d'événements nécessite moins d'appels API que 2 ans.

Utilisez des filtres : excluez les éléments dont vous n'avez pas besoin. Moins d'éléments synchronisés signifie moins de requêtes API par cycle.

Échelonnez les automatisations : si vous exécutez plusieurs automatisations pour le même fournisseur, envisagez des heures de synchronisation légèrement différentes pour répartir la charge.

Évitez les modifications en masse juste avant une synchronisation : si vous modifiez des centaines d'éléments, laissez un cycle de synchronisation se terminer avant de faire d'autres modifications.

Avant d'activer une grande synchronisation pour la première fois, lancez un Dry Run pour estimer le nombre de modifications. Cela vous aide à anticiper la durée de la synchronisation initiale et si les limites de débit seront un facteur. Voir Paramètres avancés de synchronisation pour les détails.

FAQ

Dois-je faire quelque chose quand 2sync atteint une limite de débit ?

Non. 2sync gère les limites de débit automatiquement avec un backoff exponentiel. La synchronisation se met brièvement en pause et reprend quand l'API le permet. Aucune action manuelle n'est nécessaire.

Les limites de débit causent-elles une perte de données ?

Non. Les limites de débit ne font que ralentir temporairement la synchronisation. Toutes les modifications en attente sont mises en file et traitées une fois la limite réinitialisée. Rien n'est ignoré ou perdu.

Pourquoi ma première synchronisation prend-elle si longtemps ?

Les synchronisations initiales traitent l'ensemble de votre base de données dans la fenêtre temporelle configurée. Cela peut signifier des milliers d'appels API, qui peuvent déclencher des limites de débit et nécessiter plusieurs cycles de nouvelles tentatives. Les synchronisations suivantes ne traitent que les modifications et sont beaucoup plus rapides.

Puis-je augmenter mes limites de débit API ?

Les limites de débit sont définies par les fournisseurs d'API (Google, Microsoft, Notion), pas par 2sync. 2sync opère dans ces limites et optimise les requêtes pour minimiser l'impact. Il n'y a pas de paramètre pour les augmenter.

Je rencontre des problèmes de limites de débit avec Notion. Que puis-je faire ?

Les limites de débit de Notion dépendent de la taille de votre base de données. Si vous atteignez fréquemment les limites, réduisez le nombre d'éléments synchronisés en restreignant votre fenêtre temporelle ou en ajoutant des filtres. La plupart des synchronisations réussissent après les nouvelles tentatives automatiques, mais des problèmes persistants avec de très grandes bases de données peuvent nécessiter de répartir les données sur plusieurs bases de données.