Présentation de la version 25.0 des API Graph et Marketing

Voici les principales modifications apportées aux API Graph et Marketing pour la version 25. Consultez notre changelog pour obtenir la liste complète et détaillée des modifications.

Mises à jour générales

API Graph : présentation de l’indicateur Spectateurs de la Page

D’ici la fin du mois de juin 2026, nous prévoyons d’introduire l’indicateur Spectateurs de la Page dans l’API Graph. Celui-ci vise à remplacer l’indicateur Couverture et à fournir une mesure cohérente sur les différentes plateformes (Facebook et Instagram) du nombre de personnes qui ont vu un contenu. Les équipes de développement doivent commencer à planifier la migration vers les spectateur·ices afin de garantir l’accès aux statistiques d’audience.

Qu’est-ce qui change ?

Les indicateurs relatifs aux spectateur·ices seront disponibles dans les statistiques de Page et les statistiques des stories.

Statistiques sur les publications/Pages

• GET {page-id}/insights/page_total_media_view_unique*
• GET {post-id}/insights/post_total_media_view_unique*

Statistiques des stories

• Un nouvel indicateur sera ajouté.
• GET {stories-id}/insights/metric
  • PAGE_STORY_TOTAL_MEDIA_VIEW_UNIQUE

Les API Graph ci-dessus seront disponibles après le lancement de la version 25. Nous recommandons aux équipes de développement de consulter le changelog de l’API Graph pour obtenir les informations les plus récentes.

Mise à jour du certificat mTLS Webhooks

À partir du 31 mars 2026, Meta commencera à signer les certificats mTLS Webhooks avec une autre autorité de certification lui appartenant.

Qu’est-ce que cela signifie pour les équipes de développement ?

Si vos serveurs sont configurés pour exiger et vérifier le certificat mTLS Webhooks, vous devez faire confiance à la nouvelle autorité de certification (AC) Meta. Si vous ne mettez pas à jour votre trust store dans le délai imparti, les liaisons TLS échoueront, et vos serveurs ne recevront plus aucun évènement webhook.

Action requise : mise à jour de votre trust store

Pour garantir la réception ininterrompue des webhooks, vous devez :

1. Télécharger le certificat d’AC racine Meta : accédez à Démarrer avec les webhooks et téléchargez le fichier intitulé meta-outbound-api-ca-2025-12.pem.
   L’AC racine signera le certificat feuille qui sera présenté dans les demandes Webhooks.
2. L’ajouter à votre trust store : ajoutez ce certificat au trust store de tous les serveurs recevant des webhooks.
3. Conserver le certificat actuel : vous devez ajouter le nouveau certificat à votre trust store tout en maintenant votre certificat actuel actif.

Important : n’attendez pas la date d’échéance. Nous vous recommandons d’ajouter le nouveau certificat à votre trust store dès maintenant afin de garantir une transition fluide le 31 mars.

Date limite : avant le 31 mars 2026.

Pourquoi ce changement ?

Le certificat mTLS Webhooks actuel est signé par l’AC racine DigiCert. Étant donné que DigiCert abandonne l’extension EKU d’authentification client, le certificat ne peut pas être renouvelé avec cette AC racine et expire le 15 avril 2025.

Par conséquent, le nouveau certificat mTLS Webhooks sera signé par une autorité de certification racine interne à Meta. Il portera le même nom usuel (client.webhooks.fbclientcerts.com) que le certificat actuel.

La documentation publique concernant le certificat mTLS Webhooks a été mise à jour avec une notification concernant ce changement. Les informations techniques complètes de la documentation seront mises à jour définitivement en avril 2026, une fois la transition terminée.

Abandons et modifications importantes

Amélioration des messages d’erreur pour l’API Ads Insights Async

Nous cherchons continuellement à améliorer l’expérience de développement avec nos API. Afin d’offrir davantage de transparence et de permettre aux développeur·ses de créer des applications plus résilientes, nous améliorons les rapports d’erreur pour le point de terminaison GET {AD_REPORT_RUN_ID} de l’API Ads Insights Async.

À partir de la version 25.0 de l’API Graph, qui sera publiée le 18 février 2026, les équipes de développement auront accès à des informations détaillées sur les erreurs en cas d’échec d’un rapport asynchrone. Cela permettra de faciliter le diagnostic des erreurs et d’améliorer l’efficacité des intégrations d’API. Pour les équipes de développement qui ont actuellement accès au champ error_code, le type passera de uint à int.

Qu’est-ce qui change ?

Nous avons ajouté les nouveaux champs par défaut suivants à la réponse du point de terminaison GET {AD_REPORT_RUN_ID} de l’API Ads Insights Async pour toutes les applications :

• error_code : code d’erreur. Remarque : le champ passera de uint à int pour les équipes de développement qui y ont actuellement accès.
• error_message : message correspondant à error_code.
• error_subcode : sous-code spécifique de l’erreur.
• error_user_title : titre convivial du sous-code d’erreur.
• error_user_msg : message convivial détaillant le sous-code d’erreur.

Ces champs sont renseignés si l’exécution d’un rapport échoue. Nous vous invitons à examiner l’intégration de votre API pour garantir sa compatibilité avec les nouveaux champs par défaut de la réponse.

Cette mise à jour sera publiée avec la prochaine version de l’API Graph. Nous recommandons aux développeur·ses de consulter le changelog de l’API Graph pour obtenir les dernières informations. La documentation de développement a également été mise à jour afin de refléter ces changements.

API Graph : abandon du paramètre de requête des métadonnées

À partir de la version 25 de l’API Graph, nous abandonnons le paramètre de requête metadata=1. Ce paramètre était auparavant utilisé pour renvoyer des métadonnées sur les champs et les connexions d’un nœud dans les réponses d’API. Cette fonctionnalité est peu utilisée et va être abandonnée afin de simplifier la plateforme. Le paramètre metadata sera ensuite ignoré dans les demandes d’API.

Les développeur·ses qui utilisent actuellement metadata=1 doivent consulter notre documentation API officielle pour découvrir les champs et les connexions disponibles pour chaque type de nœud.

Qu’est-ce qui change ?

Avant (jusqu’à la version 24) :

L’ajout de ?metadata=1 à une requête de l’API Graph renvoyait des métadonnées supplémentaires sur le nœud, y compris les champs et les connexions disponibles.

Après (à partir de la version 25) :

Le paramètre metadata=1 sera ignoré. Les demandes qui incluent ce paramètre continueront à renvoyer des réponses standard sans métadonnées. Il n’y aura ni échecs, ni perturbations : vos requêtes n’entraîneront pas d’erreur et ne s’interrompront pas si elles incluent metadata=1 ; le paramètre n’aura tout simplement aucun effet.

API Graph : abandon des indicateurs de couverture/d’impressions de Page

En juin 2026, nous prévoyons d’abandonner les indicateurs Couverture de la publication/Page, Impressions de la vidéo et Impressions de la story dans l’API Graph. Ces anciens indicateurs ne sont plus visibles dans nos outils statistiques, mais ils étaient encore disponibles via les API.

Afin d’aligner nos produits et nos API sur un cadre d’indicateurs unique et cohérent, et d’améliorer la fiabilité globale du système, nous abandonnons ces anciens indicateurs. Les développeur·ses devront alors migrer vers les nouveaux indicateurs Vues du contenu multimédia et Spectateurs du contenu multimédia, qui remplacent les anciens concepts d’impressions, de couverture et de spectateur·ices de vidéos.

Qu’est-ce qui change ?

Les indicateurs suivants seront abandonnés en juin 2026 pour toutes les versions de l’API. Nous recommandons aux développeur·ses de consulter le changelog de l’API Graph pour obtenir les dernières informations :

Couverture de la publication/Page

• GET {page-id}/insights/page_impressions_unique*
• GET {page-id}/insights/page_impressions_paid_unique*
• GET {page-id}/insights/page_impressions_viral_unique*
• GET {page-id}/insights/page_impressions_nonviral_unique*
• GET {page-id}/insights/page_posts_impressions*
• GET {page-id}/insights/page_posts_impressions_unique*
• GET {page-id}/insights/page_posts_impressions_paid*
• GET {page-id}/insights/page_posts_impressions_paid_unique*
• GET {page-id}/insights/page_posts_impressions_organic_unique*
• GET {page-id}/insights/page_posts_served_impressions_organic_unique*
• GET {page-id}/insights/page_posts_impressions_viral*
• GET {page-id}/insights/page_posts_impressions_viral_unique*
• GET {page-id}/insights/page_posts_impressions_nonviral*
• GET {page-id}/insights/page_posts_impressions_nonviral_unique*
• GET {post-id}/insights/post_impressions_unique*
• GET {post-id}/insights/post_impressions_paid_unique*
• GET {post-id}/insights/post_impressions_fan_unique*
• GET {post-id}/insights/post_impressions_organic_unique*
• GET {post-id}/insights/post_impressions_viral_unique*
• GET {post-id}/insights/post_impressions_nonviral_unique*
• GET {post-id}/insights/post_impressions_nonviral_unique*

Impressions de la vidéo

• GET {video-id}/video_insights/post_impressions_unique
• GET {video-id}/video_insights/total_video_impressions
• GET {video-id}/video_insights/total_video_impressions_unique
• GET {video-id}/video_insights/total_video_impressions_paid_unique
• GET {video-id}/video_insights/total_video_impressions_paid
• GET {video-id}/video_insights/total_video_impressions_organic_unique
• GET {video-id}/video_insights/total_video_impressions_organic
• GET {video-id}/video_insights/total_video_impressions_viral_unique
• GET {video-id}/video_insights/total_video_impressions_viral
• GET {video-id}/video_insights/total_video_impressions_fan_unique
• GET {video-id}/video_insights/total_video_impressions_fan
• GET {video-id}/video_insights/total_video_impressions_fan_paid_unique
• GET {video-id}/video_insights/total_video_impressions_fan_paid

Impressions de la story

• Deux indicateurs seront remplacés.
• GET {stories-id}/insights/metric
  • PAGE_STORY_IMPRESSIONS_BY_STORY_ID
  • PAGE_STORY_IMPRESSIONS_BY_STORY_ID_UNIQUE

Nous recommandons d’utiliser les indicateurs suivants à la place :

• GET {page-id}/insights/page_total_media_view_unique
• GET {post-id}/insights/post_total_media_view_unique

Pour les répartitions entre la couverture organique et la couverture payée en particulier, nous recommandons d’utiliser les indicateurs suivants, qui offrent des statistiques sensiblement similaires :

• GET {page-id}/insights/page_media_view
• GET {post-id}/insights/post_media_view

API Graph : abandon des indicateurs de spectateur·ices à 3 secondes

En juin 2026, nous prévoyons de supprimer les indicateurs de spectateur·ices à 3 secondes. Ces anciens indicateurs ne sont plus visibles dans nos outils statistiques, mais ils étaient encore disponibles via l’API Graph.

Afin d’aligner nos produits et nos API sur un cadre d’indicateurs unique et cohérent, et d’améliorer la fiabilité globale du système, nous abandonnons ces anciens indicateurs. Les développeur·ses devront alors migrer vers les nouveaux indicateurs Vues du contenu multimédia et Spectateurs du contenu multimédia, qui remplacent les anciens concepts d’impressions, de couverture et de spectateur·ices de vidéos.

Qu’est-ce qui change ?

Les indicateurs suivants seront abandonnés en juin 2026 pour toutes les versions de l’API. Nous recommandons aux développeur·ses de consulter le changelog de l’API Graph pour obtenir les dernières informations :

• GET {page-id}/insights/page_video_views_unique
• GET {post-id}/insights/post_video_views_organic_unique
• GET {post-id}/insights/post_video_views_paid_unique
• GET {post-id}/insights/post_video_views_unique
• GET {video-id}/video_insights/total_video_views_organic_unique
• GET {video-id}/video_insights/total_video_views_paid_unique
• GET {video-id}/video_insights/total_video_views_unique

Nous recommandons d’utiliser les indicateurs suivants à la place :

• GET {page-id}/insights/page_total_media_view_unique
• GET {post-id}/insights/post_total_media_view_unique

Pour les répartitions entre les spectateur·ices à 3 secondes organiques et les spectateur·ices à 3 secondes payés en particulier, nous recommandons d’utiliser les indicateurs suivants, qui offrent des statistiques sensiblement similaires :

• GET {page-id}/insights/page_media_view
• GET {post-id}/insights/post_media_view

API Marketing : abandon des campagnes de shopping Advantage+ et des campagnes d’application Advantage+

L’unification de l’automatisation permet aux campagnes d’application, de ventes et de prospects de bénéficier par défaut d’une configuration Advantage+ optimale et axée sur l’automatisation. Les annonceurs et les partenaires disposent ainsi d’un accès simplifié aux produits d’automatisation les plus récents et les plus performants de Meta. Nous procédons à un abandon progressif des anciennes API et à une migration vers la nouvelle configuration d’unification de l’automatisation Advantage+ pour les développeur·ses d’API Marketing.

À partir de la version 25.0 (18 février 2026), les campagnes de shopping Advantage+ et les campagnes d’application Advantage+ ne pourront plus être créées ou mises à jour à l’aide de l’API Marketing. Cette modification s’appliquera à toutes les versions de l’API Marketing 90 jours plus tard (19 mai 2026).

Dans la version 26.0 (prévue pour septembre 2026), toutes les campagnes de shopping Advantage+ et les campagnes d’application Advantage+ seront mises en pause.

Les campagnes de shopping Advantage+ et les campagnes d’application Advantage+ utilisant des limites de budget de clientèle existante (ECBC) resteront modifiables jusqu’à la version 26.0. Cette fonctionnalité n’est pas disponible avec les campagnes Advantage+. Pour répliquer les campagnes ECBC, les développeur·ses doivent appliquer l’une des méthodes suivantes avant la version 26.0 :

• Duplication manuelle : ouvrez une campagne de shopping ou d’application Advantage+ existante avec ECBC dans le Gestionnaire de publicités. Vous serez invité·e à dupliquer la campagne. Cette étape en un clic permet de créer une campagne qui reproduit la configuration de la campagne existante.
• Répliquer les campagnes ECBC à l’aide de l’API : suivez les instructions fournies dans la documentation développeur pour répliquer les campagnes en utilisant l’API, ici.
• Demander une migration groupée au niveau du compte publicitaire : pour les partenaires gérés, nous proposons une action unique pour repliquer toutes les campagnes ECBC à une date convenue. Contactez votre interlocuteur·ice Meta et fournissez-lui les ID des comptes ainsi que la date de migration souhaitée.

Remarque : toutes les duplications de campagnes ECBC donneront lieu à un nouvel ID de campagne.

Ce changement concerne les points de terminaison suivants :

• POST /{campaign-id}
• POST /{campaign-id}/copies

Consultez la documentation développeur et les questions/réponses mises à jour pour voir tous les détails de ce changement.

Lien vers la documentation développeur

• Documentation développeur - Expérience de campagne Advantage+ pour les ventes, les applications et les prospects

Lien vers l’article d’aide sur la fonctionnalité

• Pages d’aide - Campagnes Advantage+
• Pages d’aide - Catégories publicitaires spéciales

Abandon de certaines versions d’API :

Dans le cadre du calendrier de gestion des versions de Facebook pour l’API Graph et l’API Marketing, veuillez noter les abandons prévus prochainement :

API Graph

• 21 mai 2026 : abandon et retrait de la plateforme de la version 19 de l’API Graph
• 24 septembre 2026 : abandon et retrait de la plateforme de la version 20 de l’API Graph

Afin d’éviter toute interruption d’activité, nous vous recommandons de migrer tous les appels vers la version la plus récente de l’API que nous avons lancée aujourd’hui.