Connect Google Maps: route distance, duration and ETA for TMS lanes

Create a project in Google Cloud Console, enable the Routes API, create an API key, fill that single api_key into Integration, test it with one real Routes call, pick the route planning template and activate — TMS then gets distance, duration and route for lane cost and ETA.

The Google Maps connector is a route data source for TMS. It uses the Google Maps Routes API to calculate one route at a time — distance, duration and the route itself — so shipments and tenders in TMS can use that result as the basis for lane cost and ETA. That is its only job: it does not pull or push orders, it does not sync customers or inventory, and it does not track vehicles. One connection holds one Google Maps API Key.

Prerequisites#

• Access to Google Cloud Console with permission to create a project, enable an API and create an API key in that project.
• The Routes API will be enabled in that project. Without it, a correct key still cannot return a route.
• You understand that testing this connection is not free of usage: there is no free probe endpoint for the Routes API, so each test is one real route call and uses one quota. Do not click test repeatedly without a reason.
• Permission in this system to open Integration and create a new connection.

Get your credentials#

1. Sign in to Google Cloud Console and create a project for this connection.
2. In that project, enable the Routes API.
3. Create an API key in the same project and copy the full key. Keys for this connector start with AIza… — copy the whole value, with nothing cut off at either end.
4. Restrict the key as the console guidance suggests: limit it to the Routes API and to your IP. Write down exactly which API and which IP you allowed, because a later failure is often just a mismatch with that restriction.

Fill it into Integration#

1. Open Integration → Connector Marketplace → Google Maps → New connection.
2. api_key — required, Google Maps API Key: paste the full API key you created in Google Cloud Console after enabling the Routes API. It is a password-type field and is stored as a secret. There is no second field for this connector: no account name, no project field and no username to fill in here.
3. Save the connection before you test it, so the test uses exactly the key you just entered.

Test the connection#

Click Test connection. With a key filled in, the test makes one real, minimal Routes call: it sends a computeRoutes request to https://routes.googleapis.com/directions/v2:computeRoutes with your key in the X-Goog-Api-Key header, from origin 34.0633,-117.6509 to destination 34.0733,-117.6409 in driving mode. A pass means the key is valid and the Routes API is reachable, and the success message says so in words: API key valid, Routes API reachable (probe consumes one quota). Read that last part literally — this probe is a real call and it uses one quota every time you run it, so test once, fix the cause if it fails, and only then test again.

Mapping / pick a template#

Pick the route planning template — the only template this connector uses. There are no order or customer fields to map. What the template sets is how a travel mode asked for in TMS is sent to Google: driving and driving-traffic are sent as DRIVE, cycling as BICYCLE and walking as WALK. After the test passes, ask for one route you already know in TMS and check the returned distance and duration against your own expectation for that lane before you activate. If the numbers look wrong for every lane, check the mode first — the same two points give very different results by car, by bicycle and on foot.

Activate#

After activation, TMS can ask this connection for a route whenever a shipment or tender needs a lane estimate: the connection returns distance, duration and the route, and TMS uses them as the basis for lane cost and ETA. Watch the first real requests in Runs / Logs and compare a few returned distances and durations with lanes you know, before leaving the connection unattended.

What this connection does not do: it only provides route planning. It does not pull orders in, does not push anything back to another system, does not sync customers or inventory, and does not follow a vehicle while it moves. If a TMS screen shows no new orders after activation, that is expected — orders come from your order channels, and this connection only answers when TMS asks: how far, how long, which route.

FAQ#

Test fails right after the key is created, with the Routes API not reachable

The most common cause is that the Routes API was never enabled in the project that holds the key. The key can be perfectly valid as a key, but Google has no Routes service switched on for that project, so the computeRoutes call has nowhere to go.

Open Google Cloud Console, select the same project where you created the key, enable the Routes API there, wait a short moment for the change to take effect, then test the connection once more.

Test fails after the key was restricted to an API and an IP

The restriction you set on the key does not match how this system calls Google. If the allowed API list does not include the Routes API, or the allowed IP is not the address this system calls from, Google refuses the call even though the key text you pasted is exactly right.

In Google Cloud Console, open that key and check both parts of the restriction: the Routes API must be in the allowed API list, and the allowed IP must be the address this system calls Google from. Fix the restriction, save, and test once more — do not create a second key to work around a restriction mismatch.

Usage goes up even though the connection is not activated yet

Each test is a real call. The Routes API has no free probe endpoint, so the test can only prove the key works by asking for a real route — and that request uses one quota, exactly as the success message says: probe consumes one quota. Repeated testing before activation is real usage.

Test once. If it fails, read the failure, fix that one cause in the key, the project or the restriction, and only then test again. When the test passes, move on to the template and activation steps instead of testing again to double-check.

The key looks complete, but Google still refuses it

The pasted value is not the key Google issued for this project: a character was lost when copying, an extra space came along, or the key belongs to a different project where the Routes API and the restriction are set differently. The field accepts any text, so only the real call in the test can tell.

Go back to Google Cloud Console, open the key in the project where the Routes API is enabled, copy the full value again in one go, paste it into api_key without typing any part by hand, save and test once.

Distances and durations look wrong for a lane you know well

The route was calculated for a different travel mode than you expected. The template sends driving and driving-traffic as DRIVE, cycling as BICYCLE and walking as WALK, and the same two points give very different distance, duration and route in each mode — a walking result read as a driving result looks wrong even though the call worked.

Check which mode the TMS request used for that lane, compare it with the mode you had in mind, and recalculate with the intended mode. Judge the result only against the same mode — do not compare a BICYCLE duration with your driving experience.

Activated, but no orders or tracking appear anywhere

Nothing is broken. This connection never carried orders or tracking in the first place: its only capability is route planning, so activation adds no order feed and no vehicle positions — it only lets TMS ask for distance, duration and route when a shipment or tender needs a lane estimate.

Use your order channels for orders and your carrier tools for tracking. Use this connection only where a lane cost or ETA is needed, and check its work in the route result of a shipment or tender in TMS.