Verified against ChatGPT · 2026-07-25
Turn a plain-English API description into an Actions schema a Custom GPT can actually call
Produces a valid OpenAPI schema, the matching authentication configuration, and call-safety guardrails a GPT Action needs — from a description of an internal API — so the GPT calls the endpoint safely, not just successfully.
The prompt
Ready to copy — highlighted parts are example details you can swap.
You are converting a plain-English description of an API into a working GPT Action for a Custom GPT — an OpenAPI 3.1 schema, an authentication block, and the operational guardrails the Instructions field needs so the GPT calls this API safely, not just successfully.
API DESCRIPTION
Our internal billing service — REST API at billing.internal.acme.com, issues refunds and looks up invoice status.
ENDPOINTS TO EXPOSE
GET /invoices/{id} and POST /refunds — not the customer-deletion or plan-change endpoints, even though they exist on the same service.
AUTH METHOD
Static API key in an X-API-Key header, issued per-GPT from our internal admin panel.
DESTRUCTIVE OR IRREVERSIBLE OPERATIONS
POST /refunds — issuing a refund cannot be reversed through this API once it's confirmed downstream.
RATE OR SCOPE LIMITS
No more than one refund call per conversation without the user explicitly restating the amount and invoice ID a second time.
SCHEMA RULES
Write every operation with a concrete, non-generic operationId and a description field detailed enough that a model deciding whether to call this endpoint doesn't have to guess what it does from the path alone — "createRefund," not "postAction2." Every parameter needs an explicit type, whether it's required, and, for any enum-like field, the literal list of accepted values rather than a free-text description of what values might work; a GPT filling in a parameter from a loose description will invent a plausible-looking value that fails validation, where an explicit enum makes the wrong choice mechanically impossible. For any endpoint listed under destructive or irreversible operations, mark it clearly in its description as requiring explicit user confirmation before the call is made, and separately write the exact confirmation-gate instruction for the Instructions field — the schema alone cannot enforce a human-in-the-loop step; that has to live in the instructions the model actually reads before deciding to call the action. Set the auth block to match the stated method exactly — API key in header, OAuth with the specific scopes named, or service-level auth — and never default to a placeholder auth scheme when the actual method wasn't fully specified; ask a clarifying question instead of guessing at how credentials are handled, since a wrong auth block fails silently as an unauthorized error a real user has no way to diagnose. If a rate or scope limit was named, encode it as an explicit instruction in a matching Instructions-field line since the OpenAPI schema itself has no mechanism to enforce a conversational-level limit like "don't call this more than three times per session."
OUTPUT FORMAT
1. The OpenAPI 3.1 schema as valid YAML, one code block.
2. The authentication configuration exactly as it should be entered in the GPT Builder Actions auth screen.
3. The confirmation-gate instruction lines for the Instructions field, one per destructive operation.
4. A one-line privacy-policy note stub, if this Action will be shown to anyone besides you.
5. Anything in the original API description that was too ambiguous to encode safely, listed as an open question rather than resolved by a guess.Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
OpenAPI's enum constraint is enforced at the schema-validation layer before the call is even attempted, so an explicit literal list of accepted values eliminates a whole class of failed calls that a descriptive-text parameter would otherwise produce — the model would confidently generate a plausible but invalid value and only find out it's wrong from an error response it then has to interpret and retry blind. OpenAPI itself has no concept of "ask the user before calling this" — that gate exists only if the Instructions field explicitly states it, because a Custom GPT decides whether and when to invoke an Action based on the natural-language description and the running conversation, not on any schema-level permission flag, so a destructive endpoint with a technically correct schema and no confirmation instruction is one ambiguous user message away from being called without anyone meaning to trigger it. A vague or placeholder auth block produces a generic unauthorized error inside the GPT that the end user — who never sees the Actions configuration — has no way to connect back to a misconfigured auth scheme, so getting it exactly right, or explicitly flagging it as unresolved, matters more than almost anything else in the schema. Conversational-level limits like "no more than one refund per session" have no schema representation at all — OpenAPI describes a single request/response contract, not a policy across a conversation — so the only place that rule can live is as an explicit natural-language instruction the model reads and follows on its own judgment.
Verified against
ChatGPT GPT-5.1 (GPT Actions) · 2026-07-25
Changelog
- 2026-07-25 — Initial publish, verified against ChatGPT GPT-5.1 GPT Actions configuration.
Building this for real?
This is a free starting point. If you'd rather have what Scult builds built and running for your business, that's Scult's day job.
EXPLORE WHAT SCULT BUILDS
