Create an endpoint from a description

Instead of building an endpoint field by field, you can describe it. In a collection, choose New endpoint, keep Describe it selected, write what the endpoint should do and choose Draft endpoint.

A model reads your description and drafts a complete endpoint definition:

• the inputs callers send (typed variables, with nested objects, enums and defaults),
• the output as a JSON schema (fields, types, allowed values, descriptions),
• a system prompt and prompt that use those inputs,
• a name, slug and model,
• example inputs for a first test run.

The draft is checked against the same rules as a saved endpoint before you see it. Drafting takes a few seconds, sometimes a minute or two. You can cancel while it runs. Nothing is created until you review the draft and choose Create endpoint. The endpoint then opens in the editor with the Test panel filled with the example inputs, so Run test works straight away.

If you'd rather build it yourself, choose Start blank to create an endpoint from a name only.

Writing a good description

Say three things: what callers send, what you want back, and the rules the answer must follow. Name the allowed values when a field has a fixed set, and give ranges for numbers.

A description that drafts well:

Triage incoming service requests: read the subject and body, pick a category
(billing, technical, account, other) and a priority from 1 (low) to 5 (urgent),
say which team should take it, add a few tags, and draft a short, friendly reply.
Requests from enterprise customers get at least priority 3.

Another one, for extraction:

Extract the fields from an invoice's text: vendor name, invoice number, issue and
due dates (YYYY-MM-DD), currency (ISO code), subtotal, tax and total as numbers,
and the line items with description, quantity and unit price. Leave a field null
when it isn't in the text.

Descriptions that are too vague ("do support stuff") produce generic drafts or fail with Couldn't draft a valid endpoint from that description. Add detail and try again. Descriptions are 10 to 4,000 characters.

Under Advanced you can pick the model that writes the draft; by default Scalaix chooses one. It is not the endpoint's model: the draft uses the catalog default, and you can change it in the editor.

Review checklist

The draft is a starting point. Before you create it (or right after, in the editor), check:

• Inputs are what callers actually have. Remove inputs your callers can't supply, and add ones they can (an account plan, a language). Every input becomes part of your API.
• Enums are complete. Check each list of allowed values, for inputs and output fields alike. A category the model can't choose is a category it will never answer.
• Required fields are right. Mark inputs optional, with a default, when callers can leave them out. Mark output fields required when your code relies on them.
• The prompt states your rules. Business rules (priority floors, what never to promise, reply length, tone) belong in the system prompt. Read it once as if you were the model.

Then run a few tests with real-looking inputs, adjust, save and publish.

Billing and usage

Drafting is billed like any other model call, at the drafting model's price, from your team's credits. It appears in Usage with kind assist (shown as Drafting) and no key, including drafts that failed. If your team is out of credits, drafting stops with a link to Billing; if the drafting model has no provider key, pick another one under Advanced.