Publiée le 5 mai 2020 | Disponible jusqu’au 4 août 2022 | Publication de blog
Cette modification concerne toutes les versions.
Deux nouveaux champs ont été ajoutés à la version 2 de l’extension Facebook Business.
ID de compte publicitaire (ad_account_id
) : représente l’ID de compte publicitaire sélectionné par l’utilisateur·ice dans FBE. Ce compte publicitaire peut être utilisé pour gérer les publicités si votre application dispose des autorisations ads_management
.
ID de catalogue (catalog_id
) : ID de catalogue sélectionné par l’utilisateur·ice dans FBE. Cet ID peut être utilisé pour gérer le catalogue produits.
Cette modification concerne la version 7.0+.
Vous pouvez maintenant demander le champ timestamp
sur un contenu multimédia Instagram renvoyé par les requêtes Recherche de hashtags GET /{ig-hashtag-id}/top_media
et GET /{ig-hashtag-id}/recent_media
. Par exemple : GET /{ig-hashtag-id}/top_media?fields=timestamp
.
Cette modification s’applique à la version 7.0+ et s’appliquera à toutes les versions le 2 novembre 2020.
Quand une nouvelle conversation est démarrée ou qu’une conversation existante se poursuit via le plugin de discussion clientèle, les notifications webhook initiales messaging_postbacks
et messaging_referrals
contiennent un ID user_ref
anonyme plutôt que l’ID spécifique à la page (PSID). Dès que l’utilisateur·ice envoie un message, les notifications webhook suivantes contiennent son PSID.
Cette modification concerne la version 7.0+.
La propriété home_url
dans les profils Messenger de la Page a été abandonnée pour toutes les opérations (GET
, POST
et DELETE
).
Cette modification s’applique à la version 7.0 et s’appliquera à toutes les versions le 3 août 2020.
POST /{user-id}/{open-graph-action-type-id}
Cette modification s’applique à la version 7.0+ et s’appliquera à toutes les versions le 5 mai 2021.
Le 1ᵉʳ mai 2018, l’API Pages a commencé à renvoyer des ID utilisateur spécifiques à une Page (PSID) plutôt que des ID utilisateur spécifique à une app (ASID) et ce, pour toutes les nouvelles applications. Les applications créées avant cette date ont continué à recevoir des ASID, sauf s’il avait été convenu qu’elles recevraient des PSID. Toutes les applications recevront maintenant des PSID de la part de l’API Pages.
L’API ID page spécifique vous permet de faire correspondre les ASID avec leurs PSID équivalents. Cette API a été abandonnée dans la version 7.0 et les versions ultérieures, mais elle peut être utilisée dans les versions précédentes jusqu’au 5 mai 2021.
Ces modifications s’appliquent à la version 7.0+ et s’appliqueront à toutes les versions le 3 août 2020.
Les points de terminaison suivants ne sont plus utilisés :
L’autorisation manage_pages
a été abandonnée et remplacée par quatre nouvelles autorisations :
L’autorisation publish_pages
a été abandonnée et remplacée par deux nouvelles autorisations :
Les applications qui ont déjà été approuvées pour manage_pages
et/ou publish_pages
feront l’objet d’une migration pour utiliser ces nouvelles autorisations à partir du 1ᵉʳ juin 2020.
Concernant les applications qui ont été envoyées, mais qui n’ont pas encore été examinées pour manage_pages
et/ou publish_pages
, le processus d’examen se poursuivra normalement. Une fois approuvées, ces applications feront l’objet d’une migration pour utiliser les nouvelles autorisations d’ici le 1ᵉʳ juin 2020.
Pour demander ou redemander à utiliser ces autorisations de Page avant le 1ᵉʳ juin 2020, sélectionnez les autorisations qui apparaissent dans votre Espace App, manage_pages
et/ou publish_pages
, ou encore les nouvelles autorisations. Si nécessaire, votre application fera automatiquement l’objet d’une migration vers ces nouvelles autorisations d’ici le 1ᵉʳ juin 2020.
Après le 1ᵉʳ juin 2020, manage_pages
et publish_pages
ne seront plus disponibles dans l’Espace App, dans Contrôle app > Autorisations et fonctionnalités.
Les autorisations manage_pages
et publish_pages
seront entièrement abandonnées en mai 2022. Les modifications devront être apportées à votre code avant cette date.
Veuillez consulter le Changelog du SDK pour iOS et le Changelog du SDK pour Android pour en apprendre davantage sur les prochains changements importants concernant ces SDK.
Ces modifications s’appliquent à la version 7.0+ et s’appliqueront à toutes les versions le 3 août 2020.
Les points de terminaison suivants ne sont plus utilisés :
Publiée le 5 mai 2020 | Disponible jusqu’au 3 mars 2021 | Publication de blog
Cette modification concerne la version 7.0+.
Pour une campagne publicitaire spécifique, vous ne pouvez plus définir les paramètres lifetime_budget
et spend_cap
en même temps. Vous pouvez uniquement sélectionner lifetime_budget
.
Le budget global d’une campagne est réparti tout au long de celle-ci. Quand vous utilisez le paramètre lifetime_budget
au niveau de la campagne, les informations concernant le plafond de dépense sont déjà incluses. Il n’y a ainsi aucune raison d’ajouter un deuxième plafond de dépense.
Vous pouvez continuer à utiliser le paramètre spend_cap
pour les campagnes sans optimisation de budget.
Cette modification concerne la version 7.0+.
Le paramètre special_ad_category
défini sur le point de terminaison POST /act_<AD_ACCOUNT_ID>/campaigns
a été abandonné et remplacé par un nouveau paramètre special_ad_categories
.
Le nouveau paramètre special_ad_categories
est obligatoire et accepte un tableau. Si vous utilisez le paramètre special_ad_category
, il continuera à renvoyer une chaîne. Toutefois, nous vous recommandons d’utiliser GET /{campaign-id}?fields=special_ad_categories
pour obtenir un tableau en retour.
Pour en savoir plus, consultez la section Catégorie publicitaire spéciale.
Pour en savoir plus, consultez la page d’aide Choisir une catégorie publicitaire spéciale.
Cette modification concerne la version 7.0+.
Le paramètre budget_rebalance_flag
a été abandonné. Nous vous recommandons d’utiliser en remplacement l’optimisation du budget de campagne.
Cette modification concerne la version 7.0+.
GET /{atlas-ad-campaign-id}/cumulative_edited_date
Cette modification concerne la version 7.0+.
Le paramètre cpas_parent_catalog_settings
sur l’arête POST /PRODUCT_CATALOG_ID
est abandonné pour les applications tierces.