Planifier un SMS

Définissez sending_type: "scheduled" et passez un tableau scheduled_dates. Chaque entrée est une paire (date, time) dans le fuseau horaire marchand configuré. La passerelle accepte jusqu’à 20 dates par requête.

Un seul moment futur

cURL

curl $BASE_URL/api/v1/lisoloo/sms-api/send \
  -X POST \
  -H "app-key: $LISOLOO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "to": ["+243998857000"],
    "message": "Votre rendez-vous est demain à 09:00.",
    "sender_id": "CLINIC",
    "sending_type": "scheduled",
    "scheduled_dates": [
      { "date": "2026-06-01", "time": "08:00" }
    ]
  }'

Python

requests.post(SEND_URL, headers=HEADERS, json={
    "to":        ["+243998857000"],
    "message":   "Votre rendez-vous est demain à 09:00.",
    "sender_id": "CLINIC",
    "sending_type": "scheduled",
    "scheduled_dates": [
        {"date": "2026-06-01", "time": "08:00"},
    ],
}).raise_for_status()

JavaScript

await fetch(SEND_URL, {
  method: "POST",
  headers: HEADERS,
  body: JSON.stringify({
    to: ["+243998857000"],
    message: "Votre rendez-vous est demain à 09:00.",
    sender_id: "CLINIC",
    sending_type: "scheduled",
    scheduled_dates: [
      { date: "2026-06-01", time: "08:00" },
    ],
  }),
});

Plusieurs moments

Chaque entrée de scheduled_dates est une expédition séparée. L’exemple ci-dessous envoie le même message deux fois — rappel du matin et du soir.

{
  "to": ["+243998857000"],
  "message": "N'oubliez pas de prendre votre médicament.",
  "sending_type": "scheduled",
  "scheduled_dates": [
    { "date": "2026-06-01", "time": "08:00" },
    { "date": "2026-06-01", "time": "20:00" },
    { "date": "2026-06-02", "time": "08:00" },
    { "date": "2026-06-02", "time": "20:00" }
  ]
}

Cela produit 4 dates × 1 destinataire = 4 SMS, facturés à l’avance.

Le coût est réservé à la soumission

Le total_cost complet pour chaque expédition planifiée est déduit de votre solde immédiatement quand POST /send retourne 201. Si votre solde chute ensuite sous le montant réservé (à cause d’autres envois), les expéditions planifiées partent quand même — la réserve est collante.

Sémantique des fuseaux horaires

date et time sont interprétés dans le fuseau marchand configuré sur votre compte (défaut : Africa/Kinshasa, UTC+1). Pour envoyer à un instant UTC précis, faites la conversion côté votre avant soumission.

Si le fuseau marchand observe l’heure d’été, les heures ambiguës (le fall-back) sont résolues comme la première occurrence. Le gap de spring-forward (par exemple 02:30 un jour DST de printemps qui n’existe pas) est rejeté avec 1110 INVALID_FIELD_FORMAT.

Envoyez toujours en UTC si vous pouvez

Stockez et calculez les plannings en UTC, puis convertissez en chaînes locales marchand seulement au moment de remplir le corps de la requête. Cela isole votre logique des changements de fuseau côté serveur.

Ce que vous ne pouvez pas faire

• Mélanger sending_type: "scheduled" avec recurring_schedule. Choisissez l’un.
• Planifier plus de 20 paires (date, time) en une requête. Utilisez recurring pour les cadences plus hautes.
• Planifier une date dans le passé. Les entrées passées sont rejetées à la soumission.

Voir aussi

• Types d’envoi — schéma et règles au niveau du champ
• SMS récurrents — pour les patterns répétitifs
• Vérifier le statut — suivre le lot à mesure qu’il s’expédie