Mise à jour

POST https://api.pushwoosh.com/messaging/v2/update

Remplace un message créé précédemment, identifié par son message_code, par une nouvelle définition. Le remplacement est un remplacement complet, pas un correctif : la nouvelle définition est appliquée exactement telle qu’elle est envoyée, et le message_code ne change pas.

La mise à jour n’est disponible que lorsque le message est encore en attente (pending) — programmé pour un envoi futur et pas encore pris en charge pour traitement ou livraison.

Pour vérifier si un message est toujours dans un état qui permet sa mise à jour, consultez la section Vérifier l’état du message.

Requête

Authentifiez-vous avec votre jeton d’API Serveur (Server API token) dans l’en-tête Authorization: Token <API_TOKEN>.

Champ	Type	Requis	Description
`message_code`	chaîne	Oui	Code de message (Message code) du message à mettre à jour, tel que retourné par `Notify` dans `result.message_code`.
`request`	objet	Oui	La nouvelle définition complète du message. De la même forme que le corps de la requête `Notify` — un objet `segment` ou `transactional`. Validé exactement comme `Notify`.

Exemple de requête

Reprogrammer un message de segment et modifier son contenu :

curl -X POST https://api.pushwoosh.com/messaging/v2/update \
  -H "Authorization: Token YOUR_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "message_code": "XXXX-XXXXXXXX-XXXXXXXX",
    "request": {
      "segment": {
        "application": "XXXXX-XXXXX",
        "platforms": ["IOS", "ANDROID"],
        "code": "active_users",
        "payload": {
          "content": {
            "localized_content": {
              "en": {
                "ios":     { "body": "Updated message" },
                "android": { "body": "Updated message" }
              }
            }
          }
        },
        "schedule": { "at": "2026-05-02T12:00:00Z" },
        "message_type": "MESSAGE_TYPE_MARKETING"
      }
    }
  }'

Réponse

En cas de succès, renvoie un HTTP 200 avec le résultat du message mis à jour. Le message_code reste inchangé.

{
  "result": {
    "message_code": "XXXX-XXXXXXXX-XXXXXXXX",
    "unknown_identifiers": []
  }
}

message_code (chaîne) : le même code que celui qui a été passé dans la requête.
unknown_identifiers (tableau de chaînes) : les identifiants dans la nouvelle définition qui n’ont pas été trouvés, le cas échéant (voir Notify).

Erreurs

Les erreurs utilisent l’enveloppe d’erreur standard de gRPC-Gateway : { "code": ..., "message": ..., "details": [...] }.

Statut HTTP	Condition
`400`	Le `message_code` est manquant.
`400`	La nouvelle définition de la `request` est manquante ou invalide (elle est validée exactement comme `Notify`).
`400`	Le message n’est pas dans un état qui permet sa mise à jour (il n’est plus en attente (`pending`)).
`403`	Le message appartient à un autre compte.
`404`	Aucun message n’existe pour le `message_code` donné.
`500`	Une erreur interne s’est produite lors du chargement du message ou de l’application de la mise à jour. Réessayez la requête.

Exemple

La mise à jour d’un message qui n’existe plus renvoie un HTTP 404 :

{
  "code": 5,
  "message": "message not found",
  "details": []
}

Vérifier l’état du message

Avant la mise à jour, vous pouvez vérifier si un message est toujours dans un état qui permet sa mise à jour. En plus de lire la colonne Statut dans le tableau des messages du Panneau de Contrôle (Campagnes → Messages uniques), vous pouvez interroger l’état par programmation avec messages:list :

Passez le message_code dans le tableau filters.messages_codes (en même temps que le filters.application requis).
Lisez le champ status de l’entrée correspondante dans items[].

Sujets connexes

Notify

Cancel

Statistiques des messages

Aperçu de l'API de messagerie v2

Migration depuis la v1