API Optimize

Unmap Optimize affecte les envois aux véhicules et ordonne leurs arrêts. Un envoi est un ramassage, une livraison, ou un ramassage associé à sa livraison. Le solveur cherche un plan de faible coût qui respecte vos fenêtres horaires, capacités de charge, pauses et limites de tournée, et renvoie une tournée par véhicule.

Le point de terminaison est en service à POST https://api.unmap.dev/optimize. Il accepte le format OptimizeToursRequest de l'API Route Optimization de Google Maps Platform et renvoie un OptimizeToursResponse. Les intégrations REST peuvent utiliser l'hôte et la clé API d'Unmap, sous réserve des champs pris en charge et des différences de comportement. Unmap n'est ni affilié à Google ni approuvé par Google.

Utilisez Optimize pour affecter les envois à un parc de véhicules ou planifier avec des fenêtres horaires, des capacités ou des pauses. Pour ordonner les arrêts d'un seul véhicule sans ces contraintes, utilisez /optimized-route.

Pour essayer une requête sans écrire de code, ouvrez le banc d'essai Optimize : collez une requête ou choisissez l'un des exemples commentés, exécutez-la avec votre clé et voyez chaque tournée sur une carte, avec son coût, ses heures et les envois écartés.

Cet exemple affecte deux colis à une fourgonnette au centre-ville de Calgary. Il utilise des trajets en ligne droite à 10 mètres par seconde et ne dépend donc pas du réseau routier. Retirez useGeodesicDistances et geodesicMetersPerSecond pour planifier avec les temps de trajet routiers. Définissez UNMAP_API_KEY pour curl, ou key pour TypeScript, avec votre clé API. Fixez les heures globales de début et de fin du modèle à la journée que vous voulez planifier.

curl -X POST "https://api.unmap.dev/optimize" \
  -H "X-API-Key: $UNMAP_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "useGeodesicDistances": true,
    "geodesicMetersPerSecond": 10,
    "model": {
      "globalStartTime": "2026-10-13T15:00:00Z",
      "globalEndTime": "2026-10-14T03:00:00Z",
      "shipments": [
        { "label": "parcel-1", "deliveries": [{ "arrivalLocation": { "latitude": 51.0478, "longitude": -114.0593 } }] },
        { "label": "parcel-2", "deliveries": [{ "arrivalLocation": { "latitude": 51.0375, "longitude": -114.0814 } }] }
      ],
      "vehicles": [
        { "label": "van-1", "startLocation": { "latitude": 51.0447, "longitude": -114.0719 }, "costPerKilometer": 1 }
      ]
    }
  }'

import { optimizeTours } from "@unmap/routing";
 
const { response, billableShipments } = await optimizeTours(
  {
    useGeodesicDistances: true,
    geodesicMetersPerSecond: 10,
    model: {
      globalStartTime: "2026-10-13T15:00:00Z",
      globalEndTime: "2026-10-14T03:00:00Z",
      shipments: [
        { label: "parcel-1", deliveries: [{ arrivalLocation: { latitude: 51.0478, longitude: -114.0593 } }] },
        { label: "parcel-2", deliveries: [{ arrivalLocation: { latitude: 51.0375, longitude: -114.0814 } }] },
      ],
      vehicles: [
        { label: "van-1", startLocation: { latitude: 51.0447, longitude: -114.0719 }, costPerKilometer: 1 },
      ],
    },
  },
  { key },
);

La réponse ci-dessous provient d'une exécution locale de cette requête avec le même traitement et le même solveur. L'ordre des visites et les heures peuvent varier entre les exécutions. Le solveur utilise un budget de temps pour chercher un plan de moindre coût.

// 200, avec X-Unmap-Billable-Shipments: 2
{
  "routes": [
    {
      "vehicleIndex": 0,
      "vehicleLabel": "van-1",
      "vehicleStartTime": "2026-10-13T15:00:00Z",
      "vehicleEndTime": "2026-10-13T15:04:47Z",
      "visits": [
        { "shipmentIndex": 0, "isPickup": false, "visitRequestIndex": 0, "startTime": "2026-10-13T15:01:35Z", "detour": "0s", "shipmentLabel": "parcel-1" },
        { "shipmentIndex": 1, "isPickup": false, "visitRequestIndex": 0, "startTime": "2026-10-13T15:04:47Z", "detour": "183s", "shipmentLabel": "parcel-2" }
      ],
      "transitions": [
        { "travelDuration": "95s", "travelDistanceMeters": 946, "waitDuration": "0s", "breakDuration": "0s", "delayDuration": "0s", "totalDuration": "95s", "startTime": "2026-10-13T15:00:00Z" },
        { "travelDuration": "192s", "travelDistanceMeters": 1923, "waitDuration": "0s", "breakDuration": "0s", "delayDuration": "0s", "totalDuration": "192s", "startTime": "2026-10-13T15:01:35Z" },
        { "travelDuration": "0s", "travelDistanceMeters": 0, "waitDuration": "0s", "breakDuration": "0s", "delayDuration": "0s", "totalDuration": "0s", "startTime": "2026-10-13T15:04:47Z" }
      ],
      "metrics": {
        "performedShipmentCount": 2,
        "travelDuration": "287s",
        "waitDuration": "0s",
        "delayDuration": "0s",
        "breakDuration": "0s",
        "visitDuration": "0s",
        "totalDuration": "287s",
        "travelDistanceMeters": 2869
      },
      "routeCosts": { "model.vehicles.cost_per_kilometer": 2.869 },
      "routeTotalCost": 2.869
    }
  ],
  "metrics": {
    "aggregatedRouteMetrics": {
      "performedShipmentCount": 2,
      "travelDuration": "287s",
      "waitDuration": "0s",
      "delayDuration": "0s",
      "breakDuration": "0s",
      "visitDuration": "0s",
      "totalDuration": "287s",
      "travelDistanceMeters": 2869
    },
    "skippedMandatoryShipmentCount": 0,
    "usedVehicleCount": 1,
    "earliestVehicleStartTime": "2026-10-13T15:00:00Z",
    "latestVehicleEndTime": "2026-10-13T15:04:47Z",
    "costs": { "model.vehicles.cost_per_kilometer": 2.869 },
    "totalCost": 2.869
  }
}

• routes : une par véhicule, dans l'ordre de la requête. visits donne l'ordre à suivre, chaque visite avec l'heure où le service commence. transitions compte une entrée de plus que visits : les trajets avant chaque visite, et le trajet jusqu'à l'arrivée du véhicule.
• La fourgonnette n'a pas d'endLocation, donc sa tournée se termine à son dernier arrêt et la dernière transition a un temps et une distance de trajet nuls. Définissez endLocation pour la ramener à l'entrepôt.
• metrics.totalCost inclut les coûts des tournées et les pénalités des envois facultatifs écartés. Ici, il correspond à costPerKilometer multiplié par la distance parcourue. Les coûts utilisent les unités que vous choisissez et ne représentent pas les frais d'API. Les horodatages de réponse sont en RFC 3339 et en UTC; les durées sont des chaînes en secondes, comme "95s".
• Les envois non servis figurent dans skippedShipments; reasons peut être absent lorsqu'aucune cause précise n'est identifiée. Un envoi sans penaltyCost est obligatoire, sauf si ignore: true. Si le solveur ne peut pas servir tous les envois obligatoires, la requête échoue avec 400 FAILED_PRECONDITION.

POST /optimize
POST /v1/projects/{project}:optimizeTours
POST /v1/projects/{project}/locations/{location}:optimizeTours
POST /projects/{project}:optimizeTours
POST /projects/{project}/locations/{location}:optimizeTours

Les cinq chemins acceptent la même requête et renvoient le même format de réponse. Utilisez /optimize pour les nouvelles intégrations. Les quatre autres permettent de conserver les chemins des intégrations REST de Google Route Optimization. {project} et {location} sont ignorés, tout comme parent dans le corps, qui produit un avertissement. La clé API identifie le compte qui exécute et paie la requête. Seule la méthode :optimizeTours existe; tout autre suffixe de méthode est un 404 NOT_FOUND.

Envoyez la clé dans Authorization: Bearer <key>, X-API-Key, X-Goog-Api-Key ou ?key=. Gardez la clé hors de l'URL pour les appels côté serveur. Voir Authentification.

Le corps est en JSON, d'au plus 4 Mio (au-delà, c'est un 413). Les noms de champs peuvent être en camelCase ou en snake_case; la réponse est en camelCase. Chaque réponse qu'écrit le gestionnaire d'Optimize, une résolution ou l'une de ses erreurs, porte Cache-Control: no-store; un refus de la vérification de clé placée devant lui, comme un 401, porte plutôt les en-têtes habituels de la passerelle.

Temps de trajet

Une requête tire ses temps de trajet de l'une de trois sources :

• Le réseau routier (par défaut). Les temps et distances de conduite viennent du même graphe routier canadien que les Itinéraires, en circulation fluide. considerRoadTraffic est accepté et ignoré, avec un avertissement si sa valeur est true. Les arrêts doivent être proches de routes au Canada, et chaque véhicule doit pouvoir atteindre ses arrêts. Les trajets locaux sur une île peuvent fonctionner même sans liaison routière avec le continent. Un envoi obligatoire injoignable fait échouer la requête avec 400 FAILED_PRECONDITION; un envoi facultatif injoignable est écarté. Les trajets routiers sont limités à 200 lieux distincts par requête, ou à la limite inférieure du forfait. Pour les requêtes plus grandes, utilisez les trajets en ligne droite ou vos propres matrices. Deux arrêts à plus de 1 000 km l'un de l'autre à vol d'oiseau sont traités comme injoignables entre eux, et une requête aussi étendue peut être refusée comme trop grosse pour une seule résolution; découpez-la par région.
• La ligne droite. useGeodesicDistances: true avec geodesicMetersPerSecond (au moins 1) : la distance orthodromique à vitesse fixe. Fonctionne partout, y compris hors du Canada.
• Vos propres matrices. model.durationDistanceMatrices avec durationDistanceMatrixSrcTags et durationDistanceMatrixDstTags. Chaque arrêt et chaque véhicule est alors placé par tags plutôt que par coordonnées, et une matrice par vehicleStartTag donne des trajets différents à des véhicules différents.

Les véhicules conduisent (travelMode DRIVING). Unmap ajoute un champ au véhicule, unmapProfile, qui nomme le profil routier; auto est la seule valeur pour l'instant.

Avec populatePolylines: true, Unmap tente d'ajouter routePolyline.points à chaque tournée utilisée. Il s'agit d'une polyligne encodée à la précision 5, tracée sur les routes canadiennes. Si le tracé échoue ou manque de temps, la tournée reste valide et revient sans polyligne, avec l'avertissement ROUTE_POLYLINE_UNAVAILABLE. Pour les requêtes géodésiques, une polyligne routière ne modifie pas les temps ni les distances en ligne droite utilisés pour planifier. Les requêtes avec vos propres matrices n'ont pas de coordonnées et ne renvoient pas de polylignes.

Ce qu'il planifie

Pris en charge aujourd'hui :

• Des envois avec un ramassage, une livraison, ou les deux (une paire est servie par un seul véhicule, ramassage d'abord), chaque visite avec un lieu, une durée de service (duration) et des fenêtres horaires strictes (timeWindows).
• Les charges : loadDemands sur l'envoi face aux loadLimits (maxLoad) du véhicule, par nom de type de charge.
• Les envois facultatifs : penaltyCost ajoute un coût lorsqu'un envoi est écarté. Le solveur peut l'écarter pour réduire le coût total, respecter les contraintes, ou faute de trouver un plan qui l'inclut dans son budget de temps. ignore: true exclut un envoi de la planification, sans pénalité.
• allowedVehicleIndices, pour limiter les véhicules qui peuvent servir un envoi.
• Des véhicules avec un lieu de départ et d'arrivée (ou des extrémités ouvertes), une fenêtre de départ et une fenêtre d'arrivée, fixedCost, costPerHour, costPerTraveledHour et costPerKilometer.
• Les limites strictes routeDurationLimit, travelDurationLimit et routeDistanceLimit.
• Des fenêtres horaires souples sur les visites et sur le départ et l'arrivée d'un véhicule (softStartTime, softEndTime et leurs coûts horaires), des limites souples de durée de tournée et de temps de conduite, une limite souple de distance et une charge maximale souple, chacune rapportée sous sa propre clé dans metrics.costs.
• Les pauses des chauffeurs : breakRule.breakRequests, chacune avec un début au plus tôt, un début au plus tard et une durée minimale.
• Des étiquettes sur la requête, les envois, les visites et les véhicules, renvoyées dans la réponse.
• searchMode : RETURN_FAST cesse d'améliorer le plan peu après une première solution, CONSUME_ALL_AVAILABLE_TIME utilise tout le timeout.

Les champs énumérés acceptent le nom ou l'entier, comme les clients de Google les envoient ("travelMode": 1).

Pas encore : les limites de durée souples quadratiques, plus d'une option de ramassage ou de livraison par envoi, plus d'une fenêtre de départ ou d'arrivée par véhicule, les types d'envois et les règles de précédence, les solutions injectées et la marche. Chacun est refusé avec FIELD_NOT_SUPPORTED_YET ou VALUE_NOT_SUPPORTED_YET plutôt qu'abandonné en silence, parce qu'un plan qui ignorerait une de vos contraintes serait faux sans vous le dire. Comme les limites de durée souples quadratiques, routeDistanceLimit.costPerKilometerBelowSoftMax est refusé, mais pour de bon et avec INVALID_VALUE : GMPRO ne le prend pas en charge non plus. Un identifiant de lieu Google est refusé aussi : géocodez l'adresse avec /geocode/search et envoyez des coordonnées. Champs pris en charge par Optimize donne chaque champ et son statut.

Envoyez "solvingMode": "VALIDATE_ONLY" pour vérifier une requête. Rien n'est calculé ni résolu, et ce n'est jamais facturé. Une requête valide répond 200 avec {}. Une requête invalide répond 200 avec chaque problème trouvé, jusqu'à maxValidationErrors (100 par défaut) :

// 200
{
  "validationErrors": [
    {
      "code": 11,
      "displayName": "MISSING_REQUIRED_FIELD",
      "fields": [{ "name": "geodesicMetersPerSecond" }],
      "errorMessage": "geodesicMetersPerSecond is required when useGeodesicDistances is true."
    }
  ]
}

Dans le mode de résolution par défaut, ces problèmes renvoient 400 INVALID_ARGUMENT, avec une violation de champ par erreur. VALIDATE_ONLY vérifie les champs et les contraintes de la requête; il ne vérifie ni l'accessibilité routière ni la possibilité de servir tous les envois ensemble. L'authentification, l'analyse du corps, sa taille et les limites du nombre d'envois ou de véhicules s'appliquent toujours et peuvent produire une réponse autre qu'un 200 avant la validation.

Limites par forfait

• Envois compte chaque entrée de model.shipments, y compris les envois ignorés. Lieux compte les endroits distincts entre lesquels il faut se déplacer, une fois les doublons fusionnés. Une requête qui dépasse un compte est un 400 INVALID_ARGUMENT qui nomme la limite; découpez-la en requêtes plus petites.
• Sur tous les forfaits, une requête peut utiliser au plus 16 noms de types de charge distincts, toutes ses clés loadDemands et loadLimits confondues. Un de plus est un 400 INVALID_ARGUMENT (OUT_OF_RANGE).
• Le nombre total de cellules des matrices est limité au carré de la limite de lieux du forfait : 10 000 pour Hobby, 250 000 pour Indie et 1 000 000 pour Growth. Les matrices de plusieurs véhicules partagent cette limite. La limite de 4 Mio du corps s'applique aussi aux matrices fournies.
• Résolution la plus longue plafonne timeout. Un délai plus long est ramené à la limite, avec un en-tête Warning: 299 - "timeout clamped to 30s for this plan" et un avertissement TIMEOUT_CLAMPED. Sans timeout, la résolution reçoit min(plafond, max(2, ceil(visites / 25))) secondes, où les visites sont les ramassages et les livraisons de la requête.
• Résolutions simultanées vaut par compte, pour toutes ses clés. Une de plus est un 429 RESOURCE_EXHAUSTED avec Retry-After.
• Les trajets routiers et la réponse du solveur partagent un budget de 140 secondes. Une étape qui dépasse le temps qui lui est alloué renvoie 504 DEADLINE_EXCEEDED. Le tracé facultatif des polylignes dispose de 30 secondes supplémentaires, pour un budget total maximal de 170 secondes. Une polyligne manquante ne fait jamais échouer la résolution.

Ce sont des valeurs de départ, fixées avant que le service ait été mesuré sous la charge de production, et elles peuvent changer.

Tarification

Un envoi effectué compte pour un appel des appels inclus dans votre forfait, la même réserve que celle des tuiles, du géocodage et des itinéraires. Un envoi effectué est un envoi visité sur une tournée lors d'une résolution réussie (200). Au-delà des appels inclus, Indie et Growth facturent le dépassement à leur prix habituel par appel, et Hobby s'arrête. Voir Forfaits et limites.

Gratuit :

• VALIDATE_ONLY, quoi qu'il trouve.
• Toute réponse autre qu'un 200 : erreurs de validation, limites, délais dépassés, pannes.
• Chaque envoi de skippedShipments, ignoré ou non servi.
• Un envoi résolu de nouveau dans les 24 heures qui suivent la résolution qui l'a d'abord facturé.

Contrairement aux autres points de terminaison, Optimize facture une requête provenant d'une origine de développement (localhost, *.pages.dev, *.workers.dev) comme n'importe quelle autre. Grâce à la nouvelle résolution gratuite ci-dessus, itérer sur une même requête reste peu coûteux.

Nouvelles résolutions. Les répartiteurs replanifient quand une fenêtre bouge ou qu'un chauffeur se déclare malade, et ce sont toujours les mêmes livraisons. Un envoi qui porte un label est donc reconnu par son étiquette et les lieux de ses visites, et un envoi sans étiquette par tout son contenu. Dans les 24 heures qui suivent la résolution qui l'a d'abord facturé, le même envoi est gratuit; une nouvelle résolution ne prolonge pas cette période. Une étiquette recyclée sur d'autres arrêts est un nouvel envoi. Quand la requête fournit ses propres matrices, l'identité couvre aussi les matrices et les startTags et endTags de chaque véhicule : de nouvelles données de trajet, ou un véhicule passé à une autre matrice, sont facturées de nouveau.

L'en-tête X-Unmap-Billable-Shipments indique le nombre d'envois facturables, y compris 0. Avant les trajets routiers ou la résolution, Unmap vérifie si le quota restant ou le plafond de dépenses couvre tous les nouveaux envois non ignorés de la requête. Les envois facultatifs comptent dans cette estimation, même si le solveur pourrait les écarter. Si l'estimation dépasse les appels disponibles, la requête renvoie 429 RESOURCE_EXHAUSTED avec le code de premier niveau quota_exceeded ou spend_cap.

La gratuité des nouvelles résolutions s'applique à toutes les clés d'un compte. Les envois en double dans une requête comptent comme des unités distinctes. Si la vérification de cette gratuité est indisponible après une résolution réussie, tous les envois effectués sont facturables. Consultez X-Unmap-Billable-Shipments pour connaître le nombre réel.

En-têtes de réponse

Les avertissements ne changent jamais le corps de la réponse, qui garde la forme qu'attend un client Google. Les codes sont FIELD_IGNORED (un champ accepté qu'Unmap ne peut pas respecter), TIMEOUT_CLAMPED, ROAD_TRAVEL_DEGRADED et ROAD_TRAVEL_UNCONFIRMED (un budget de calcul d'itinéraires, et non le réseau routier, a décidé que certaines cellules étaient injoignables; un arrêt laissé de côté pourrait donc être servi, découpez la requête), ROUTE_POLYLINE_UNAVAILABLE et WARNINGS_TRUNCATED. Un navigateur peut lire les quatre en-têtes : la passerelle les expose par CORS.

Erreurs

Sur ces chemins, les erreurs ont la forme de celles de Google, avec la chaîne code de la passerelle à côté, pour qu'un client Google comme un client Unmap puisse les lire. Le statut est dans error.status (INVALID_ARGUMENT, FAILED_PRECONDITION, RESOURCE_EXHAUSTED, etc.), et les erreurs de validation donnent une entrée fieldViolations par problème, avec le chemin exact du champ. Là où Google peut répondre 200 en laissant de côté un envoi obligatoire, Unmap refuse avec un 400 FAILED_PRECONDITION.

Erreurs donne le corps complet, chaque statut, code de validation, avertissement et raison d'exclusion, avec la cause et le correctif.

npm i @unmap/routing

pnpm add @unmap/routing

yarn add @unmap/routing

bun add @unmap/routing

optimizeTours() dans @unmap/routing envoie la clé dans X-API-Key, jamais dans l'URL, et renvoie la réponse d'Unmap au format Google, plus les informations des en-têtes. Elle est offerte dans @unmap/routing et @unmap/sdk depuis la 0.21.0.

import { optimizeTours, UnmapOptimizeError } from "@unmap/routing";
 
try {
  const { response, warnings, billableShipments, timeoutClamped } = await optimizeTours(
    {
      timeout: "10s",
      model: {
        shipments: [{ label: "order-1", deliveries: [{ arrivalLocation: { latitude: 51.05, longitude: -114.07 } }] }],
        vehicles: [{ label: "van-1", startLocation: { latitude: 51.04, longitude: -114.06 } }],
      },
    },
    { key },
  );
  console.log(response.routes, warnings, billableShipments, timeoutClamped);
} catch (e) {
  if (e instanceof UnmapOptimizeError) console.error(e.status, e.googleStatus, e.details);
}

• Le même appel est router.optimizeTours(request) sur un Router, et unmap.router.optimizeTours(request) depuis @unmap/sdk.
• warnings est l'en-tête X-Unmap-Optimize-Warnings décodé, billableShipments l'en-tête X-Unmap-Billable-Shipments décodé, et timeoutClamped avec clampedTimeoutSeconds disent si votre timeout a été raccourci.
• Un échec lève UnmapOptimizeError : status est le statut HTTP, code le code de la passerelle, googleStatus le nom de statut de Google et details les error.details de Google. Les 429, 502, 503 et les pannes de transport sont réessayés par défaut.

Champs pris en charge

Chaque champ du format OptimizeToursRequest qu'utilise l'API Route Optimization de Google Maps Platform, et ce qu'en fait Unmap Optimize. Les noms et l'imbrication des champs suivent la référence REST publique de Google; les descriptions sont celles d'Unmap. Unmap n'est ni affilié à Google ni approuvé par Google.

Cette section est générée à partir de la table de champs du validateur; les vérifications du dépôt la gardent à jour. Elle compte 191 lignes : 126 pris en charge, 16 ignoré, 5 refusé, 30 prévu (V2), 14 prévu (V3).

Comment lire les tableaux

Un chemin comme model.shipments[].deliveries[].timeWindows[].startTime désigne un champ : nom[] est un élément d'un tableau, et nom{} est une valeur d'un dictionnaire dont les clés sont les vôtres (des noms de types de charge, comme loadLimits{}). Les champs situés sous un champ refusé ou ignoré ne sont pas listés, parce que rien en dessous n'est lu.

Règles qui valent pour tout le corps :

• Les noms de champs peuvent être en camelCase ou en snake_case. Envoyer les deux graphies d'un même champ dans un même objet est une erreur CONFLICTING_FIELD_NAMES. Les clés de dictionnaire et les valeurs de chaîne ne sont jamais réécrites.
• Un champ absent de ces tables est une erreur UNKNOWN_FIELD, pour qu'une faute de frappe n'abandonne jamais une contrainte en silence.
• Les durées sont des chaînes comme "300s" ou "1.5s". Les horodatages sont des chaînes RFC 3339 ou { "seconds": ..., "nanos": ... }. Les entiers de 64 bits peuvent être des chaînes décimales ou des entiers JSON jusqu'à 2^53 - 1.
• La validation s'arrête après maxValidationErrors erreurs (100 par défaut, au plus 10 000).
• Une requête peut utiliser au plus 16 noms de types de charge distincts, comptés sur toutes les clés loadDemands et loadLimits du modèle. Le premier nom au-delà est une erreur OUT_OF_RANGE.
• Un identifiant de lieu Google (placeId) est PLACE_ID_NOT_SUPPORTED; géocodez l'adresse avec /geocode/search et envoyez des coordonnées. Aucun champ ne prend d'URI : les méthodes par lots qui lisent les URI Cloud Storage gs:// ne sont pas offertes (elles répondent par un 404), et GCS_URI_NOT_SUPPORTED leur est réservé; rien ne le renvoie aujourd'hui.

Chaque code d'erreur est expliqué dans Erreurs.

La prise en charge des champs décrit la validation et le comportement offert. Elle ne garantit pas qu'une requête a une solution réalisable. populatePolylines tente un tracé routier pour les tournées avec coordonnées; les requêtes avec matrices fournies ne renvoient pas de polylignes. Voir les temps de trajet et les limites par forfait.

Les messages d'erreur et d'avertissement sont cités tels que l'API les renvoie, en anglais.

Champs de la requête

Champs du modèle

Champs des envois

Champs des véhicules

Prochaines étapes

• Des exemples, chacun une requête complète à copier : livraisons du dernier kilomètre, service sur le terrain avec pauses, et une messagerie avec ramassage et livraison.
• Erreurs : chaque erreur, avertissement et raison d'exclusion.
• Depuis Google Route Optimization : faire passer une intégration existante.