Gestion de l’URL de Rappel (Callback)

Lorsque l’état d’une transaction est mis à jour dans notre système, une notification est envoyée au client via une requête POST à l’URL de callback spécifiée. Ce document décrit comment les notifications sont gérées et les différents statuts qui peuvent être envoyés.

Notification de Mise à Jour

Lorsque l’état d’une transaction change, notre système envoie une notification à l’URL de callback fournie par le client.

Les données envoyées dans la notification incluent:

status : Le statut de la transaction.
orderid : Identifiant unique de la transaction.
external_id : Identifiant métier fourni par le client.
content : Contenu du fichier pré-état daté (encodé en base64, utilisé uniquement lorsque le statut est done).
registration_id : Identifiant national du syndic (utilisé uniquement lorsque le statut est done).
documents : Documents annexes au pré-état daté (utilisés uniquement lorsque le statut est done).

Notes

Les champs registration_id et documents sont conditionnels.
Ils ne sont fournis que si les conditions contractuelles associées au compte client le permettent.

Exemple de Notification

{
  "status": "done",
  "orderid": "order_id_12345",
  "content": "JVBERi0xLjMKJeLjz9MNCjEgMCBvYmoKPDwvTW9k...",
  "external_id": "1221"

  "registration_id": "AA-XXX-XX",
  "documents": [
    {
     "id": 41,
     "doctype": 2,
     "delivered": "2025-03-12",
     "comment': "", 
     "mimetype": "application/pdf",
     "url": "https://storag...2c8b5050b7d84f.pdf"
     }
  ]
}

Cette notification indique que pour la transaction order_id_12345, son statut est maintenant done, et contient les données du document PDF. Les données sont encodées en base64.

Statuts des Transactions

Les notifications peuvent contenir l’un des statuts suivants :

confirmed : Indique que la transaction a été reçue et confirmée.
received : Indique que les documents nécessaires ont été reçus.
waiting : Indique que des documents sont manquants. Une transaction peut passer du statut received à waiting si, durant son traitement, il s’avère que certains documents sont absents.
done : La transaction est terminée, le pré-état daté est prêt. Lorsque le statut est done, le champ content contient le fichier pré-état daté, encodé en base64.
need-refresh : Indique une demande d’actualisation du document.

Types de Documents

Code	Libellé	Description succincte
1	Fiche synthétique	Résumé des informations clés de la copropriété.
2	Procès-Verbal	Compte rendu des assemblées générales.
3	Règlement de Copropriété	Document définissant les règles de vie commune.
4	Diagnostic	Rapport global des diagnostics techniques.
5	Diagnostic Amiante	État de présence ou d’absence d’amiante.
6	Diagnostic Plomb	Rapport sur la présence de plomb dans le bâti.
7	Carnet d’Entretien	Historique et suivi de l’entretien de l’immeuble.
8	Plans	Plans architecturaux ou techniques du bâtiment.
9	Immatriculation	Justificatif d’immatriculation de la copropriété.
10	Autre	Tout autre document non classifié ci-dessus.

Notes

Assurez-vous que le serveur de callback est configuré pour accepter les requêtes POST et peut traiter les données au format JSON.

En cas de besoin d’aide ou de questions concernant l’URL de callback ou la gestion des notifications, veuillez contacter notre équipe technique contact@pre-etat.date.

Test de Notifications

Il est possible de simuler les notifications d’une transaction en mode test en utilisant cet endpoint.

Endpoint

URL : /test/webhook-events
Méthode : POST
Content-Type : application/json

Paramètres de la Requête

Les paramètres doivent être envoyés dans le corps de la requête au format JSON :

orderid (string) : Identifiant unique de la commande.
event (string) : Statut à simuler (done, waiting, received, need-refresh, confirmed).

Exemple de Requête

curl -X POST https://api.pre-etat.date/order/test/webhook-events \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -H "X-Auth-Key: $APIKEY" \
  -d '{
    "orderid": "xxx",
    "event": "received"
}'