Generate Postman Collection

Describe the integration flow you need — which payment rails, countries, and operations — and the generator will build a Postman Collection v2.1 with all requests ordered, headers pre-configured, and test scripts to chain tokens and IDs between steps.

Note

Open the Workbench at the bottom of any page and switch to the Postman tab to generate the collection without leaving the docs.

The generator is hybrid: AI interprets multilingual prompts into a small, validated Conomy flow plan; deterministic templates then generate the collection. The rail catalog is generated from the OpenAPI x-rail-catalog, payment-node-type, and node-wrapper schemas, so the templates can render every published rail node instead of a hardcoded subset. This keeps meetings flexible while preventing hallucinated endpoints, missing rail nodes, or invalid fields such as externalId.

What you get

The generated collection includes:

• Setup folder — POST /auth with a test script that saves access_token to your environment automatically
• Identity and account context — creates or stores the identityId and internal accountNumber used by the generated flows
• Rail discovery — calls GET /payments/available-products before building payment nodes, and destination/origin discovery when the flow requires it
• Step folders — one folder per logical step of the flow, in the correct order
• Pre-configured headers — x-api-key, Authorization: Bearer {{accessToken}}, conomyhq-api-version
• Realistic request bodies — required fields filled with example values based on the OpenAPI schema
• Chaining scripts — test scripts that save IDs (identityId, paymentId, etc.) so later requests can reference them
• Collection variables — baseUrl, apiKey, clientId, clientSecret, accessToken ready to fill in
• Rail-specific nodes — each payment node includes the matching rail object (cvu, pse, pix, spei, etc.)
• OpenAPI-backed rail coverage — generated bodies use the node key and required fields from the API Reference for all published rails
• Webhook setup when requested — PUT /clients/webhook, GET /clients/webhook, and an example signed callback payload

How to use

1. Import the .json file into Postman via File → Import
2. Create a new Environment in Postman and fill in:
   • apiKey — your x-api-key from the Sandbox Dashboard
   • clientId and clientSecret — from Settings → API Keys
   • baseUrl — already set to https://api.conomyhq.com/sandbox
3. Run Get Access Token first — the test script saves the token automatically
4. Run the remaining requests in order

Payment context used by the generator

The indexed context behind these rules is maintained in Postman Generator Context.

• An identity is the actor that owns accounts and determines which rails are enabled.
• An ACCOUNT node is an internal Conomy balance.
• Pay-in flows use an external rail in origins and an internal ACCOUNT in destinations.
• Pay-out flows use an internal ACCOUNT in origins and an external payout rail in destinations.
• Static CVU pay-ins start with GET /payment-origins; the client sends the fixed cvu.code in the CVU origin when creating the payment.
• Dynamic CVU pay-ins create a payment with a CVU origin and no cvu.code; Conomy returns the dynamic origins[0].cvu.code after POST /payments/{id}/captured or the follow-up status read.
• CVU pay-outs use CVU as a destination and require the recipient cvu.code.
• PCT is an Argentine QR pay-in rail. It does not use GET /payment-origins, cvu.code, or a generated capture step; the response stores pct.qrCode, which is a simulator URL in sandbox/staging and the QR payload in production.
• Webhook configuration uses PUT /clients/webhook and GET /clients/webhook. Use flavor: "cvu.static" or flavor: "cvu.dynamic" only when those CVU flows need separate URLs.

Multi-flow example

Use a prompt like this when you need a complete Argentina CVU/PCT collection:

Flujos requeridos en postman:

1- Pay-in
a) Desde CVU dinámico
b) Desde CVU estatico
c) Desde PCT (QR)

2- Pay-out
d) Hacia CVU
e) Hacia Bank Account

Información adicional:
f) API de configuración de webhook

That generates setup, identity/account context, rail discovery, the three pay-in flows, the two pay-out flows, and webhook configuration in one collection.

Tips

• Keep the flow description concise and specific. Mentioning the country and rail helps (e.g. “PSE Colombia”, “ETPAY Chile”, “SPEI Mexico”).
• Mention direction explicitly when it matters: pay-in, payout, static CVU, or dynamic CVU.
• Generated payment bodies do not include externalId; chain from Conomy IDs returned by each response.
• Generated payment bodies choose one amount mode: purchaseAmount with purchaseCurrency, or totalAmount with currency. They never send both in the same request body.
• Static CVU flows start with GET /payment-origins and create the payment with that fixed cvu.code; dynamic CVU flows create and capture a payment so Conomy returns origins[0].cvu.code.
• Webhook flows use /clients/webhook.
• The generator follows the same contracts as the API Reference, recipes, rail docs, and OpenAPI node-wrapper schemas.
• Generation uses flow templates and validation rules, so the downloaded collection is available immediately.