Work with Postman collections

Postman collections help test public API requests and share an integration's client contract. Importing requests and generating a collection are different workflows.

Generate requests for a client#

Open Workflows → Postman Collection and choose the available controller/action scope. Review the generated environment, URLs, authentication setup, headers, and request bodies before running the collection.

Set the collection's environment values to your sandbox host and credentials. For signed requests, preserve the generated signing behavior and verify the exact path/query/body used by the request.

Run a harmless read first, then inspect the matching action log. Keep write requests disabled until their target data and external effects are understood.

Import an existing collection#

Use the supported Postman import flow when bringing existing API request definitions into Cloudgate. Inspect the source collection's base URLs, variables, methods, headers, bodies, and scripts.

After import, check the generated controller paths, action routes, and Request nodes. Resolve variables into deliberate selectors and resource configuration. Collection scripts and provider-specific behaviors may require manual adaptation; confirm the resulting workflow rather than assuming every Postman feature became executable logic.

Maintain useful examples#

Keep examples for success, validation failure, denied access, and an empty response. Describe required fields and the expected status/result.

Saved samples are not a schema. A response from a detail endpoint does not define the body accepted by a create or update endpoint. Verify the actual contract before using the example to build a form.

Share safely#

Use environment placeholders and remove current tokens, cookies, and private records before sharing a collection. Document how recipients obtain their own authorized credentials.

For signing details, see HMAC request signing. For broader validation, see testing workflows.