# Un webhook Sendinblue qui ne parvenait jamais au front headless

> Une automatisation marketing modifiait bien le contenu WordPress, mais le site vitrine découplé n'affichait jamais la mise à jour. Le webhook s'arrêtait avant le front.

- Auteur : WordPress Développement
- Publié le : 2022-12-10
- Mis à jour le : 2026-09-30
- Catégorie : Headless & API
- URL : https://www.wpmoderne.fr/headless/webhook-sendinblue-jamais-parvenu-front-headless/

## L’essentiel

- Le journal du webhook côté fournisseur ne suffit pas à garantir la réception
- Une réponse HTTP 200 trop précoce masque un traitement resté incomplet
- Chaque étape du relais doit produire une trace vérifiable

« Webhook delivered — 200 OK » : c'est ce qu'affichait le tableau de bord Sendinblue pour chaque déclenchement de l'automatisation censée republier une page promotionnelle sur le site vitrine découplé d'une enseigne de prêt-à-porter, après chaque campagne d'e-mailing. Pourtant, la page en question restait figée sur son ancienne version, parfois plusieurs jours durant, sans qu'aucune erreur ne remonte nulle part.

## Symptôme : un webhook « livré », un contenu jamais rafraîchi

L'automatisation Sendinblue, déclenchée à l'envoi d'une campagne, appelait un endpoint REST personnalisé côté WordPress chargé de mettre à jour un champ ACF sur une page promotionnelle, puis de notifier le front Gatsby pour déclencher un nouveau build via un webhook Netlify. Le tableau de bord Sendinblue confirmait systématiquement une livraison réussie du premier appel, avec un code 200. Le contenu WordPress lui-même était bien à jour après vérification manuelle dans l'administration. Seul le site public restait figé.

## Diagnostic : où s'arrêtait réellement la chaîne

Le point de blocage ne se trouvait ni côté Sendinblue, ni côté mise à jour du contenu WordPress : il se trouvait dans l'étape intermédiaire, silencieuse, entre les deux. L'endpoint REST personnalisé, une fois le champ ACF mis à jour, appelait `wp_remote_post` vers le webhook de build Netlify — mais renvoyait sa réponse HTTP 200 à Sendinblue **avant** d'attendre le résultat de cet appel, avec un paramètre `'blocking' => false` :

```
function traiter_webhook_sendinblue(WP_REST_Request $request) {
    update_field('promo_active', true, $request->get_param('page_id'));

    wp_remote_post('https://api.netlify.com/build_hooks/xxxx', [
        'blocking' => false, // <- l'appel part, sans jamais verifier son issue
        'timeout'  => 0.01,
    ]);

    return rest_ensure_response(['status' => 'ok']);
}
```

Avec `'blocking' => false` et un délai d'expiration de dix millisecondes, la requête vers Netlify était souvent interrompue avant même d'avoir quitté le serveur WordPress — un choix initialement fait pour répondre rapidement à Sendinblue, mais qui sacrifiait la fiabilité de l'étape suivante sans que personne ne s'en aperçoive, faute de journal associé à cet appel spécifique.

## Correctif : rendre l'appel vérifiable, pas silencieux

La correction a consisté à séparer les deux préoccupations : répondre vite à Sendinblue reste nécessaire, mais l'appel vers Netlify doit être fiabilisé indépendamment, avec un journal explicite de son résultat plutôt qu'un envoi tiré à l'aveugle.

> L'essentiel à retenir : Le journal du webhook côté fournisseur ne suffit pas à garantir la réception ; Une réponse HTTP 200 trop précoce masque un traitement resté incomplet ; Chaque étape du relais doit produire une trace vérifiable

```
function traiter_webhook_sendinblue(WP_REST_Request $request) {
    $page_id = $request->get_param('page_id');
    update_field('promo_active', true, $page_id);

    // Reponse immediate a Sendinblue, sans dependre du declenchement Netlify.
    $response = rest_ensure_response(['status' => 'ok']);

    // Declenchement du build en tache differee, avec journal.
    wp_schedule_single_event(time(), 'declencher_build_netlify', [$page_id]);

    return $response;
}

add_action('declencher_build_netlify', function ($page_id) {
    $resultat = wp_remote_post('https://api.netlify.com/build_hooks/xxxx', [
        'blocking' => true,
        'timeout'  => 10,
    ]);

    if (is_wp_error($resultat) || wp_remote_retrieve_response_code($resultat) >= 300) {
        error_log(sprintf(
            'Echec declenchement build Netlify pour page %d : %s',
            $page_id,
            is_wp_error($resultat) ? $resultat->get_error_message() : wp_remote_retrieve_response_code($resultat)
        ));
    }
}, 10, 1);
```

L'appel vers Netlify s'exécute désormais dans une tâche différée avec un délai d'expiration réaliste et un résultat consigné, tout en laissant la réponse à Sendinblue rester immédiate, comme avant.

## Prévention : ne jamais faire confiance à un statut « livré » du fournisseur

- Un webhook marqué « livré » côté fournisseur signifie seulement que le premier appel a réussi, jamais que la chaîne complète qui en découle a fonctionné.
- Un appel non bloquant avec un délai d'expiration trop court équivaut, en pratique, à un envoi sans garantie.
- Chaque étape d'un relais de webhook mérite son propre journal, vérifiable indépendamment des autres.

> Un webhook « réussi » ne raconte que la première moitié de l'histoire. Tout ce qui se passe après la réponse HTTP mérite sa propre vérification, sans quoi la panne se cache exactement là où personne ne regarde.

## En résumé

Cette panne n'avait rien à voir avec la délivrabilité des e-mails Sendinblue ni avec la configuration de l'automatisation marketing elle-même : elle se logeait dans un choix technique isolé, un appel non bloquant avec un délai trop court, invisible tant que personne ne cherchait spécifiquement à vérifier cette étape intermédiaire du relais.