Automate backups of your Postman Collections with the Postman API
Postman enables you to manually back up your data and recover deleted collections. While keeping backups of your Postman Collections is always a good idea under normal circumstances, it can be a real lifesaver when:
- You have automatic processes that modify collections. In such cases, you may want to back up collections before there are any changes. Then, if there’s an error, you can safely roll those changes back.
- There are accidental manual changes you want to revert.
But did you know that you can use the Postman API to programmatically maintain a copy of your collection? You can do it by using the Postman API’s GET and PUT collection endpoints, a transfer method, or the new pull source changes endpoint.
Using the /collections GET and PUT endpoints
The Postman API offers a GET /collections/{id}
and PUT /collections/{id}
endpoint that you can use to create a collection backup. These endpoints read a source collection and then update an empty destination collection with the source collection’s contents.
To simplify the process, we’ve created a collection and environment you can fork and run. You can also use this collection in your CI/CD environments using the Postman CLI.
Prerequisites
- An empty collection in a workspace. This will be your backup (destination) collection. During the process, this collection will be renamed to use the original (source) collection’s name.
- The empty backup collection’s ID.
How it works
When you run this collection, it:
- Performs a GET of the source collection using the GET
/collections/{id}
endpoint. - Processes the GET response and removes all the
id
,_postman_id
, anduid
fields. This is necessary for the next step. - Runs a PUT
/collections/{id}
on the backup destination collection with an emptyitem
list in the body. This cleans up all the data in the destination collection. - Runs a PUT
/collections/{id}
using the processed payload (without the ID fields) into the destination collection.
Pros
- It’s a simple process: it reads from the source collection and overwrites the destination collection.
- It requires fewer requests to complete than the Transfers API method, so it is best for small collections.
Cons
- It requires some code in the collection scripts to remove the ID fields from the source collection’s response.
- It performs several requests to the Postman API, so Postman API rate limits may apply.
- Not recommended for large collections because the process can take some time to complete.
Using the /collections/{id}/pulls endpoint
The PUT /collections/{id}/pulls
endpoint lets you pull changes from a source collection into a forked (destination) collection. The process consists of a single request, which you can run with a cURL command:
curl --location --globoff --request PUT 'https://api.getpostman.com/collections/{{forkedCollectionId}}/pulls' \ --header 'x-api-key: PMAK-XXX'
Prerequisites
- Create a fork of the collection you want to back up.
- The forked collection’s ID.
How it works
Use the PUT /collections/{id}/pulls
endpoint to pull changes from the source into the destination collection:
- Fork the source collection in the Postman app or use the Postman API Create a fork endpoint.
- Perform a pull changes request on the forked collection. To avoid conflicts when you pull changes, make certain that you don’t modify the forked collection. For large collections, this request can take several seconds to complete.
Pros
- This is the fastest and easiest way to update a collection because it only propagates changes. It consists of creating a fork of the collection and updating it periodically with a pull of the changes on the source collection.
- The process is a single API call that you can implement with a cURL request and integrate into your CI/CD processes without exceeding your Postman API rate limits.
Cons
- If the backup collection changes, the process may fail due to conflicts.
Using Transfers APIs
The Postman API has Transfers endpoints, which let you move collection items—such as requests and responses—between different collections and folders. These endpoints copy the collection’s items (folders and requests) from the source collection into a backup collection.
This is a variant of the GET and PUT method, but instead of retrieving all the collection contents, it just gets basic information about the collection. It uses the Postman API’s Transfers endpoints to iteratively copy that information into the backup collection.
We’ve created a collection and environment you can fork and use to make backups of your collections.
Prerequisites
- An empty collection in a workspace. This will be your backup (destination) collection. During the process, this collection will be renamed to use the original (source) collection’s name.
- The empty backup collection’s ID.
How it works
When your run this collection, it:
- Retrieves the source collection data using the GET
/collections/{id}
endpoint and passing themodel=minimal
query string parameter. This returns all folders and requests located in the collection’s root level. - Performs a PUT on the destination collection using the previous data, but passes an empty
item
list. This copies the collection’s variables, scripts, and authorization information. - Loops over the
rootLevelFolders
property and uses the POST/collection-folders-transfers
endpoint to copy each folder into the backup collection. - Loops over the
rootLevelRequests
list and uses the POST/collection-requests-transfers
endpoint to copy each request into the backup collection.
Pros
- This method is best for very large collections because it does not process the entire collection in a single request.
Cons
- It’s an advanced process that requires some code and uses a complex collection.
- It performs several requests to the Postman API, so Postman API rate limits may apply.
- It is a slower process versus the pull strategy.
Next steps
The Postman API provides full CRUD capabilities that let you programmatically back up your collections into another collection in different ways.
Depending on your use case, you can fork and pull changes or read and copy the information using different strategies. We’ve shown you some possible scenarios and implemented some collections with these solutions.
Do you have any use cases related to collections that require managing them programmatically? We would love to hear about it—please let us know in a comment below!
What do you think about this topic? Tell us in a comment below.