×

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.

Categories
All
CRM-Salesforce
Salesforce Developers

Vehicle Level Constraints

Constraints that operate at the vehicle level allow one to control properties of the solution that apply to the individual vehicles. In cases where there is only one shift per vehicle, these are equivalent to constraints at the route level as there is exactly one route per vehicle. However, for multi-day, multi-vehicle problems, one may wish to control the properties of all the routes associated with a particular vehicle.

Very similar to the route_balance constraint, this constraint allows us to provide a min and max value for a metric summed across all the routes associated with the vehicles specified. If a list is provided for vehicle_ids , then the constraint is only applied to the specified vehicles. Otherwise, the constraint applies to all vehicles. When specifying the constraint, values for metric_id , min_metric_value , and max_metric_value must be given. The metrics are summed across all orders in the routes for the specified vehicle(s).

There are some cases where the duration of an order depends on who is servicing it. For example, a particular technician may complete a repair much faster than his/her colleagues. This variability can be expressed by using the work_speed parameter as a property of the shift. Since a vehicle can have multiple shifts, the work_speed parameter can be tied to the vehicle's operator instead of the vehicle itself.

In the example below, we illustrate a simple request where a manager explores the impact of "What if all my employees could work faster?" This can be achieved by trying different values of work_speed as shown below in the example vehicles array where a work_speed of 0.5 indicates that these workers are twice as fast as the default case.

Expand to view request sample

This experiment shows the manager that five more orders can be completed on this day if the workers are twice as fast since the 0.5 work_speed solution allows 22 order to be completed as opposed to 17 in the default case. The first image below shows the default work_speed 1 case. The second shows how additional orders are satisfied when workers are twice as fast.

img

A solution with work_speed = 1.0

img

A solution with work_speed = 0.5

Salesforce Developers

Order Level Constraints

There are solutions where items remain on a vehicle longer than desired in problems involving pickup and dropoff. Still, the solutions have shorter overall travel times. The additional_journey_time constraint controls consideration of these solutions. Additional journey time is the difference between an item's journey_time and the travel time directly from the pickup location to the delivery/dropoff location. The associated violation_increment is in seconds.

In the passenger pickup and dropoff example below, the journey_time , additional_journey_time , and dropoff_deadline constraints are used simultaneously. In the example, several vans start and end their routes at an Atlanta hotel. Each van has a six (6) passenger capacity expressed using the capacity_by_item array with passengers described as "items" using "item_type": "person" .

Expand to view request sample

img

The solution for this example does not violate any constraints. It utilizes all three (3) vehicles with a total travel time of approximately 7.5 hours. The longest journey for any passenger is short of one (1) hour. In contrast, removing the constraints and adding ones that enforce meeting pickup time windows and minimizing travel time, the solution requires two (2) vehicles and only six (6) hours of total travel time. Why would one not want a shorter overall travel time? Because in not considering the passengers' dropoff time, Mark and Oscar needlessly wait 3.5 hours at the airport before their eventual dropoff at the tennis tournament 5 hours later! This example illustrates many of the tradeoffs inherent in complex routing problems. Punishing customers with a terrible experience can be avoided with the right mix of constraints.


Prevent orders from being assigned to vehicles with attributes that are “undesirable” for some orders. The attributes_to_avoid are specified at the order level, and then vehicle attributes are compared against these values when evaluating the constraint. Thus there are no additional constraint parameters beyond the default. Violation increment has no impact on this constraint.

Expand to view request sample

img

Solution with no attempt to avoid incompatible attributes

img

We assign the attribute “Loud vehicle” to Vehicle 1, represented by the new solution's pink route. Many orders now request to avoid this attribute via the constraint, forcing the route for vehicle 1 to be very inefficient, traveling far from the start location to service orders. In particular, order 693192 boxed in red is right next to the start/end location for Vehicle 1. However, since this order has “Loud vehicle” in its attributes_to_avoid, Vehicle 1 does not visit it, forcing the green route to travel very far out of the way to hit this order.


Given an order with a dropoff_location_id , a dropoff_deadline enforces the latest time that the dropoff occurs. The associated violation_increment is in seconds.

In the passenger pickup and dropoff example below, the journey_time , additional_journey_time , and dropoff_deadline constraints are used simultaneously. In the example, several vans start and end their routes at an Atlanta hotel. Each van has a six (6) passenger capacity expressed using the capacity_by_item array with passengers described as "items" using "item_type": "person" .

Expand to view request sample

img

The solution for this example does not violate any constraints. It utilizes all three (3) vehicles with a total travel time of approximately 7.5 hours. The longest journey for any passenger is short of one (1) hour. In contrast, removing the constraints and adding ones that enforce meeting pickup time windows and minimizing travel time, the solution requires two (2) vehicles and only six (6) hours of total travel time. Why would one not want a shorter overall travel time? Because in not considering the passengers' dropoff time, Mark and Oscar needlessly wait 3.5 hours at the airport before their eventual dropoff at the tennis tournament 5 hours later! This example illustrates many of the tradeoffs inherent in complex routing problems. Punishing customers with a terrible experience can be avoided with the right mix of constraints.


The journey_time constraint specifies the maximum number of seconds between when an item is picked up and dropped off, delivered, or the route ends. For example, if refrigerated goods can only be on a vehicle for one hour before beginning to spoil, add the journey_time constraint with the max_journey_seconds parameter set to 3600. The associated violation_increment is in seconds.

In the passenger pickup and dropoff example below, the journey_time , additional_journey_time , and dropoff_deadline constraints are used simultaneously. In the example, several vans start and end their routes at an Atlanta hotel. Each van has a six (6) passenger capacity expressed using the capacity_by_item array with passengers described as "items" using "item_type": "person" .

Expand to view request sample

img

The solution for this example does not violate any constraints. It utilizes all three (3) vehicles with a total travel time of approximately 7.5 hours. The longest journey for any passenger is short of one (1) hour. In contrast, removing the constraints and adding ones that enforce meeting pickup time windows and minimizing travel time, the solution requires two (2) vehicles and only six (6) hours of total travel time. Why would one not want a shorter overall travel time? Because in not considering the passengers' dropoff time, Mark and Oscar needlessly wait 3.5 hours at the airport before their eventual dropoff at the tennis tournament 5 hours later! This example illustrates many of the tradeoffs inherent in complex routing problems. Punishing customers with a terrible experience can be avoided with the right mix of constraints.


Matches the attributes of an order with the attributes of the vehicle servicing the order. This can be used to enforce “skill matching” type constraints. Each order can be given a set of attributes. If any one of these attributes is not present in the vehicle's attributes that services this order, then a penalty is assessed. The violation_increment is in terms of the percentage points of the attributes matched in order. For example, suppose an order has five attributes, and three are matched by the vehicle that services it. In that case, 60% of the attributes are matched. A violation increment of 10 would mean that this scenario would incur a penalty of 4 times the original penalty amount since 40% of the attributes are unmatched and 40/10 =4.

Suppose some attributes are more important than others when assigning vehicles to orders. In that case, the constraint can assign different penalties at the attribute level. This is illustrated in the second example below.

Expand to view request sample

img

A solution to the original problem with no Match Attributes constraint.

img

Vehicle 1 (blue route) is assigned the attribute “speaks Spanish.” In contrast, Vehicle 4 (red route) has the attributes “speaks Russian” and “speaks Spanish.” Various order is now assigned these attributes, and we see that the blue route (vehicle 1) and red route (vehicle 2) now cover a much larger geographical area since the Match_Attributes constraints have a high penalty, effectively forbidding any vehicle from visiting these orders unless they have the correct attributes.

In this example, we have a more nuanced approach towards attribute matching. Our vehicles now have various attributes: paint, drywall, gutters, Charles, and Gavin. The skill (paint, drywall, or gutter) is enforced to match a very high penalty. The penalty for matching these attributes is higher than visit_range. The optimization will only visit an order if the skill is matched – visiting an order with inadequate skills incurs a higher penalty than missing to enforce this behavior. Additional Match_Attributes constraints enforce a “soft matching” with the preferred driver, either Gavin or Charles. These assignments are violated due to the lower penalty.

Expand to view request sample

img

In this example, the two unserved orders have the attribute “gutter.” The only route with the “gutter” attribute is the light blue route, which has less than a minute of extra time and can not visit any more orders. The pink route has 2.5 hours of slack time. Still, since the vehicle does not have the “gutter” attribute, the two unserved “gutter” orders are not visited by this vehicle.


Favor visiting high priority orders. If the priority p is greater than one and order with min_visits: m is visited k times in the solution with k < m , then we assess a penalty amount of (p – 1) * (m – k) . Thus, an order with a priority of 1 will not receive a penalty. Otherwise, the higher the order’s priority, the higher the penalty for not visiting at least min_visits times. No additional parameters are necessary for this constraint beyond the defaults as the priority information is part of each order object.

Expand to view request sample

img

Original solution with two vehicles and no order_priority constraint.

img

In the original two vehicle solution, we have 12 unvisited orders. We now add the order_priority constraint and specify a priority for many orders. In the resulting solution, we have 17 unvisited orders. Still, we visit all of the orders that have a priority greater than 1. In other words, we visit fewer customers but hit the important ones. Order 688798 at the bottom is boxed in black – we do not visit this order in the original solution since it is so far out of the way. However, the penalty for missing this priority ten order is now high enough that a lower overall score is obtained by adding this order to the solution.


There may be some cases where traversing a particular segment in a solution is undesirable (here, a segment refers to the path between two stops, not particular streets or roads). Such segments can be avoided by using the Prevent_Segment constraint, which takes in an array of pairs of location_ids and penalizes the solution if the segment connecting these pairs is present in the solution.

Expand to view request sample

img

The original four-vehicle solution before any segments is penalized.

img

The example introduces a Prevent_Segment constraint that penalizes links that start or end at location “loc36” (boxed in black) and the five other locations boxed in red. This results in the blue northeast route now traveling far out of the way since the Cumming order is effectively prevented from being serviced by the green route. This results in an overall increase in travel time, but all of these undesirable segments are avoided.


A scheduled appointment is more stringent than a time window. Appointments are expressed inside the order object, and they must include an appointment_start and appointment_end time. One can additionally specify a specific shift_id or a vehicle_id if the appointment should be satisfied by a particular shift or vehicle. Given some appointments at an order, service must begin precisely at the specified time and end at the specified time. Meeting an appointment can sometimes force the vehicle to idle/wait to meet the appointment, often resulting in fewer orders being visited due to the lack of flexibility in determining the routes. The scheduled_appointment constraint ensures that the appointment times given in each order are met – note that if appointments are given in the orders but there is no scheduled_appointment constraint, the appointments will virtually be ignored. To ensure that a specific shift or vehicle satisfies the appointment, one should invoke the scheduled_appointment_shift or scheduled_appointment_vehicle constraint. By applying a combination of these constraint types to a particular appointment, one can ensure that service at the order begins at the right time by a specific vehicle or shift. This technique can be useful when an existing schedule has been determined. A new disruptive event occurs - this leads to a so-called "schedule repair" problem. One of the considerations is to produce a new schedule that is "similar" to what was planned. By expressing this previously determined schedule as a set of appointments, one can generate a new optimization problem. Part of the objective is to adhere to this former plan.

Expand to view request sample

img

Shown above is the original two vehicle solution with no scheduled appointments. With two vehicles, we are left with 12 orders that cannot be feasibly visited.

img

Solution with scheduled appointments met at the orders with black boxes around them. This results in 14 unvisited orders vs. 12 unvisited in the case of 2 vehicles with no scheduled appointments. Also, note the pink route's relative inefficiency where stop three must be added to this route since a single-vehicle can't satisfy both of the scheduled appointments.


The span constraint allows us to ensure that the service at all orders in a provided set is completed within a specific time limit. The constraint offers an array of order_id ’s and a max_seconds value. The constraint is violated if the difference between the latest departure and earliest service starts exceeds max_seconds .

Expand to view request sample

img

The solution before adding the Span constraint.

img

In this example, we force a set of 9 orders in the center of Atlanta (inside the black region) to all be visited around the same time – the time between the earliest arrival and the latest departure must be <= 120 minutes. These orders are visited by two routes (cyan and purple), the earliest arrival being at and the cyan route, in particular, becomes relatively inefficient due to this constraint. Overall, travel time increases by about 30 minutes when we don’t have this constraint.


Individual orders can have time windows – intervals during which a vehicle must arrive and begin service. This constraint determines the importance of meeting time windows for each customer. By default, it applies to all orders. Still, if specific orders have more critical time windows, this constraint can be used multiple times for sets of order_ids. The constraint checks each order’s visit(s) against the time windows defined inside the order object.

Expand to view request sample

img

Original four-vehicle solution with no time window constraints

img

Shown above is the four vehicle solution after adding time window constraints. The bottom orange route changes substantially, and we can see backtracking in this route to satisfy the time windows. We add about an hour to the total travel time across all routes to satisfy all the time windows.


This constraint encourages the solution to visit orders with higher urgency values earlier on in the planning period. An order’s urgency must be in the range 1-99 and should be viewed as a percentile. An urgency of 90 means that we want to visit this order in the first 10% of the planning period. If violation_increment is specified, then an additional penalty is assessed for each percentile outside the desired range. So if the planning period is 10,000 seconds and an order has urgency 89, we will penalize a solution that has us visiting this order after ((100-89)/100)*10,000 = 1100 seconds. In this case, the violation increment is in percentage points.

Expand to view request sample

img

Original four-vehicle solution with no urgency enforced.

img

We add an urgency of 99 to 4 orders, indicating that we want them to be visited in the first 1% of the planning period's available time. These four orders now become one of the first two orders visited on the cyan and orange routes. This comes at the expense of increasing total travel time by about 90 minutes. Since it is impossible to visit all these orders in the first 1% of the planning period, we still incur a penalty from this constraint. However, since the constraint in the example utilizes violation_increment, a lower total score of the solution is obtained when we visit these orders as early as possible, even if we still violate the constraint.


The vehicle_coverage constraint allows one to specify that a small number of vehicles must visit a certain set of orders. Typically, this would be to force a set of orders to be covered by a single-vehicle. Still, it is flexible enough to handle more complex use cases. The constraint must specify a set of orders and values for min_vehicles and max_vehicles. If violation_increment is specified, then the units are expressed in the # of vehicles used to cover the set of orders. For example, if we have a penalty of 1000 with min_vehicles=1, max_vehicles=2, violation_increment=1, and four vehicles are used to service a set of orders. A penalty of 3000 will be assessed: 1000 for using too many vehicles, and an additional penalty of 2000 for exceeding the limit by 2.

Expand to view request sample

img

Original solution with no vehicle_coverage constraint.

img

Three widely spread orders (boxed in black) are added to the vehicle_coverage constraint with min_vehicles equal to 1 and max_vehicles equal to 1. The result is that Vehicle 1 now covers a huge territory and visits all three of these orders. Note that Vehicle 2 is now not used, leading to a very unbalanced solution in terms of the # stops per route and total travel time per route.


The visit_gap constraint will enable one to constrain these visits. The constraint can be restricted to a subset of orders if desired by specifying an optional order_id 's array, as shown below.

Ensure the spacing of visits at an order meets requirements. The gap between consecutive visits at a single order is measured as the difference in the first arrival time and the next arrival time. The constraint checks the visit spacing at each order against the values for min_days and max_days . If the amount of time between visits at an order falls outside this range, a penalty is assessed. The units of violation_increment are days.

In the full example below, we specify a problem with four vehicles where each vehicle has two shifts over two consecutive days. Many of the orders now require a minimum of two visits with a gap (min_days) of 1. If the visit gap constraint is not given, then the routes consecutively visit each of these orders that require two visits. This allows a solution with only three vehicles and another vehicle that is only active on one of the days. With the visit gap constraint in place, we must have at least one day (24 hours) between visits – all visit requirements are still met, but all eight shifts are required. The request below contains both the visit_range and Visit_Gap constraints.

Expand to view request sample

img

Shown above is the solution where no visit gap constraint is specified. All the orders that require multiple visits are now visited back to back on the route since there is no incentive to space out the visits. The vehicle starting at the northwest-most location is not needed at all.

img

The solution when we use both visit range and visit gap constraints. Visits to each customer location now do not occur within 24 hours of one another. All four vehicles are active on both days.


The visit_range constraint allows one to specify the number of times an order is visited. The constraint can be restricted to a subset of orders if desired by specifying an optional order_id 's array, as shown below.

Ensure an order receives a minimum or a maximum number of visits over the entire planning period. This constraint is particularly useful in problems that span multiple days where vehicles have numerous shifts. The default value of min_visits is 1 for any order. Suppose the visit range constraint is not included in a request. In that case, the optimization has no incentive to visit the orders. The default behavior would be not to visit any orders and return an empty solution. Since this is undoubtedly not the desired behavior, the user is protected if they do not include a visit range constraint. The optimization proceeds as if one wants to visit all the orders one time.

Suppose we use the default travel_time constraint so that one second of travel by a vehicle is equivalent to one penalty unit. In that case, we can use the visit range to express our problem as a revenue optimization problem. In the example below, we have two visit_range constraints – one for generic orders with a penalty of 1000 and another with a penalty of 40,000 for a set of “high profit” orders. Now the tradeoff is that for the specific order, if we must travel more than 2000 seconds out of the way to visit a location, we will choose not to do so. For the high-profit orders, if we must travel more than 40,000 seconds out of the way to hit these, we will decide not to do so. Suppose one has a dollar cost associated with a vehicle traveling 1 second and a dollar revenue amount for visiting each location. In that case, the objective function becomes an excellent proxy for the route's profit. The request below includes both visit range constraints (for the generic orders and the high-profit orders). Note that it is also possible to achieve this behavior with the order_priority constraint – here, we are just expressing this differently.

Expand to view request sample

img

When we account for revenue at the generic orders and do not treat any of the high-profit orders differently, note the unserviced orders boxed in red – these will be added to the second visit_range constraint in the next request.

img

After adding the second visit_range constraint for the high-profit orders, "constraint_name": "service high-profit orders" . Now note that all of the outlying orders missed in the first solution are now visited (green boxes above).

Read article
Salesforce Developers

CHANGELOG

Added

  • Details of the territory optimization service.
  • Introduced new constraints:
    • order_dependency
    • promptness
    • vehicle_attribute
    • vehicle_attribute_distribution
    • vehicle_attribute_duration_distribution
    • vehicle_balance
    • visit_range_across_shifts
  • Documented "easter egg" parameters which output debugging information. These parameters can be searched for using the phrase " FOR DEBUGGING ".
  • Unlimited mixing of vehicle types is supported. For example, one vehicle object can have a "type": "car" and another vehicle object can be "type": "truck" and so on.
  • Additional truck parameters:
    • num_trailers
    • weight_per_axle .
  • Where relevant, parameters now have default , minimum , and maximum .
  • OpenAPI Specification validators now included in pre-publication to ensure standardization followed.

Added

  • Documented the shift_duration_sum constraint
  • Documented the visit_same_location constraint
  • Documented the max_flights constraint
  • Added values for default constraint values when a request is sent without a constraints object

Changed

  • Updated max_distance docs to indicate 0 baseline is equivalent to minimizing distance travel
  • Corrected docs to indicate URLs expect one of /sync or /async
  • Clarified sources and destinations usage in matrix documentation
  • Clarified shifts description in routing
  • Corrected volume and weight descriptions in item object to indicate arbitrary units
  • Updated description of priority and urgency in order object
  • Updated directions description to reflect richness of response

Added

  • Published a "coverage status" map per country based on random matrix and routing tests
  • Added a strict, finite request/response data retention policy of maximum 90 days

Changed

  • Improved driving directions for mainland China
  • Fixed bug related to floating breaks some times not being honored
  • Improved handling of null values in request and updated to a meaningful error message.

Added

  • Routing optimization requests can now contain multiple vehicles of type: "truck" each with different parameters, e.g., height , weight , volume_capacity , etc. The routes for each truck are guaranteed to be compliant for that truck's parameters.
  • Standardized the expression of driving directions and polylines across all regions, including China and Japan.
  • Verbose driving directions included for all routing responses.

Added

  • Addition of a work_speed parameter to the shift object which controls the speed of work at an order. This parameter helps account for historical variations of technicians work speed versus the baseline duration one expects to complete an order.

    The default value is one (1). When set to a value other than 1, the duration at any order_id serviced during the shift is longer/shorter than the stated duration of the order. For example, "work speed": 1.2 results in the order taking 20% longer to complete.

  • Additional info incorporated into the response for problems involving drop-offs. Each stop in the route object's stops array now includes an array of order_ids_dropped_off .

  • New constraints to handle appointments:

    • scheduled_appointment_shift
    • scheduled_appointment_vehicle
  • New constraints for problems involving drop-offs:

    • journey_time
    • additional_journey_time
    • dropoff_deadline

Changed

  • Minor bugfixes in lesser used constraints involving journey time
  • In visit_gap constraint, time intervals expressed via seconds as well as days by using min_seconds and max_seconds to express desired visit spacing. Previously allowed only min_days and max_days .

Added

  • Documentation for existing constraints shown in examples but not explicitly noted in technical documentation.

Removed

  • Removed num_visits constraint since it is redundant with the visit_range constraint.

Added

  • New Max_Commute constraint added to handle first and last legs of routes
  • Optional rounding_minutes added to the round start of service events to nearest k minutes
  • For matrix calls with no path between source/end locations, added count and warning message to response

Changed

  • Updated worldwide map with latest street network and traffic data
  • A more cost-effective and efficient method of traffic window interpolation and storage
  • Improved error checking for errors in input requests (e.g., empty orders, invalid parameters)
  • Improved handling of complex pickup/delivery/-drop-off/replenishment problems
  • Improved handling of truck routing with changes to underlying map service
  • For cases of non-obvious input in routing JSON, changed HTTP return code from 409 to 422
  • Bug fixed in output JSON for items_delivered and items_picked up in pickup/delivery problems

Changed

  • Enforce the requirement that all vehicles with type truck have identical dimensions. Previously, the routing endpoint in the Optimization API accepted mixed dimension fleets; Now, the routing endpoint in the Optimization API responds with an error.

Added

  • Enforce requirement that all vehicles in a problem be the same type vehicle, i.e., do not allow the mixed fleet problem.
  • Submitting a request with an empty vehicle array now results in an error response.

Changed

  • Updated the behavior of the Visit Sequence constraint.
  • Solutions are now deterministic for repeatable behavior.

Added

  • Forced route structures are now supported

Added

  • A constraint for limiting distance traveled from a home location.

  • A constraint for handling orders at the same physical location, e.g., apartment buildings.

  • Handling of hard, soft, and floating breaks.

  • A constraint for handling orders at the same physical location, e.g., apartment buildings.

  • Handling of hard, soft, and floating breaks.

Added

  • Initial major release of all functionality.
Read article
Salesforce Developers

Get Started with Pardot API

Pardot’s REST APIs let you access and manipulate your Pardot data.

Extend Pardot

Build your own custom integrations to better support your business needs.

Augment Pardot Data

Clean and enrich prospect data, saving your sales reps hours of time spent on menial tasks.

Expand Reporting

Use the Pardot API to automate exporting visitor data to your own external analytics tools for richer insights.

Boost Your Business Value

Automate tasks, segment prospects with external data, or create custom external scoring models and update prospects.

To get answers to your questions about the API, or report a documentation issue, open a ticket with our Support team. Learn how.

If you're new to using Pardot APIs, see our Quick Start.

Versions 3 and 4

If your Pardot account has the Allow Multiple Prospects with the Same Email Address (AMPSEA) feature disabled, use version 3 of the Pardot API.

If your Pardot account has AMPSEA enabled, use version 4 of the Pardot API.

Versions 3 and 4 provide the same functionality, using slightly different input and output syntax to support working with prospects that share an email address.

See Version 3 and 4 Overview for information about using versions 3 and 4.

Version 5

Version 5 provides new functionality. You can use this version whether or not your Pardot account has "Allow Multiple Prospects with the Same Email Address" enabled.

See Version 5 Overview for information about using version 5.

Different Pardot environments are hosted on different domains, and you must use the correct domain in your request URLs. In general:

  • Demos, developer orgs, and sandbox environments are hosted on the domain pi.demo.pardot.com .
  • Training and production environments are hosted on the domain pi.pardot.com .

You can find the correct URL for your Pardot domain from Salesforce Setup.

  1. In Salesforce, click the gear icon to access Setup.
  2. From Setup, enter Installed Packages in the Quick Find box, and then select Installed Packages .
  3. Find the package b2bmaIntegration .
    • If the namespace prefix is "b2bma", use the domain pi.pardot.com in your request URLs.
    • If the namespace prefix is "pi3", use the domain pi.demo.pardot.com in your request URLs.

We enforce API rate limits in two ways:

  • daily requests
  • concurrent requests

Daily Requests Limits

Pardot Edition Allocated Daily Requests
Growth 25,000
Plus 50,000
Advanced 100,000
Premium 100,000

These limits reset at the beginning of the day based on your account time zone settings. Any request made exceeding the limits result in an error code 122

You can check your current daily usage on the "usage and limits" page.

Concurrent Requests

To interact with our API more efficiently, you can have up to five concurrent API requests. Any connection over five results in an error code 66 response.

These wrappers aren't officially supported, but are available to use with the Pardot API.

  • ruby-pardot
  • python-pypardot4 for version 4 of the API
  • pardot-java-client
Read article
Salesforce Developers

Use Cases for Pardot API

Extend Pardot to fit your business needs, providing access to your data for use in various ways. The API has so many possibilities that it can feel overwhelming to get started, so we’ve rounded up a few common use cases here. Start with these examples, then get creative.

You can use the Pardot API to clean and enrich prospect data, saving your sales reps hours of time spent on menial tasks. Automate data clean up tasks like normalizing picklist values, capitalizing names, and formatting phone numbers. You can also add data from your vendors by updating prospects via the API.

Example

Your manager asks you to fix all prospect name fields that are in all-caps or lowercase. They also want you to update prospect scores regularly, based on an internal scoring tool. You write some code that checks each prospect name and updates the capitalization. You set it up to run when a new prospect is added, keeping the database neat. You then set up an integration between your internal scoring tool and Pardot that updates the prospect score field every day.

Pardot Objects

  • Prospect: get prospect data, update prospect field values

Use the Pardot API to automate exporting visitor data to your own external analytics tools for richer insights.

Example The marketing team wants a detailed analysis of all the web analytics to see how much budget they need to drive clicks and sync web ad targeting. You automate a bulk export of Pardot visitor data, then import it into your company’s analytics tool at regular intervals.

Pardot Objects

  • Visitor Activity (via the Export API)
  • Prospect: get prospect data
  • Prospect Account: get prospect account data

Use the Pardot API to help you target the right groups of prospects, so you can optimize your messaging and personalization. If another system contains most of your data, you can segment prospects in that system instead of Pardot. In this case, use the API to get the prospect data you need. Do your segmentation analysis outside of Pardot so you can update the prospects. Then, import the updated prospects into Pardot and add them to lists for engagement programs and other marketing efforts

Example

A marketing manager at your company wants to create a Pardot list for a new marketing initiative, but the information for the segmentation criteria is hosted outside of Pardot. The manager gives you a list from an external database, and the list includes Pardot prospect IDs. You use the Create operation with the List object and create a Pardot list.

Pardot Objects

  • Prospect: get prospect IDs
  • List: Read or Create the List for the segment
  • List Membership: Add or remove prospects from the list
Read article
Salesforce Developers

Authentication

Prerequisites:

  1. You must have Salesforce OAuth set up in the org. To set up a connected app for OAuth, the "pardot_api" scope must be one of the selected OAuth scopes. Otherwise, OAuth flows other than username/password flow can't be used with the Pardot API. Check out this video for an example of how to implement OAuth.
Implement Salesforce OAuth for Pardot API
undefined
  1. You must have the Pardot Business Unit ID that you want to authenticate with. To find the Pardot Business Unit ID, use Setup in Salesforce. From Setup, enter "Pardot Account Setup" in the Quick Find box. Your Pardot Business Unit ID begins with "0Uv" and is 18 characters long. If you can’t access the Pardot Account Setup information, ask your Salesforce Administrator to provide you with the Pardot Business Unit ID.

  2. Authenticate with a user that is SSO enabled. An SSO-enabled user is one who can log in to pi.pardot.com using "Log In with Salesforce" or who can access Pardot using the Pardot Lightning App.

Pardot Account Type Salesforce Domain Pardot Domain
Production Account login.salesforce.com pi.pardot.com
Pardot Developer Org login.salesforce.com pi.demo.pardot.com
Sandbox test.salesforce.com pi.demo.pardot.com

OAuth 2.0 Flows

There are numerous OAuth 2.0 Flow types supported. The Web Server Flow is the most commonly used. For a list of all flows, see the OAuth 2.0 Flows Help page. Read the descriptions of the flows to choose the best one for your case.

After you get the access token, you must pass it and the Pardot Business Unit ID using the Authorization and Pardot-Business-Unit-Id headers.

Sample Request

Request must be made using HTTPS.

Request Parameters

Parameter Required Description
access_token X Access token obtained from Salesforce OAuth Endpoint
business_unit_id X Pardot Business Unit ID

If a valid access token is provided with a valid business unit ID, the Pardot endpoint works as expected.

Note: The Pardot API doesn’t enforce IP address restrictions that are configured using the Salesforce option "Enforce login IP ranges on every request".

Read article

Still Thinking?
Give us a try!

We embrace agility in everything we do.
Our onboarding process is both simple and meaningful.
We can't wait to welcome you on AiDOOS!