Plafond de l’API Marketing

L’API Marketing dispose de sa propre logique de plafond et elle est exclue de toutes les limites de débit de l’API Graph. Si vous effectuez un appel de l’API Marketing, il ne sera donc pas calculé dans la limitation de bande passante de l’API Graph.

La fonctionnalité qui a un impact sur le plafond de l’API Marketing est l’accès standard à la gestion des publicités. Lorsque vous ajoutez le produit API Marketing dans votre Espace App, vous obtiendrez l’accès standard de la fonctionnalité Accès standard à la gestion des publicités par défaut. Cela vous permettra d’accéder au développement de l’API Marketing. Si vous souhaitez disposer d’un plafond plus élevé, passez de l’accès standard à la gestion des publicités à l’accès Avancé dans le Contrôle app.

Plafonds

La plupart des requêtes de l’API Marketing et de l’API Pages sont soumises à des plafonds BUC (Business Use Case) et dépendent des points de terminaison que vous interrogez. Vous devriez être en mesure de déterminer cela en vérifiant si votre requête HTTP contient un en-tête X-Business-Use-Case. Pour plus de détails, reportez-vous à Plafonds BUC (Business Use Case).

Limites au niveau du compte publicitaire et de l’API

• Le plafond se situe au niveau du compte publicitaire.
• Les plafonds interviennent en temps réel sur une période donnée.
• Un indice est attribué à chaque appel de l’API Marketing. Votre indice correspond à la somme de vos appels d’API.
• Nous appliquons un indice maximal. En règle générale, un appel d’API en lecture équivaut à 1 point et un appel d’API en écriture équivaut à 3 points, et lorsque vous atteignez l’indice maximal, nous déclenchons une erreur de limitation de bande passante.

  • Si votre application est au niveau développement de l’API Marketing :

    • L’indice maximal est de 60.
    • Le taux de décroissance est de 300 secondes.
    • Vous serez bloqué·e pendant 300 secondes si vous atteignez cet indice maximal.
  • Si votre application est au niveau standard de l’API Marketing :

    • L’indice maximal est de 9 000.
    • Le taux de décroissance est de 300 secondes.
    • Vous serez bloqué·e pendant 60 secondes si vous atteignez cet indice maximal.

Code d’erreur connexe :17, Error subcode: 2446079, Message: User request limit reached. 613, Error subcode: 1487742, Message: There have been too many calls from this ad-account. Please wait a bit and try again.

Plafond de la plateforme Ads Insights

• Le plafond se situe au niveau de l’application.
• Le plafond est déterminé par la capacité de l’infrastructure backend et des services en aval.
• Lorsque votre application dispose d’un plafond, tous les appels de l’API Ads Insights pour l’application sont limités.
• Le plafond au niveau de l’application est appliqué.

Code d’erreur connexe :4, Error subcode: 1504022 or 1504039, Message: There have been too many calls from this app. Wait a bit and try again.

Lorsque cette erreur se produit, réduisez vos appels.

Limites au niveau de l’application

• Le plafond se situe au niveau de l’application.
• Le plafond est déterminé par le nombre total d’utilisateur·ices d’une application.
• Lorsque votre application dispose d’un plafond, tous les appels de l’application sont limités.
• Le plafond au niveau de l’application est appliqué.

Code d’erreur connexe :4, Message: Application request limit reached.

Lorsque cette erreur se produit, réduisez vos appels.

Plafonds BUC (Business Use Case) au niveau du compte publicitaire

Nous calculons cette limite en fonction de votre niveau d’accès pour l’API Marketing et votre application.

• Le plafond se situe au niveau du compte publicitaire et le quota est calculé en fonction de votre niveau d’accès pour l’API Publicités pour applications.
• ads_management - Pour chaque compte publicitaire sur une période d’une heure : (100 000 si votre application est au niveau standard de l’API Marketing ou 300 si votre application est au niveau développement) + 40 * nombre de publicités actives.
• custom_audience - Pour chaque compte publicitaire sur période d’une heure : pas plus de 700 000. Pas moins de 190 000 si votre application est au niveau standard de l’API Marketing ou 5 000 si votre application est au niveau développement + 40 * nombre d’audiences personnalisées actives.
• ads_insights - Pour chaque compte publicitaire sur une période d’une heure : (190 000 si votre application est au niveau standard de l’API Ads ou 600 si votre application est au niveau développement) + 400 * nombre de publicités actives - 0,001 * erreurs d’utilisateur·ice.
• Gestion de catalogue - Pour chaque compte publicitaire sur une période d’une heure : 20 000 + 20 000 * log2(utilisateur·ices uniques).
• Lot de catalogues - Pour chaque compte publicitaire sur une période d’une heure : 200 + 200 * log2(utilisateur·ices uniques).
• Le plafond de l’API Marketing peut également être déterminé par le temps CPU total et le temps de mur total sur votre compte publicitaire. Vous disposerez d’un quota plus important si votre application dispose de l’accès standard à l’API Marketing. Pour en savoir plus, consultez l’en-tête HTTP [X-Business-Use-Case](/docs/graph-api/overview/rate-limiting/#headers-2) et la section Plafonds Business Use Case.

Code d’erreur connexe :80000, 80003, 80004, 80014, Message: There have been too many calls from this ad-account. Wait a bit and try again. For more info, please refer to https://developers.facebook.com/docs/graph-api/overview/rate-limiting.

Vérifiez le point de terminaison de l’API et l’en-tête HTTP X-Business-Use-Case pour confirmer le type de limitation de bande passante. Pour plus de détails, reportez-vous à Plafonds BUC (Business Use Case). Lorsque cette erreur se produit, réduisez les modifications apportées au compte publicitaire.

Limites de dépense publicitaire au niveau du compte publicitaire

Nous limitons votre capacité à modifier les limites de dépense de votre compte à 10 fois par jour pour assurer la performance de diffusion des publicités.

• Le nombre de modifications apportées aux dépenses du compte publicitaire telles que les champs spend_cap et spend_cap_action est limité.

Code d’erreur connexe :17, Error subcode: 1885172, Message: You can only change your account spending limit 10 times per day. Please wait to make more changes.

Limites au niveau de l’ensemble de publicités

Le nombre de modifications apportées aux champs daily_budget et lifetime_budget d’un ensemble de publicités est limité. Pour chaque ensemble de publicités, le budget ne peut être modifié que 4 fois par heure. En cas de dépassement, la modification du budget pour cet ensemble de publicités est bloquée pendant une heure.

Code d’erreur connexe :613, Error subcode: 1487632, Message: You can only change your ad set budget 4 times per hour. Please wait to make more changes.

Lorsque cette erreur se produit, réduisez les modifications apportées à l’ensemble de publicités.

Limites au niveau de la publicité

La création de publicité est limitée pour un compte publicitaire donné en fonction de la limite de dépense quotidienne.

Code d’erreur connexe :613, Error subcode: 1487225, Message: User request limit reached.

Vérifiez le sous-code d’erreur (1487225) et le point de terminaison de l’API pour confirmer le type de limitation de bande passante. Lorsque cette erreur se produit, réduisez les modifications. Pour augmenter votre limite, vous pouvez également augmenter la limite de dépense quotidienne.

Plafonds pour la prévention des abus

Lorsque notre système détecte que certains comptes publicitaires génèrent un volume important de trafic anormal, nous réduisons temporairement le plafond de l’API des comptes anormaux afin de protéger la stabilité du système et de garantir l’expérience des autres utilisateur·ices. Veuillez contacter l’assistance Meta pour obtenir de l’aide.

Code d’erreur connexe :613, Error subcode: null, Message: (#613) Calls to this api have exceeded the rate limit.

La différence avec la limite de niveau API du compte publicitaire est que cette erreur ne contient pas de sous-codes d’erreur. Lorsque cette erreur se produit, vérifiez si une action ne déclenche pas un nombre excessif de requêtes d’API et contactez l’assistance Meta pour obtenir de l’aide.

Gérer les erreurs de limitation de bande passante

Évaluation initiale

Vérifiez le niveau d’accès à l’API Marketing :

Par défaut, les applications ont un accès development_access à l’API Marketing. Pour savoir à quel niveau vous vous situez, vous pouvez accéder au tableau de bord du Contrôle app. Vous êtes dans le niveau de développement de l’accès à l’API Marketing si vous avez un accès standard à la fonctionnalité Accès standard à la gestion des publicités. Vous êtes dans le niveau standard de l’accès à l’API Marketing si vous avez un accès Avancé à la fonctionnalité Accès standard à la gestion des publicités. Vous pouvez également vérifier votre en-tête HTTP et rechercher ads_api_access_tier dans votre en-tête X-Ad-Account-Usage, X-Business-Use-Case ou X-FB-Ads-Insights-Throttle.

Si vous continuez à obtenir des erreurs de plafond, envisagez de mettre à niveau l’accès standard_access de la fonctionnalité Accès standard à la gestion des publicités. Pour passer au niveau standard et obtenir un quota de plafond plus élevé, vous pouvez demander un accès Avancé à la fonctionnalité Accès standard à la gestion des publicités dans votre tableau de bord du Contrôle app.

• Vérifiez les codes d’erreur : déterminez les codes d’erreur spécifiques liés à la limitation de bande passante dans la réponse de l’API.
• Vérifiez les en-têtes HTTP :

  • X-Ad-Account-Usage contient acc_id_util_pct, reset_time_duration et ads_api_access_tier.
  • X-Business-Use-Case contient les informations call_count, total_cputime, total_time et estimated_time_to_regain_access, etc. pour le point de terminaison Business Use Case.
  • X-FB-Ads-Insights-Throttle contient app_id_util_pct, acc_id_util_pct et ads_api_access_tier pour les points de terminaison de l’API Ads Insights.
• Vérifiez l’Espace App : nous fournissons des consoles dans l’Espace App qui permettent aux équipes de développement d’avoir une vision approfondie du système de plafond et les aident à diagnostiquer et à prévenir les problèmes de plafond.

Identifier la cause

• Plafonds : comprenez les plafonds de l’API Marketing Meta pour les différents points de terminaison utilisés et vérifiez si le nombre de requêtes de l’API se situe dans les limites autorisées pour l’application.
• Limites d’utilisation en rafale : vérifiez si les limites d’utilisation en rafale posent des problèmes pendant les périodes d’utilisation intensive. En général, le trafic en rafale entraîne des limites au niveau du compte publicitaire et de l’API (codes d’erreur connexes :17, 613).
• Opérations erronées : déterminez si des opérations erronées déclenchent des requêtes d’API excessives.

Mesures d’atténuation

• Prévenir le trafic en rafale : répartissez les requêtes d’API de manière homogène afin d’éviter la limitation de bande passante causée par un grand nombre d’accès dans un court laps de temps.
• Optimiser les requêtes : combinez plusieurs petites requêtes en lots, soit en lots d’ID, soit en requêtes asynchrones, afin de minimiser le nombre total d’appels de l’API.
• Stratégie de temporisation : mettez en place une stratégie de temporisation exponentielle lors de la réception d’erreurs de limitation de bande passante, en augmentant progressivement le délai entre les tentatives. Vous pouvez également examiner les en-têtes HTTP pour obtenir une estimation du temps de réinitialisation.

Astuces d’atténuation supplémentaires

• Vérifiez si ces appels sont nécessaires et réduisez-les s’ils ne le sont pas.
• Pour les points de terminaison prenant en charge les requêtes asynchrones, tels que l’API Ads Insights, utilisez les requêtes asynchrones pour interroger une grande quantité de données.
• Vous pouvez également essayer de passer une liste d’ID si vous avez besoin d’interroger plusieurs types d’objets publicitaires.
• Pour l’API Ads Insights, utilisez les paramètres de niveau ou le filtrage pour réduire le nombre d’appels.