Generate Dummy Data Using Postman with HubSpot APIs

When testing and developing with CRM platforms, a big challenge developers face is the need for realistic test data. Creating sample data manually is time-consuming and lacks the authenticity of real-world scenarios. Without properly associated test data, developers struggle to validate workflows, debug API calls, and ensure accurate data relationships before deploying to production. This is particularly relevant for teams building sales, service, or marketing automation, reporting tools, or integrations that rely on structured CRM data. Utilising Postman and HubSpot APIs, developers can simulate real CRM data, making testing and debugging more efficient, without disrupting live environments.

This guide is designed for:

• Developers building HubSpot integrations who need structured test data
• QA engineers and testers looking to automate CRM data creation
• Sales and marketing ops teams testing workflows without affecting live HubSpot data

To follow along, you should have:

• A basic understanding of HubSpot CRM APIs (such as companies, contacts, and deals).
• Familiarity with the Postman platform.
• Access to a HubSpot account with a private app configured.
• The following scopes for your private app: 
  • crm.objects.deals.write
  • crm.objects.companies.write
  • crm.objects.contacts.write
  • sales-email-read

💡 For more information on private app scopes, please check out our documentation

This is a comprehensive guide to setting up the collection in Postman, so in-depth Postman knowledge isn’t required, but please leverage our Postman and HubSpot blog to get you started with Postman and HubSpot private apps. A basic understanding of JavaScript is also helpful but not strictly necessary.

Implementing the Data Generation Collection

Import the collection

We will leverage our publicly available Data Generation Collection, which you can import into Postman using the import function. 

Authorising Postman and HubSpot

The next step is authorizing the connection between Postman and your HubSpot portal. The collection has preset variables to allow for automation and abstract unnecessary repetition. A HubSpot private app token variable has been added here to allow it to be called by the collection’s API requests. 

1. Select the HubSpot Data Builder collection and, under the collection tabs
2. Select the ‘Variables’ tab
3. In the access_token variable row, enter your HubSpot private app token in the ‘Current Value’ column.
4. Now hit Save

Now that the access_token variable is set, it will populate the authorization token in the collection. The individual APIs in the collection are also authorized as they reside under the collection, and the authorization option for them has been set to ‘Inherit from parent’. API calls can now be made to your HubSpot portal. To test that your Postman portal is authenticated, you can make a test call using the Create a Company request. You should get a 201 Created response. Check your HubSpot portal to see if a new company is created. 

Postman Variables

Postman variables are organized into different scopes, each serving a specific purpose:

• Global Variables: Accessible across all collections and environments, useful for values that remain constant.
• Collection Variables: Shared within a single collection, ensuring consistency across multiple requests. This feature will be utilised in this tutorial to share variables between API calls in the collection.
• Environment Variables: Tied to a specific environment, making it easy to switch between setups.
• Data Variables: Used in collection runs with external data files (CSV or JSON), allowing dynamic inputs for automated testing.
• Local Variables: Temporary variables that exist only during a request and are not stored beyond execution. Useful for non-persistent data when making multiple calls in a loop.

For more on Postman scopes, see here.

Postman has a built-in object that allows you to alter request and response data. This is the pm object. You can access variables at each scope depending on the request. Below is a method to set a certain variable as a collection variable:

pm.collectionVariables.set(variableName:String, variableValue:*)

This variable can then be called in other requests in the collection using:

pm.collectionVariables.get(variableName:String)

Using this method you can chain together requests and run them in sequence to create data with built in associations. In order to use this method we need to use a Postman tool called scripts to capture, edit and set data.

💡The collection used to accompany this tutorial has pre-built scripts that you can utilize as a guide to get you started using automation in Postman.

Postman Scripts

For this exercise it is worth understanding the structure of scripts in Postman. Postman scripts allow you to automate tasks within API requests. Postman’s runtime is based on Node.js, allowing you to run scripts at different stages of a request and help with tasks like setting variables, validating responses, chaining requests, and customising automation flow. For more on Postman scripts see here.
To create a script, select the ‘Scripts’ tab in a request window:

Pre-request Scripts: These run before an API request is sent. They are commonly used for getting data, setting variables, and modifying request parameters. In our example collection we have added functions to define the data that can then be requested in the body.

Here we can see the example used to generate the firstname and lastname for the Create a Contact request. These are first set to local variables, and then to Postman variables to be used in the current and other requests in our collection.

💡Postman has a built-in library that allows you to dynamically set data to variables using random data. Postman utilises the Faker library to generate this data. To access this in Postman, you can use the syntax:

We can now use this random name generator in our collection to generate a different random name for each iteration of our requests. To call the variable we have defined, we can structure the body of the request as below:

❗️Note the different syntax. Postman random data will be denoted by a $. When allocating custom variables assigned to Postman, we simply call that variable.

So why not just use random data across all properties in the body?

This can be done, but the first and last name will then not relate to the email, hence why we call the random firstname and lastname in the pre-request script and assign them to the relevant variables. We can then compile an email address with these variables and assign that to the randomEmail variable. This way we can ensure that the data in the contact and company records is associated correctly and looks coherent.

Post-response Scripts: These execute after a response is received. They are useful for validating responses, storing data for chaining requests, and triggering workflows.

Testing can be used for debugging and to ensure your collection is running correctly.  An example of a test (again utilising the pm object):

Building the Collection

This collection starts by creating a company. After the company is created we can then use the company name and domain to create the contact email address as we have shown. We can also save the new company ID to a variable that we can use to associate the Contact and Deal records.

We now have a series of requests that execute in a flow as shown below:

• A company is created: We save the company name and ID to use in subsequent requests.
• A contact is created: We associate the company using the company ID and add the contact email address using the company name. We save the contact ID.
• An email is created: We use the contact ID to associate the email to the contact.
• ❗️For the Create an Email API to execute correctly, you will need to add the hubspot_owner_id. You can get this by making a call to the Owners API endpoint. A variable for this has also been added in the variables section of the collection folder.
• countofContacts IF statement: If the countofContacts counter has not been met then loop back to create a contact, else move to Create a Deal.
• A deal is created: We use the contact ID to associate the deal.
• Iterations met: If the number of iterations outlined in the Runner criteria is not met then reinitialise the run, if it has been met, then End.

Running the Collection

There are a number of ways to start the collection in Runner:

1. Right-click on the collection folder and select Run collection.
2. In the collection folder UI, click the Run button.
3. Click the Runner button on the Postman taskbar.

This will open the Runner utility in Postman where you can run a full collection of requests. It also allows you to iterate over the collection so you can run it multiple times.

❗️If you do not see the HubSpot Data Builder collection in Runner, you can drag and drop it into the Runner window.

You should see the Run Order where the collection’s requests will be located. You can select and deselect requests from here to set up your flow. In the Runner settings on the right-hand side of the window you can choose how many times you want to iterate over the collection. You can also schedule runs or even add a document (like a CSV file) to dynamically add data to your collection run.

Once you have chosen your options you can select Run HubSpot Data Builder. I would suggest running this once to check for errors and also to check you are happy with the data structure in your HubSpot portal.

When Runner has completed execution you will get a response like the above. This shows us the requests that were completed and the status for each request thanks to  the pm.test function we placed in the response script of each API request.

Tips and Tricks

Creating Usable Data

Each iteration of the run will use a different company name. To get these names, we have used an array in the pre-request script, but there are a number of ways to get data for this process:

• Hard Coded: As we have done in this collection you can hard code a list of companies into an array and loop over the array. AI can be used here to generate random company names.
• API GET Request: Instead of initially using a POST request you could use a GET request to get data from HubSpot or any 3rd party data repository.
• CSV upload: Postman has a cool feature that allows you to add a data file to the Runner request. Postman will look at the body of a request and pull data from the file to populate it. This is located in the Runner configuration settings:

Useful Postman Functions

replaceIn: This function is used alongside the random data variable to dynamically assign new random data at the time of execution. This is useful in our scenario to ensure a new value is assigned to the variables across multiple iterations.

pm.variables.replaceIn('')

setNextRequest: In this collection we wanted to add multiple contacts to every company. To do this, we can break out of the linear Runner flow using a Postman function. The function we use is pm.execution.setNextRequest. This function overrides the Runner execution and tells Postman to go to a specific request instead. In our case, after the email is created on the contact record, loop back to create an additional contact. We can then wrap this in an IF statement and set conditions. We have added a counter variable that tracks the number of contacts. When this has been met, the next request is set to Create a Deal.

Summary

With the methods outlined in this blog, you have multiple ways to generate structured test data that accurately simulates real-world CRM interactions. This approach makes testing more efficient, repeatable, and scalable without affecting live environments. 

Use our collection to set up your own HubSpot Data Generator in Postman today and see how it transforms your testing process! While we only tackled one scenario that developers come across, the opportunity to be creative here is endless. Try exploring HubSpot’s API documentation and HubSpot's Public API Workspace to see how you can iterate on our collection and make it your own. Be creative!