Cannot delete collection items via the Postman API


I am facing issues with cached/stall collection items

Steps to reproduce:

  1. Create a mock server with an empty collection (via Postman Client)
  2. Add request items with example responses (via Postman Api)
  • programmatically call POST to /collections/collectionId/requests
  • programmatically call POST to /collections/collectionId/responses?request=requestId
    I do the above 21 times, i.e. creating 21 requests with example responses.
  1. Reset the collection (sometimes I change the collection name with the PUT request)
  • PUT to /collections/collectionId
    "collection": {
        "info": {
            "name": "my_collection",
            "schema": ""
        "item": []
  1. Repeat step 2 (here is when the items compound, i.e. as if the PUT to reset the collection did not work)
  2. Verify the collection state
  • GET /collections/collectionId
  1. Observing the items returned for the call at step 5. they seem what they should be per the last created requests
  2. Observing the items in Postman Client, they just compound and if I attempt to delete any of them I get on the UI the following pair of messages:
  • requestName was deleted successfully.
  • Unable to delete request


If I call /collections/collectionId I now receive a response with no items, although they still appear in postman client and are callable via POST postmanMockServerUrl/requestName

not sure this is an UI problem, or caching one, but this worked seamlessly just a week ago or so.

Anyone has faced this issue before?

Hey @supply-technologist8 :wave:

Would you mind expanding on the details of this please? Is this all done via the Postman API or mixture of both?

Can you provide some example requests that your using?

If you feel it looks like a bug and you wanted to raise a product, you can do this but heading out to our Issue Tracker:

Hi @danny-dainton,

I only am using the Postman API. I use the postman client just to validate the results. I can see on a PUT /collections/collectionId that the items previously created remain in the client, whereby I try to delete them manually from the postman client and seeing the errors above, these ghost items just remain there. Even if I create new ones they collection just increase in size with the new ones and the “ghost” ones, really strange behavior.

My only way to “reset” all this is to delete the collection entirely - then delete the mock server associated with it and then recreate them…


Just had another interesting observation.

If I open the collection in a different browser, at first I see it in its correct state, once I open a request it somehow refreshes and adds on the rogue requests? Really bizarre.

Hey @supply-technologist8

Can you confirm that this was the issue you raised on the Tracker?

Hi @danny-dainton,

Yes absolutely!

Can someone help me troubleshoot this? It’s quite important

Sorry to be a pain, but I don’t want this automatically closed. Can anyone assist?

Hey @aerospace-geoscient2

Could you help out here as it’s related to the Postman API.

@supply-technologist8 Can you update the original post, please? It’s missing a lot of the context and details that you mentioned when raising the Bug Report.

Done, I have updated the original post with more details.

Thank you,

1 Like

Hi, Cris!
The first thing I noticed in your description: if you want just to update the name of the collection, please use the PATCH endpoint, not the PUT one. The PUT is intended for other usages (like replacing the whole collection).
In addition, can send the bodies of the POST request and responses so I can check if something is wrong? Just change or mask the sensitive information.

Hi David @aerospace-geoscient2 ,

Thanks for your reply, good point on using PUT wrongly, although the problem appears even if I do not change the name just reset the collection items. Would there be a DELETE collections/collectionId/items ?


    "name": "test",
    "url": "",
    "method": "POST"


    "name": "test",
    "responseCode": {
        "code": 200,
        "name": "OK"
    "headers": [
            "key": "Content-Type",
            "value": "application/json"
    "text": "{"anObject":"in the value of this text object I provide the response body json string content, so when I request the item I can see it in the response body"}",
    "language": "json",
    "requestObject": "{\"method\":\"POST\",\"url\":\"\"}"

Hi @aerospace-geoscient2,

Did you manage to find anything suspicious with the requests above?

I tried to execute my flow from postman client and it seems to be working alright, when I do from my app it gets all confused.

It’s me again, bumping it up before it auto-closes. Any update?


I was advised by @danny-dainton in a different thread that when creating mock requests/responses I need to provide a header - k: Accept v: application/vnd.postman.v2+json

while reading through the docs Postman API documentation it’s been said to use - k: Accept v: application/vnd.api.v10+json

for an end user like me what would be the difference between the two?

When moving from V9 > V10 of Postman there was a change in the way that APIs are created within platform.

To allow for either of the new and old versions to be created via the Postman API, that header (application/vnd.api.v10+json) is used when calling the API specific endpoints.

With the (application/vnd.postman.v2+json) header, there are some routes that are only currently on version 2 of the Postman API and without using that header in the request, those wouldn’t work.

For more granular details of these, @aerospace-geoscient2 would be able to expand on the information.

1 Like

Hi, Cris!
The application/vnd.postman.v2+json header was something temporary we were using in some specific endpoints, like the old collection individual items API. Now, this API is public in the regular Public Postman API (here), and the header is not used anymore.
Related to the application/vnd.api.v10+json header, it’s there only for the API endpoints, to distinguish if you are working with APIs created in Postman v9 or APIs created in Postman v10. Eventually, the v9 endpoints will be removed.

Hi @aerospace-geoscient2,

so would it make a difference to me if I create request and example responses with one or the other header value, feels right to use the latest and greatest?

You don’t have to use any header to create requests and responses, the v2 header is not used anymore, and the v10 header is just for the /apis/ endpoints (and it will be removed eventually).
If you pass a header, it will be simply ignored in the collection items API.

1 Like