Short answer: Treat the existing collections as evidence of the API, not as the destination. Convert them into an OpenAPI contract, then generate the request set from that contract. The migration is a one-time consolidation that replaces a maintained collection with a maintained spec.

What the collections already tell you

Every saved request is a clue: a path, a method, a body, a header, an expected response. They are a partial, practical description of the API, and they are the best starting material for a contract.

The migration path

  1. Export the collections and convert the requests into OpenAPI operations.
  2. Fill in the response schemas from real responses, then validate the contract.
  3. Generate the request set from the spec and compare it against the old collection.
  4. Once they match, retire the collection as the source of truth.

What to expect

The first pass will be incomplete: collections rarely capture every response and error. Treat the gaps as a punch list and close them against the running API. The result is a contract that is more complete than the collection it replaced.

The payoff

After the move, the request set is an output. New paths appear on their own, the docs and mocks share the same source, and the team stops maintaining a separate artifact.

This is part of the Powerduck vs Hoppscotch comparison. Next, read the AI comparison.