API des Rendez-vous

🚀 Pourquoi utiliser l’API des Rendez-vous?

Les rendez-vous sont au cœur des opérations d’entrepôt dans DataDocks. Ils représentent les créneaux horaires planifiés à vos quais ou dans votre cour pour la réception ou l’expédition d’inventaire. L’API des rendez-vous vous offre un contrôle programmatique sur l’ensemble de votre flux de planification d’entrepôt—de la réservation des créneaux au suivi des mouvements de camions, jusqu’à la finalisation des expéditions.

Problèmes réels résolus par cette API

Éliminer la double saisie : Synchronisez directement les rendez-vous entre votre ERP/WMS et DataDocks
Réduire la surcharge de communication : Automatisez les notifications entre le personnel d'entrepôt et les transporteurs
Optimiser l’utilisation des quais : Planifiez les rendez-vous de façon programmatique pour maximiser l’efficacité
Suivre les indicateurs clés en temps réel : Surveillez la ponctualité, les temps d’attente et le débit
Améliorer la visibilité : Offrez aux transporteurs et clients un accès en libre-service au statut des rendez-vous

Démarrage rapide en 5 minutes

Vous voulez voir l’API en action ? Suivez ces étapes pour créer votre premier rendez-vous :

Demandez et obtenez votre jeton API auprès du support
Trouvez votre sous-domaine d’emplacement (par ex., votre-entrepot.datadocks.com)
Créez un rendez-vous de base avec cette commande :

Voir l’exemple cURL pour démarrage rapide

curl -X POST \
  https://your-warehouse.datadocks.com/api/v1/appointments \
  -H 'Authorization: Token VOTRE_JETON_API' \
  -H 'Content-Type: application/json' \
  -d '{
    "appointment": {
      "scheduled_at": "2023-12-15T10:00:00-05:00",
      "duration": 60,
      "dock_name": "Quai 1",
      "shipping_number": "EXP-12345"
    }
  }'

Voilà ! Vous avez créé votre premier rendez-vous. Vérifiez votre tableau de bord DataDocks pour le voir.

Aperçu de l’architecture de l’API

┌─────────────────┐       ┌─────────────────┐       ┌─────────────────┐
│  Votre système  │──────▶│   API DataDocks │──────▶│  Opérations Entrepôt │
│ (ERP/WMS/TMS)   │◀──────┤  (REST/JSON)    │◀──────┤  (Planification)    │
└─────────────────┘       └─────────────────┘       └─────────────────┘
                                  │  ▲
                                  │  │
                                  ▼  │
                           ┌─────────────────┐
                           │  Applis Transporteurs │
                           │  (Enregistrement)     │
                           └─────────────────┘

Authentification

Toutes les requêtes API doivent inclure votre jeton API dans l’en-tête Authorization :

Authorization: Token VOTRE_JETON_API

Les jetons d’API sont spécifiques à chaque organisation et apparaîtront dans les journaux d’audit comme « Datadocks API - VOTRE_NOM_ORG ».

Limitations importantes

Les rendez-vous récurrents ne peuvent pas être créés ou modifiés via l’API
La suppression de rendez-vous n’est pas prise en charge via l’API (utilisez l’annulation à la place)
Les paramètres DateTime doivent être correctement formatés avec l’information de fuseau horaire
Seuls les rendez-vous non récurrents sont retournés par les endpoints de listes

Lister les Rendez-vous

Objectif

Récupère une liste paginée de rendez-vous, avec possibilité de filtrage par plage de dates ou par numéro de bon de commande. Utilisez ce endpoint pour synchroniser les rendez-vous avec vos systèmes ou générer des rapports.

Cas d’utilisation métier

Synchroniser les rendez-vous avec votre WMS ou TMS pour la semaine à venir
Générer des rapports sur les expéditions à venir par quai ou transporteur
Afficher les rendez-vous sur un tableau de bord avec suivi du statut
Suivre des indicateurs tels que ponctualité, temps d’attente et taux d’utilisation des quais

Requête HTTP

GET https://[location_subdomain].datadocks.com/api/v1/appointments

Paramètres de requête

Paramètre	Type	Requis	Description	Exemple
`page`	Integer	Non	Numéro de page pour la pagination (défaut : 1)	`page=2`
`po_number`	String	Non	Filtre par numéro de bon de commande (sensible à la casse, concordance exacte)	`po_number=PO-12345`
`from`	String	Non	Filtre les rendez-vous planifiés à partir de cette date/heure (fuseau de l’emplacement)	`from=2023-10-01 08:00 AM`
`to`	String	Non	Filtre les rendez-vous planifiés avant cette date/heure (fuseau de l’emplacement)	`to=2023-10-05 06:00 PM`

Format de la réponse

La réponse contient un tableau paginé d’objets rendez-vous, chacun avec les champs suivants :

Champ	Type	Description
`id`	Integer	Identifiant unique du rendez-vous
`appointment_number`	Integer	Numéro de rendez-vous facile à lire
`state`	String	État actuel du rendez-vous (ex. : « scheduled », « arrived », « completed »)
`duration`	Integer	Durée en minutes
`scheduled_at`	String	Horodatage ISO8601 de la planification du rendez-vous
`shipping_number`	String	Numéro de référence pour l’expédition
`trailer_number`	String	Numéro d’identification de la remorque
`bol_number`	String	Numéro du connaissement (BOL)
`carrier_name`	String	Nom de l’entreprise de transport
`carrier_number`	String	Identifiant du transporteur dans votre système
`driver_name`	String	Nom du chauffeur
`driver_phone`	String	Téléphone du chauffeur
`driver_email`	String	Courriel du chauffeur
`created_by`	String	Nom de l’utilisateur ayant créé le rendez-vous
`outbound`	Boolean	Rendez-vous sortant (true) ou entrant (false)
`drop_trailer`	Boolean	S’il s’agit d’un rendez-vous de dépôt de remorque
`queued`	Boolean	Si ce rendez-vous est en file d’attente
`dock_name`	String	Nom du quai assigné (null si la cour assignée)
`yard_name`	String	Nom de la cour assignée (null si le quai assigné)
`internal_id`	String	Identifiant interne pour ce rendez-vous
`free_until`	String	Horodatage ISO8601 de libération du quai/cour
`approved_at`	String	Horodatage ISO8601 d’approbation du rendez-vous
`arrived_at`	String	Horodatage ISO8601 de l’arrivée du rendez-vous
`started_at`	String	Horodatage ISO8601 du début des opérations
`completed_at`	String	Horodatage ISO8601 de fin des opérations
`left_at`	String	Horodatage ISO8601 de départ
`cancelled_at`	String	Horodatage ISO8601 d’annulation (null si actif)
`custom_values`	Object	Paires clé/valeur de champs personnalisés
`checklist_values`	Object	Paires clé/valeur d’items de liste de contrôle
`packing_lists`	Array	Listes d’objets de listes d’emballage associées au rendez-vous
`notes`	Array	Liste de notes associées (voir le format de note ci-dessous)
`documents`	Array	Liste de documents associés

(Le contenu des blocs de code, exemples cURL ou JavaScript, ainsi que les objets JSON doivent être traduits uniquement au niveau des commentaires. Les clés/champs/restent en anglais, seuls les commentaires ou le contexte autour des exemples doivent être en français.)

Exemples de code

cURL

Voir l’exemple cURL

# Liste de base
curl -H "Authorization: Token VOTRE_JETON_API" \
     https://VOTRE_EMPLACEMENT.datadocks.com/api/v1/appointments

# Filtré par plage de dates et bon de commande
curl -H "Authorization: Token VOTRE_JETON_API" \
     "https://VOTRE_EMPLACEMENT.datadocks.com/api/v1/appointments?from=2023-10-01%2008:00%20AM&to=2023-10-05%2006:00%20PM&po_number=PO-12345"

JavaScript

Voir l’exemple JavaScript

// Utilisation de fetch API avec filtres
const getAppointments = async (fromDate, toDate, poNumber) => {
  // ...pas de modification
};

Exemple de réponse

Voir exemple de réponse

[
  {
    "id": 1,
    "appointment_number": 1,
    "state": "left",
    "duration": 120,
    "shipping_number": "57886",
    "trailer_number": "2222222",
    "bol_number": "922",
    "carrier_name": "FastCo",
    "carrier_number": "FC123",
    "driver_name": "Jason Smith",
    "driver_phone": "+1 (555) 123-4567",
    "driver_email": "jason.smith@fastco.example.com",
    "created_by": "Sysadmin",
    "outbound": false,
    "drop_trailer": false,
    "queued": false,
    "dock_name": "Dock 2",
    "yard_name": null,
    "internal_id": "ERP-A12345",
    "free_until": null,
    "scheduled_at": "2020-09-30T06:00:00-04:00",
    "approved_at": "2020-09-22T13:35:00-04:00",
    "arrived_at": null,
    "started_at": "2020-09-24T13:35:00-04:00",
    "completed_at": "2020-09-24T13:35:00-04:00",
    "left_at": "2020-09-25T13:35:00-04:00",
    "cancelled_at": null,
    "custom_values": {
      "expected_at": "2020-10-01",
      "travel_type": "Truck",
      "forklift_operator": "Sue",
      "inspection_passed": "1"
    },
    "checklist_values": {
      "safety_check": "Passed",
      "dock_seal_status": "Good",
      "temperature": "-5"
    },
    "packing_lists": [
      {
        "id": 4,
        "po_number": "A-2000",
        "customer_name": "FishCo",
        "customer_number": "FC001",
        "product_name": "Trout",
        "unit_name": "Skid",
        "booked_quantity": 10,
        "booked_weight": 152,
        "actual_quantity": 12,
        "actual_weight": 160,
        "custom_values": {
          "barcode": "11223344",
          "dimensions": "S",
          "temperature_celcius": "-5"
        }
      }
    ],
    "notes": [
      {
        "id": 3,
        "body": "First note.",
        "note_type": "user_note"
      }
    ],
    "documents": []
  }
]

Pagination

La réponse est paginée pour mieux gérer le volume de données. Pour plus d’informations sur la pagination, consultez la documentation sur la pagination.

Pièges courants et dépannage

Problèmes d’analyse de date/heure : les paramètres from et to sont interprétés selon le fuseau horaire de l’emplacement. Assurez-vous de toujours fournir l’information de fuseau horaire pour éviter des résultats inattendus.
```
✅ Bon : from=2023-10-01T08:00:00-04:00
✅ Bon : from=2023-10-01 08:00 AM EDT
❌ Mauvais : from=2023-10-01
```
Filtrage par numéro de commande : la recherche n’est pas sensible à la casse, mais la correspondance doit être exacte. Les correspondances partielles ne fonctionnent pas.
```
✅ Fonctionnera : po_number=PO-12345
✅ Fonctionnera : po_number=po-12345 (sans sensibilité à la casse)
❌ Ne fonctionnera pas : po_number=12345 (partiel)
```
Format de date incorrect : l’API ne retourne pas d’erreur de validation pour un format de date incorrect. Assurez-vous que vos chaînes de date sont bien formatées.
Rendez-vous non récurrents uniquement : seul ce type de rendez-vous est retourné par ce endpoint.
Considérations de performance : pour de grandes plages de dates, privilégiez des requêtes sur des périodes plus courtes (ex. : par semaine au lieu du mois entier).

Création d’un Rendez-vous

Objectif

Créer un nouveau rendez-vous sur un quai ou une cour, avec listes d’emballage et métadonnées facultatives. C’est la méthode principale de planification depuis votre système.

Arbre de décision : quand créer via l’API

┌─────────────────┐
│ Besoin de planifier │
│   un rendez-vous ?  │
└────────┬────────┘
         │
         ▼
┌─────────────────────────┐   Oui   ┌─────────────────┐
│ Cela fait-il partie     │────────▶│ Utilisez l’interface │
│ d’un motif récurrent ?  │         │ de réservation standard │
└────────┬───────────────┘          └─────────────────┘
         │ Non
         ▼
┌────────────────────┐   Oui   ┌─────────────────┐
│ Créez-vous beaucoup│────────▶│ Utilisez l’import │
│ de rendez-vous en  │         │ en lot via le web │
│ une seule fois ?   │         └─────────────────┘
└────────┬──────────┘
         │ Non
         ▼
┌─────────────────┐
│  Parfait pour   │
│    l’API !      │
└─────────────────┘

Cas d’utilisation métier

Intégration système : Planifier depuis ERP, WMS ou TMS
Planification automatisée : Créer selon les règles métier ou des déclencheurs
Libre-service transporteurs : Permettre la réservation via leur portail
Applications mobiles : Permettre la création depuis mobiles d’entrepôt
Exécution de commandes : Générer un rendez-vous sortant quand la commande est prête

Requête HTTP

POST https://[location_subdomain].datadocks.com/api/v1/appointments

Corps de la requête

(Voir tableau original – les champs, contraintes et exemples sont identiques. Traduisez les titres/entêtes, contextualisez les exemples.)

* Soit dock_name, soit yard_name est généralement requis, selon la configuration de votre emplacement.

** Peut être requis selon les préférences d’emplacement

Approbation automatique des rendez-vous

Par défaut, selon les paramètres de votre emplacement, les rendez-vous créés via API peuvent être approuvés automatiquement si scheduled_at est présent. Pour modifier ce comportement, contactez le support.

Format liste d’emballage

(L’exemple JSON reste aussi, seul le commentaire général est adapté.)

Détails des champs de liste d’emballage

(Voir le tableau original. Les titres et explications sont traduits, les clés restent identiques.)

Logique d’affectation client

Lorsque vous créez une liste d’emballage, fournissez soit customer_name, soit customer_number, soit les deux :

Si seul customer_number est fourni, le système :
- Cherche une correspondance sur le numéro d’entreprise
- S’il trouve, il remplit automatiquement nom et ID du client
- Sinon, il renseigne customer_name avec le numéro fourni

Traitement des produits et unités

La correspondance se fait sans tenir compte de la casse. Si le produit ou l’unité n’existe pas et que la validation automatique n’est pas désactivée, vous obtiendrez une erreur. Pour activer la création automatique, contactez le support.

Format de note

{
  "body": "Le chauffeur nécessite un hayon élévateur"
}

Les notes sont attachées automatiquement à l’utilisateur API courant.

Les réponses retournent aussi un champ note_type en lecture seule pour chaque note :

Valeur	Signification
`user_note`	Une note écrite par une personne. C’est la valeur par défaut, et le seul type que vous pouvez créer.
`cancellation_note`	Enregistrée par DataDocks lorsqu’un rendez-vous est annulé avec un motif depuis le portail de réservation.

note_type est attribué par DataDocks et est ignoré si vous l’envoyez. Les notes d’annulation ne peuvent pas être supprimées — elles documentent ce qui est arrivé au rendez-vous, donc un _destroy envoyé pour l’une d’elles est rejeté et la mise à jour entière échoue.

Réponse

Une requête réussie retourne un 200 OK avec l’objet rendez-vous complet, incluant l’id système généré.

Exemples de code

(Par souci de lisibilité, ne traduisez que les commentaires/contextes, laissez le code original en anglais.)

Gestion des erreurs

Code d’erreur	Description	Cause possible
400	Requête invalide	Champs obligatoires manquants ou valeurs invalides
404	Introuvable	Quai/cour/produit référencé inexistant à cet emplacement
422	Entité non traitable	Validation métier échouée (conflit de planning, quai plein, etc.)
401	Non autorisé	Jeton API invalide ou manquant
403	Interdit	Permissions insuffisantes pour créer des rendez-vous

Exemple de réponse d’erreur

{
  "errors": {
    "scheduled_at": ["ne peut être vide", "doit être dans le futur"],
    "dock_name": ["Le quai 'Dock 99' n'existe pas à cet emplacement"],
    "packing_lists.product_name": [
      "Le produit 'Produit inconnu' n'existe pas et la création automatique est désactivée"
    ]
  }
}

Pièges et dépannage courants

Affectation quai vs cour : fournissez l’un OU l’autre. Les deux donnent des résultats inattendus.
Formats d’heure : toutes les heures doivent inclure l’information de fuseau horaire.
Création de produit/unité : à activer par administrateur DataDocks si non existant.
Recherche client : le numéro est comparé sans tenir compte de la casse.
Suppression d’une liste d’emballage : passez l’id et _destroy: true lors de la mise à jour.
Rendez-vous récurrents : non supportés par l’API, utilisez l’interface web.
Champs personnalisés : seuls les champs configurés sont pris en compte.
Approbation automatique : dépend du paramétrage local.

Conseils d’optimisation

Regroupez les requêtes : espacez-les pour éviter les limites de débit
Minimisez les valeurs personnalisées : n’envoyez que ce qui est nécessaire
Préchargez les ressources : vérifiez l’existence de produits/unités/transporteurs
Validez localement : limitez les échecs en validant côté client

Récupération d’un rendez-vous

Objectif

Obtenir l’ensemble des informations d’un rendez-vous par ID : statut, listes d’emballage, métadonnées, etc.

Cas d’utilisation

Suivi du statut : vérifier l’état en temps réel
Suivi des heures : analyser les heures d’arrivée et de départ
Vérification documentaire : contrôler les documents ou listes d’emballage joints
Transporteur : récupérer les infos chauffeur/remorque
Champs personnalisés : accéder aux champs spécifiques

Requête HTTP

GET https://[location_subdomain].datadocks.com/api/v1/appointments/:id

Paramètres d’URL

Paramètre	Type	Requis	Description
`id`	Integer	Oui	Identifiant unique du rdv

Réponse

Un 200 OK avec l’objet rendez-vous complet (même format que la liste).

Exemples de code

(Seuls les commentaires alentours sont traduits pour le contexte.)

Réponses d’erreur

Code	Description	Cause possible
404	Introuvable	L’ID ne correspond à aucun rendez-vous
401	Non autorisé	Jeton API manquant ou invalide
403	Interdit	Permissions insuffisantes

Limitations

Seuls les rendez-vous non récurrents sont accessibles
Les modèles récurrents ne sont disponibles que via l’interface web

Mise à jour d’un rendez-vous

Objectif

Modifier les détails, le statut ou les données associées d’un rendez-vous, à toutes les étapes de son cycle de vie.

Cas d’utilisation

Mise à jour des statuts : arrivé, commencé, terminé, parti
Changement de planification : ajustez l’horaire ou la durée
Mise à jour des détails : infos transporteur/remorque/référence
Listes d’emballage : modifiez produits, quantités, valeurs personnalisées
Gestion des notes : ajoutez des remarques historiques

Requête HTTP

PUT https://[location_subdomain].datadocks.com/api/v1/appointments/:id

Paramètres d’URL

Paramètre	Type	Requis	Description
`id`	Integer	Oui	Identifiant unique du rdv

Corps de requête

Même format que pour la création. Seuls les champs à modifier doivent être inclus.

Logique de transition de statut

Le cycle normal suit cet ordre :

scheduled_at → approved_at → arrived_at → started_at → completed_at → left_at

Même si les champs sont modifiables à tout moment, il est préférable de tenir ce flux logique.

Scénarios fréquents de mise à jour

Marquer comme « arrivé »

{
  "appointment": {
    "arrived_at": "2023-10-15T08:45:00-04:00",
    "trailer_number": "TRAILER-789"
  }
}

Modification des quantités d’une liste d’emballage

{
  "appointment": {
    "packing_lists": [
      {
        "id": 123,
        "actual_quantity": 9,
        "actual_weight": 450
      }
    ]
  }
}

Ajout d’une nouvelle note

{
  "appointment": {
    "notes": [
      {
        "body": "Le camion est arrivé avec un scellé endommagé. Inspection faite."
      }
    ]
  }
}

Suppression d’une liste d’emballage

{
  "appointment": {
    "packing_lists": [
      {
        "id": 123,
        "_destroy": true
      }
    ]
  }
}

Marquer comme « Terminé »

{
  "appointment": {
    "completed_at": "2023-10-15T10:30:00-04:00",
    "left_at": "2023-10-15T10:45:00-04:00",
    "checklist_values": {
      "dock_condition": "Clean",
      "paperwork_complete": "Yes"
    }
  }
}

Exemples de code

(Comme précédemment, seuls les commentaires contextuels sont adaptés si pertinent.)

Gestion des erreurs

Code	Description	Cause possible
400	Requête invalide	Valeurs ou formats invalides
404	Introuvable	L’ID du rendez-vous n’existe pas
422	Entité non traitable	Validation métier échouée (ex : transition impossible)
401	Non autorisé	Jeton API manquant ou invalide
403	Interdit	Permissions insuffisantes

Limitations importantes

Rendez-vous récurrents : pas de support pour leur modification via l’API
Mise à jour partielle : seuls les champs présentés sont mis à jour
Objets imbriqués : pour modifier (ex : listes d’emballage), indiquez bien leur id
Suppression non supportée : pas d’endpoint pour supprimer ; pour annuler, posez la date dans cancelled_at

Bonnes pratiques de transition de statut

Procédure conseillée :

Créer le rendez-vous (scheduled_at)
L’approuver (approved_at)
Marquer comme arrivé (arrived_at)
Commencer l’opération (started_at)
Terminer le rendez-vous (completed_at)
Marquer comme parti (left_at)

À chaque étape d’état, incluez les métadonnées appropriées (ex : quantités réelles à la complétion).

Cycle de vie et flux de travail des rendez-vous

Comprendre ce cycle est essentiel pour une intégration efficace. Chaque rendez-vous suit une machine à états qui gouverne ses transitions.

Workflow visuel des états

┌────────────┐    ┌────────────┐    ┌────────────┐    ┌────────────┐    ┌────────────┐
│  Planifié  │───▶│  Arrivé    │───▶│  Commencé  │───▶│  Terminé   │───▶│    Parti   │
└────────────┘    └────────────┘    └────────────┘    └────────────┘    └────────────┘
       │
       │                              ┌────────────┐
       └─────────────────────────────▶│  Annulé    │
                                      └────────────┘

Événements de transition d’état

De	À	Champ horodatage	Description
Besoin de réservation	En attente d'approbation	`scheduled_at`	Rendez-vous avec date prévue
Planifié	Approuvé	`approved_at`	Approbation du rendez-vous (peut être auto)
Approuvé	Arrivé	`arrived_at`	Camion arrivé sur site
Arrivé	Démarré	`started_at`	Le chargement/déchargement démarre
Démarré	Terminé	`completed_at`	Chargement/déchargement terminé
Terminé	Parti	`left_at`	Camion a quitté le site
Tout état	Annulé	`cancelled_at`	Rendez-vous annulé (état terminal)

Collecte de données lors des transitions

À chaque étape :

Arrivé

Mettre à jour les infos chauffeur si besoin
Valider le numéro de remorque
Documenter l’heure d’arrivée
Ajouter des remarques

Démarré

Documenter les changements d’affectation
Horodater le début de l’opération

Terminé

Renseigner les quantités/manquants
Noter les problèmes qualité
Recueillir signatures
Charger les documents nécessaires

Parti

Calculer le temps total sur site
Horodater le départ
Finaliser la liste de contrôle

Meilleures pratiques d’implémentation

Validez les transitions logiquement
Ajoutez les métadonnées à chaque changement
Documentez chaque étape via des notes
Déclenchez des notifications avec les webhooks
Enregistrez les temps pour chaque état

Bonnes pratiques de sécurité

Protégez vos données d’entrepôt via de bonnes mesures de sécurité API.

Stockage sécurisé

Ne codez jamais en dur les jetons : stockez-les dans des variables d’environnement, coffre-fort, etc.
Chiffrez au repos les jetons API
Utilisez une gestion des secrets (ex. HashiCorp Vault, AWS Secrets Manager)

Sécurité des connexions

Utilisez HTTPS en tout temps
Vérifiez les certificats SSL/TLS

Mesures complémentaires

Mettez en place la surveillance de l’activité API
Préparez un plan d’intervention en cas de fuite de jeton

Endpoints connexes

API Produits – Gérer les produits des listes d’emballage
API Bons de commande – Gérer les bons de commande liés
API Entreprises – Gérer transporteurs et clients
Webhooks – Notifications temps réel des changements de rendez-vous

Suppression de rendez-vous (non supportée)

Limitation importante

L’API des rendez-vous ne prend pas en charge la suppression pure et simple, pour assurer l’intégrité des historiques.

Alternatives à la suppression

Annulez le rendez-vous en définissant cancelled_at
Mettez à jour les détails si le planning doit être modifié
Gérez le suivi via des champs personnalisés

Annuler un rendez-vous

Annulez en renseignant cancelled_at. Toute note envoyée avec cette requête est une user_note ordinaire : les notes d’annulation ne sont produites que par le flux d’annulation du portail de réservation, où l’installation peut exiger un motif de la part des transporteurs.

Voir l’exemple cURL

curl -H "Authorization: Token VOTRE_JETON_API" \
     -H "Content-Type: application/json" \
     -X PUT \
     -d '{
       "appointment": {
         "cancelled_at": "2023-10-14T15:30:00-04:00",
         "notes": [
           {
             "body": "Annulé en raison de conditions météorologiques."
           }
         ]
       }
     }' \
     https://VOTRE_EMPLACEMENT.datadocks.com/api/v1/appointments/123

Livre de recettes API : scénarios fréquents

(Cette section contient des recettes réutilisables pour divers scénarios : synchronisation ERP, tableau bord, gestion status, etc. Le code reste tel quel, seuls les commentaires contextuels sont adaptés.)

--- Les recettes suivantes montrent comment :

Synchroniser des expéditions sortantes depuis l’ERP
Calculer l’utilisation temps réel des quais
Automatiser le traitement d’arrivée des camions
Mettre à jour par lots les statuts de rendez-vous

(reportez-vous au texte anglais source pour le détail des fonctions JavaScript)

Optimisation de la performance

Adoptez ces conseils pour des intégrations API efficaces :

Chargement efficace des données

Filtrez par date : fournissez from et to pour limiter le résultat
Cachez les données stables
Utilisez la pagination pour limiter le volume par appel

Optimisation des requêtes

Regroupez les mises à jour au lieu de faire des appels multiples isolés
Contrôlez la concurrence pour éviter les limites de débit
Préparez à l’avenir : prise en charge à venir de demandes conditionnelles/Etag

Performance réseau

Conservez les connexions si vous faites de nombreux appels
Compressez les corps de grosse taille (gzip)
Exponential backoff : augmentez le délai entre tentatives en cas de limite

Dépannage des problèmes courants

Problèmes d’authentification

Symptômes

Erreurs 401 « Non autorisé »
Messages « Jeton invalide »

Solutions

Vérifiez votre jeton et sa validité
Vérifiez les permissions sur ce jeton
Confirmez le sous-domaine
Vérifiez le format de l’en-tête : Authorization: Token VOTRE_JETON_API

Limites de débit

Symptômes

Erreurs 429 « Trop de requêtes »
Échecs soudains de requêtes auparavant fonctionnelles

Solutions

Implémentez la gestion des limites (60 requêtes/min/IP)
Ajoutez des délais entre les mises à jour par lots
Utilisez un backoff exponentiel pour la reprise
Répartissez les requêtes sur plusieurs jetons si possible

Problèmes de date/heure

Symptômes

Rendez-vous créés à de mauvaises heures
Filtres de recherche inopérants

Solutions

Incluez toujours le fuseau horaire
Attention aux changements d’heure d’été
Utilisez le format ISO8601
Assurez l’ordre chrono dans les filtres

Erreurs de validation des données

Symptômes

422 Entité non traitable
Erreurs de champ spécifiques

Solutions

Consultez la réponse détaillée pour identifier le champ fautif
Fournissez les champs requis (scheduled_at, duration)
Vérifiez l’existence des ressources référencées
Validez côté client

Assistance et support

Trouver des solutions aux erreurs

Si vous rencontrez des erreurs non traitées :

Lisez la réponse d’erreur : elle est généralement explicite
Consultez les limitations de l’API
Procédez par étapes pour isoler la cause
Vérifiez les limites de débit

Obtenir du support

Pour toute aide complémentaire concernant DataDocks API :

Documentation complète : docs.datadocks.com/api
Support : support@datadocks.com

Lors de votre demande, précisez :

Votre sous-domaine
Les détails de la requête (méthode, endpoint, paramètres)
La réponse complète de l’erreur
L’heure exacte du problème

Remarque : Tous les exemples de code, noms de champs, requêtes JSON/Payload REST restent en anglais pour des raisons d’intégration technique, les notes, explications, et titres, ainsi que les tables et contextes, sont en français canadien, techniquement précis, et suivent le lexique fourni.

🚀 Pourquoi utiliser l’API des Rendez-vous?​

Problèmes réels résolus par cette API​

Démarrage rapide en 5 minutes​

Aperçu de l’architecture de l’API​

Authentification​

Limitations importantes​

Lister les Rendez-vous​

Objectif​

Cas d’utilisation métier​

Requête HTTP​

Paramètres de requête​

Format de la réponse​

Exemples de code​

cURL​

JavaScript​

Exemple de réponse​

Pagination​

Pièges courants et dépannage​

Création d’un Rendez-vous​

Objectif​

Arbre de décision : quand créer via l’API​

Cas d’utilisation métier​

Requête HTTP​

Corps de la requête​

Approbation automatique des rendez-vous​

Format liste d’emballage​

Détails des champs de liste d’emballage​

Logique d’affectation client​

Traitement des produits et unités​

Format de note​

Réponse​

Exemples de code​

Gestion des erreurs​

Exemple de réponse d’erreur​

Pièges et dépannage courants​

Conseils d’optimisation​

Récupération d’un rendez-vous​

Objectif​

Cas d’utilisation​

Requête HTTP​

Paramètres d’URL​

Réponse​

Exemples de code​

Réponses d’erreur​

Limitations​

Mise à jour d’un rendez-vous​

Objectif​

Cas d’utilisation​

Requête HTTP​

Paramètres d’URL​

Corps de requête​

Logique de transition de statut​

Scénarios fréquents de mise à jour​

Marquer comme « arrivé »​

Modification des quantités d’une liste d’emballage​

Ajout d’une nouvelle note​

Suppression d’une liste d’emballage​

Marquer comme « Terminé »​

Exemples de code​

Gestion des erreurs​

Limitations importantes​

Bonnes pratiques de transition de statut​

Cycle de vie et flux de travail des rendez-vous​

Workflow visuel des états​

Événements de transition d’état​

Collecte de données lors des transitions​

Meilleures pratiques d’implémentation​

Bonnes pratiques de sécurité​

Stockage sécurisé​

Sécurité des connexions​

Mesures complémentaires​

Endpoints connexes​

Suppression de rendez-vous (non supportée)​

Limitation importante​

Alternatives à la suppression​

Annuler un rendez-vous​

Livre de recettes API : scénarios fréquents​

Optimisation de la performance​

Chargement efficace des données​

Optimisation des requêtes​

🚀 Pourquoi utiliser l’API des Rendez-vous?

Problèmes réels résolus par cette API

Démarrage rapide en 5 minutes

Aperçu de l’architecture de l’API

Authentification

Limitations importantes

Lister les Rendez-vous

Objectif

Cas d’utilisation métier

Requête HTTP

Paramètres de requête

Format de la réponse

Exemples de code

cURL

JavaScript

Exemple de réponse

Pagination

Pièges courants et dépannage

Création d’un Rendez-vous

Objectif

Arbre de décision : quand créer via l’API

Cas d’utilisation métier

Requête HTTP

Corps de la requête

Approbation automatique des rendez-vous

Format liste d’emballage

Détails des champs de liste d’emballage

Logique d’affectation client

Traitement des produits et unités

Format de note

Réponse

Exemples de code

Gestion des erreurs

Exemple de réponse d’erreur

Pièges et dépannage courants

Conseils d’optimisation

Récupération d’un rendez-vous

Objectif

Cas d’utilisation

Requête HTTP

Paramètres d’URL

Réponse

Exemples de code

Réponses d’erreur

Limitations

Mise à jour d’un rendez-vous

Objectif

Cas d’utilisation

Requête HTTP

Paramètres d’URL

Corps de requête

Logique de transition de statut

Scénarios fréquents de mise à jour

Marquer comme « arrivé »

Modification des quantités d’une liste d’emballage

Ajout d’une nouvelle note

Suppression d’une liste d’emballage

Marquer comme « Terminé »

Exemples de code

Gestion des erreurs

Limitations importantes

Bonnes pratiques de transition de statut

Cycle de vie et flux de travail des rendez-vous

Workflow visuel des états

Événements de transition d’état

Collecte de données lors des transitions

Meilleures pratiques d’implémentation

Bonnes pratiques de sécurité

Stockage sécurisé

Sécurité des connexions

Mesures complémentaires

Endpoints connexes

Suppression de rendez-vous (non supportée)

Limitation importante

Alternatives à la suppression

Annuler un rendez-vous

Livre de recettes API : scénarios fréquents

Optimisation de la performance

Chargement efficace des données

Optimisation des requêtes