Welcome to Knowledge Base!

KB at your finger tips

This is one stop global knowledge base where you can learn about all the products, solutions and support features.

Salesforce Developers

Postman Collections

Run any of the examples provided in this section using our maintained Postman Collections. A "Public PROD Environment" ships with the Postman Collection. You need to edit this environment and replace the {{apiKey}} variable with your API key. If you do not have one yet, contact us to get one.

Salesforce Developers


The Distance Matrix service takes a set of locations and provides estimates for the travel times and distances between each pair accounting for predicted traffic based on years of historical data.

The Routing Optimization service is powered by an optimization engine designed to handle a huge variety of problems and aims to help you find your optimal business solution by giving you control over how your problem is solved.

Read article
Salesforce Developers

Distance Matrix

The Distance Matrix service takes a set of locations and provides estimates for the travel times and distances between each pair accounting for predicted traffic based on years of historical data. The travel times are returned for multiple "traffic windows," periods during which predicted traffic remains roughly constant. The Distance Matrix service has been engineered using patented methods for hyper-efficiency in handling unprecedentedly large requests: up to 7,500 locations at once. The current performance is orders of magnitude faster than competing services, and vastly less expensive.

As a reminder, a distance matrix describes the distances between all sets of points in a collection. For example, if we have locations A, B, and C, then the figure below represents the distance matrix:

Distance Matrix

Take note that the diagonals of the distance matrix have value zero (0) since the distance from a location to itself is zero. Also, notice that the matrix is symmetric; that is, the distance from A-to-B is the same as B-to-A and so on, which is not always accurate in the real world road network due to one-way streets, variations in traffic patterns, and other subtleties that our backend services take into consideration.

When supplied latitudes and longitudes for locations of interest, our backend services calculate travel times and distances between each location pair using predicted traffic estimated for multiple traffic windows: periods during which predicted traffic remains roughly constant. We provide a visual example of traffic windows in the figure below using simulated data.

Traffic Windows

In this exaggerated cartoon, notice that there are distinct periods during which the travel time is constant (colored, horizontal lines) that separate into different travel time windows (vertical blue lines). Our backend services take the same approach, and in each distance matrix response, there are eight different time windows all with their travel times.

Given a set of n locations (A, B, C in the example above), the Distance Matrix service returns a square n x n matrix with each entry in the matrix representing the time and distance of traveling between a pair of locations in different time windows. The Distance Matrix service allows users to filter further these results based on the specifics of the use case. For example, as illustrated below, users can designate that some locations are only sources and others are only destinations so that the result contains only information about traveling from a source location to a destination location, thus saving calculation time and calls.

Distance Matrix Source-Destination

The Distance Matrix service supports a variety of other options that allow users to filter results further. By default, the Distance Matrix service assumes the vehicle type to be a car. However, the Distance Matrix service allows users to specify types such as bicycle, pedestrian, and truck. Trucks are a unique vehicle type that takes additional parameters, such as weight and height. Details provided below.

The response from the Distance Matrix service is simple to understand, yet complex to describe syntactically. Other companies that provide a distance matrix service do not offer the traffic time window and filtering options. Hence our more extensive Distance Matrix service has a denser response format, which is detailed below. Represented graphically, a source-destination pair in our distance matrix is an array of distance and travel times for each traffic window, as shown below.

Distance Matrix Source-Destination

Read article
Salesforce Developers

Basic Distance Matrix

The simplest example of using the distance matrix service is to apply no filters (sources and destionations are unused) and request a single traffic window ("weekend": true). This simple format will result in an all-versus-all distance matrix for a single traffic window. An example of input and output is provided below.

Expand to view request sample
Expand to view response sample
Read article
Salesforce Developers

Large Requests

If you provide more than 200 locations in a distance matrix requesst, the Optimization API will process the request asynchronously due to the computation time being longer than a connection timeout. As a result, the service will respond with a jobid and URI that can be used to retrieve the input using the GET method on the same endpoint. An example is shown below.

Read article
Salesforce Developers

Location Classes with Force Containment

The meaning of "location classes with force containment" is requiring source location classes to be completely contained by the destination location classes. For example, if a skilled labor team has drywall and painting skills, we want that team to service job sites in need of drywall or painting skills, and not job sites in need of drywall, painting, AND electrical. The reason is obviously that a second team will have to cover the electrical work.

We abandon the vehicle-fueling station problem presented in the Sources and Destinations and Location Classes examples. Instead, let us consider three (3) teams of skilled technicians and six (6) job sites needing skilled labor. How would we submit a distance matrix to find which teams are closest to the job site most relevant to their skills? In this case, we'll make use of the force_containment parameter.

Our teams can have one or all of the following skills:

Available SkillsClass

To frame the problem further, listed below are our teams and their skills with associated classes for each:

team-paint+concrete+hvacpaint (0), concrete (3), and hvac (6)
team-drywall+electricaldrywall (1) and electrical (4)
team-concrete+plumbingframing (2) and plumbing (5)

Our job sites in this example are:

Job SitesSkill Needs
jobsite-paint+hvacpaint (0) and hvac (6)
jobsite-paint+concrete+hvacpaint (0), concrete (3), hvac (6)
jobsite-drywalldrywall (1)
jobsite-drywall+electricaldrywall (1) and electrical (4)
jobsite-paint+framing+plumbingpaint (0), framing (2), plumbing (5)

Unlike the prior examples where we broke down the problem into visual examples, the number of combinations here is too large to visualize simply. This is where the power of our Distance Matrix service shines!

To handle this complexity, all you need to do is apply the same location_class parameters as in the other examples, but this time we will add the force_containment parameter to ensure that when a job site needs multiple skills, ALL of those skill needs are met.

The complete request we will send to the Distance Matrix endpoint is given below.

Expand to view request sample

The complete response we receive from the Distance Matrix endpoint is given below. As expected, we only have travel_costs which show going from sources to destinations where all of the destinations location_class needs are met. The results we get are:

  • team-concrete+plumbing is not eligible for any job site because the only job site in need of concrete and plumbing work also needs all the other types of skilled work (HVAC, paint, etc.), which this team does not possess. Thus there are no travel_costs returned for them.
  • team-drywall+electrical is eligible for the jobsite-drywall or jobsite-drywall+electrical because they are the only team which can handle both types of work.
  • team-paint+concrete+hvac is eligible for two job sites — jobsite-paint+concrete+hvac and jobsite-paint+hvac — because they have the overlapping skills needed.
  • The remaining job sites do not appear in the response because there are no teams which can fulfill all the skill needs and thus no viable solution is available.
Expand to view response sample
Read article

Signup now!

Login / Signup as

Takes and get it done by experts

Find great opportunities and enjoy reading