Last month I integrated a payments provider the way everyone does. I pasted a curl command into ChatGPT, then the 401 response, then a screenshot of the docs page I could not link to, then I typed "no, the idempotency key goes in a header." Two days later the agent made the same mistake again, because none of that context survived the chat.

Here is how that same integration goes in Powerduck today, step by step.

1. Get the contract into the workspace in one drag

I drag the provider’s file into the workspace. The same import flow accepts five starting points and converts or upgrades everything to OpenAPI 3.2:

  • an OpenAPI or Swagger file (Swagger 2.0 and OpenAPI 3.0/3.1 are upgraded in place);
  • a Postman collection;
  • a single cURL command;
  • a Git repository;
  • or a URL pointing at a spec.

Thirty seconds later I am looking at the real contract, not my memory of it.

2. The assistant reads before it writes

When I ask "which endpoints do I need for a refund flow?", the assistant does not guess. It calls read-only tools against the document: spec.overview for the shape of the API, spec.listOperations for every METHOD /path, and spec.getOperation for the full definition of the endpoints it intends to use. Its answer quotes the actual parameters and status codes in the file.

The same applies to schemas: spec.getSchema returns the component with its required fields and descriptions, so generated sample bodies match the contract instead of looking plausible.

3. Send the real request without a CORS fight

I open the operation in the Request workspace and send it. Requests execute through the local Node main process, not the web view, so two annoyances disappear at once: cross-origin restrictions never block the call, and the bearer token never shows up in a browser network panel. The status, headers, body and timing render in a tab, and I can keep several calls open side by side.

Values that change between runs live in variables across four scopes — globals, collection, environment and local — so the token and the merchant id are typed once. My personal sandbox base URL goes in a custom environment, which never edits the contract; the document’s declared servers stay read-only.

4. Promote what worked back into your own spec

A scratch request that turns out to be a keeper promotes into my own OpenAPI document through an add-to-spec dialog: pick the path, method, tags and folders, check whether the operation already exists, and it lands in the spec. The exploration becomes contract, not a forgotten tab.

5. Hand the same contract to the coding agent

This is the part that replaces curl-pasting for good. The spec is served as an MCP server — locally from the desktop app, or as a managed endpoint from Cloud — and my coding agent discovers and calls the exact operations with the exact arguments. It cannot invent a header, because its tool descriptions are the contract. When the provider ships a new field, I update one file and every agent gets the new truth.

A chat window gives an agent a screenshot of your API. The spec gives it the source code. Serve the source code.

The full loop takes about ten minutes and survives every context-window reset. The quickstart walks the same path on your own API.