AI importer

For inputs no direct importer handles — Markdown docs, curl logs, HAR captures — one prompt turns an API description into a Reqloom project.

Check the direct importer first

reqloom import handles OpenAPI, Postman, Insomnia, Thunder Client, Hoppscotch, REST Client, and Bruno natively — no LLM, no cost, deterministic output. Reach for the AI importer when your input isn’t one of those, or when you want actors and dependencies proposed. See reqloom import.

The prompt

One file: prompts/import/reqloom-import.md. Paste it into your model, paste your API description after it, and you get a project back in one pass.

your API description
        │
        ▼
  reqloom-import.md  ──►  a plan + open questions, then the YAML files
        │
        ▼
  reqloom lint       ──►  paste errors back, iterate
        │
        ▼
  reqloom run <op>   ──►  the only real proof

Typically 1–3 calls for a 50-endpoint API, in the low tens of cents. No API key and no integration — it’s a Markdown file you paste.

The workflow

1. Open a fresh chat with a capable model. This is a long structured prompt, so use your strongest available one rather than a mini variant.

2. Paste prompts/import/reqloom-import.md, then your API description — spec, exported collection, docs, or curl logs.

3. Read Part 1: the plan. You get a table of operations, a variable-flow table, the environment variables needed, and a list of open questions. This is the review gate and it takes about five minutes.

4. Answer the open questions in the same chat. Every inference the model couldn’t ground in your input lands here by design — answering them is far cheaper than debugging generated YAML.

5. Take Part 2: the files. reqloom.yaml, an environment file, one file per actor, one per resource. If your tool can write files, it will; otherwise copy each labelled block.

6. Lint it.

   reqloom lint --project my-api

   Paste any errors back. The messages name the operation and the error code, so they’re directly actionable.

7. Run one chain for real. This is the step people skip, and it’s the only one that proves anything.

   reqloom run order.create --project my-api

Why one prompt, not six

This was originally a six-stage suite — discover, plan, generate actors, generate resources, generate environment, fix lint. The staging existed to stop a model hallucinating detail and truncating long output, and those are real failure modes.

It was consolidated because the friction outweighed the benefit: 8–15 calls, manual copy-paste of intermediate artifacts between them, and a workflow that was tedious enough that people abandoned it halfway.

What actually prevents hallucination is giving the model the schema, not splitting the work. The single prompt embeds the full key reference, a worked example, and an explicit instruction to ask rather than guess — so there’s very little left to invent. The review gate survives as Part 1 of the response.

The original stage files are in git history if you want them.

What it gets right

• Resource and operation structure from paths and methods
• Actor proposals, including which endpoint issues a token
• Dependency edges where a path parameter clearly comes from another response
• !secret placeholders for every credential, so nothing lands in the repo
• Provenance on each operation recording what was inferred and why

What it cannot know

Two things, and no spec carries them either:

Whether a status code or body is correct. Docs drift from implementations. A plausible expect_status: 200 on an endpoint that returns 201 lints clean and fails on contact.

Which credentials are real. You get !secret ADMIN_PASSWORD and populate the keychain yourself. See secrets.

A clean lint is not a correct schema

reqloom lint validates structure. It cannot tell whether a path, body, or status matches the real API, and it checks that a reference’s scope exists rather than the field — so {{order.typo}} passes as long as an order resource exists. Budget one real run per chain you care about.

Auditing what was guessed

Generated operations carry provenance the runtime ignores but you shouldn’t:

    _provenance:
      source: ai_import
      verified_against: synthetic
      evidence:
        actor: "inferred from the /admin path prefix"
        extract.order_id: "guessed from a response example"

verified_against: synthetic means the model invented the sample response — the weakest signal there is. Once a real response confirms it, update it to live_capture. On a 100-operation import that’s how you track which ones you’ve actually confirmed.

Keeping cost and effort down

• Don’t import everything. Import the resources whose chains you’ll actually test. A 200-endpoint spec rarely needs 200 operations.
• Give it responses, not just requests. Sample response bodies are what make extractions correct rather than guessed.
• Redact credentials first. Replace real tokens with placeholders before pasting anything into a model. The schema references {{secret.X}} anyway.
• For a small API, write it by hand. Five endpoints and one actor is about twenty minutes with the authoring guide open, and you’ll understand the result. The importer earns its keep at 30+ endpoints.

Licence

The prompt is a designated paid component — not covered by the Apache 2.0 licence over the engine, CLI, schema, and desktop app. See LICENSE.

Next

• Importing OpenAPI — when to skip the LLM entirely
• Importing Postman — converting scripts to dependencies
• Importing curl logs — the hardest input
• Authoring guide — writing a schema yourself