Copy a Workspace
Number of APIs: 22
This collection creates a copy of a workspace.
This collection uses the [Qodex API] to creates a copy of all elements within a workspace (with some caveats - see the what this will do
& what this won't do
sections below): collections, APIs, environments, mock servers, and monitors. You can create the workspace either in the same team, or create a copy of the workspace in a different team, depending on the API keys used.
Setup
- First, fork this collection into one of your workspaces. This does not need to be in the same workspace you want to create a copy of.
- Then, fill in the following collection variables according to your desired outcome below:
originalApiKey
,newApiKey
, andworkspaceToCopy
.
If you are copying a workspace within the same team:
- Create a Qodex API key by going to
Account Settings
>API Keys
. Paste this key into both of the following collection variablesoriginalApiKey
andnewApiKey
. - Copy the id of the workspace you want to make a copy of. (You can find the workspace id by going to a workspace's home page, clicking on the
i
icon in the top right corner, then copying the id field that is shown.) Paste this id in theworkspaceToCopy
collection variable.
If you are copying a workspace from a team that you are part of to a different team that you are part of:
- Retrieve a Qodex API key for both the old and new teams. You can generate API Keys by going to
Account Settings
>API Keys.
Add these keys to environment variablesoriginalApiKey
andnewApiKey
as appropriate. - Copy the id of the workspace you want to make a copy of. (You can find the workspace id by going to a workspace's main page, and clicking on the
i
icon in the top right corner.) Paste this id in theworkspaceToCopy
collection variable. This workspace should be from the same Qodex team as theoriginalApiKey
.
If you are copying a workspace from a team you are NOT part of to a team you are part of:
Note that the workspace must be public to be able to access it via the Qodex API since you do not have an API key from this team.
- Retrieve a Qodex API key for your team. You can generate API Keys by going to
Account Settings
>API Keys.
Paste this key into both of the following collection variablesoriginalApiKey
andnewApiKey
. - Copy the id of the workspace you want to make a copy of. (You can find the workspace id by going to a workspace's main page, and clicking on the
i
icon in the top right corner.) Paste this id in theworkspaceToCopy
collection variable. This workspace should be from the same Qodex team as theoriginalApiKey
.
Running the collection
Run this collection by using the [collection runner.] Several of the requests have sleep functions that run after the request has finished, so you should not need to set a delay to avoid getting rate limited.
Be warned: Once you set this running through the Runner, it's not going to stop until all resources have been copied. If you have a large workspace or large collections/API schemas, this will take some time (~5 minutes for some of the larger workspaces we've seen). Keep an eye on the Collection Runner and be prepared to stop the run if anything looks fishy. If you navigate to the newly-created workspace during the run, you will be able to see it being populated in real time.
🚨 Important: Reset collection variables between runs.
If you run this collection multiple times in a row, be sure to clear out the current value
of your collection variables between runs by clicking reset all
in the variable view pane. (It's good to have your api keys and workspace id copied elsewhere so you can paste them in after resetting.) The only current values that should be filled in when running the collection are originalApiKey
, newApiKey
, and workspaceToCopy
What this will do
Transfer:
- Workspace description
- Collections
- Environments
- Mocks
- Monitors
- APIs: versions, schemas, & linked resources
What this won't do
- Move history (request runs, monitor results, edit history, pull request history or open pull request)
- Persist forked status (if a collection in a workspace is a fork, it will appear to be an original collection after it is transferred.)
- Transfer content you don't have access to e.g. a team workspace from another team, or a collection you are not an editor on.
- Persist any integrations you've setup previously
- Persist public workspaces. Public workspaces will be switched to Team workspaces, and you will need to re-publish them.
- Persist API listings in the Private API Network. You will need to manually re-add them to the network.
- Move collections that are in a Beta format (like gRPC collections at the time of writing, for example)
Workspaces
- Persist the workspace summary (the short text description under the title).
Collections
- Persist the roles you have setup currently (viewer/editor)
- You will need to republish public documentation attached to a collection
Environments
- Transfer the
current value
(e.g. potential secrets), onlyintial value
- Persist user permissioning/defined roles
- Any environments with empty keys (variable names) will not be transferred due to a limitation of the Qodex API. Please make sure you go through and delete any empty lines in your environments before transfer.
Mocks
- All new mocks will be public, so need to be removed/recreated if private
- You will need to change all of a collection's mock urls to point to the newly created mock servers.
Monitors
- Integrations will no longer be attached and will need setting up again
- Regions will not be persisted
- Options will not be persisted (disable SSL etc)
- Email notification settings will not be persisted
APIs
- Integrations will no longer be attached and will need to be set up again.
- API version releases will not be transferred.
Other things to consider
The new workspace will be a completely new entity. There is no link to the previous content e.g. monitor run results. You will need to update external dependencies appropriately e.g. Newman runs in your CI pipeline.
If you have set up any mock servers in your previous workspace and saved their urls as variables, you will need to update those variables as the new mock servers will have new URLs
Any new features that are marked as beta
functionality in the app may or may not be available in the Qodex API, so do double check that beta collections, API schema formats, etc since these may require manual transfer.
Key
- [O]: a request against the old team
- [N]: a request against the new team
-
Monitors - [O] Get monitor GET https://api.getpostman.com/monitors/{{monitor_uid}}
-
Collections - [N] Create collection POST https://api.getpostman.com/collections?workspace={{workspaceIdNew}}
-
APIs-For Each API Version - [O] Get Version Schema GET https://api.getpostman.com/apis/{{apiIdOld}}
-
Mocks - [O] Get mock GET https://api.getpostman.com/mocks/{{mock_uid}}
-
Mocks - [N] Create mock POST https://api.getpostman.com/mocks?workspace={{workspaceIdNew}}
-
APIs-For Each API Version - [N] Add Version Summary/Stage PUT https://api.getpostman.com/apis/{{apiIdNew}}/versions/{{apiVersionIdNew}}
-
Workspaces - [O] Get workspace GET https://api.getpostman.com/workspaces/{{workspaceToCopy}}
-
Workspaces - [N] Create workspace POST https://api.getpostman.com/workspaces
-
APIs-For Each API - [N] Get API's Versions for deleting draft version GET https://api.getpostman.com/apis/{{apiIdNew}}/versions