Skip to main content

​
AI Extension Builder

The Builder turns a sentence into a Custom Extension. You describe the integration you want — “when an order is paid, push it to my ERP”, “quote shipping rates from my own carrier” — and it returns a complete extension: the recipe or handler code, the trigger, the secrets it needs, and a test plan. Its inputs are this deployment’s own API surface: the OpenAPI spec, the SDK, the extensions runtime, and the event catalogue. So the endpoints, event names, filter operators and field names it uses are read from what is deployed rather than recalled — and where it can’t find something you asked for, it asks instead of substituting a close-sounding alternative.
A build produces a draft. You review it, connect its secrets, and test it before enabling it — particularly the outbound call, which is the one part shaped by your description rather than read from the API.

​
Where it lives

In your admin, under Settings → Extensions → Build with AI. Agencies get the same builder inside their own portal, for the billing rails they offer their merchants. Each build consumes AI credits from your plan’s allowance, so an unclear prompt that produces something you discard still costs a little. Being specific is cheaper as well as better.

​
What it produces

A build returns one extension plus the context you need to judge it: If your message isn’t a build request — a greeting, or a question about what it does — it answers directly instead of inventing an extension to satisfy the prompt.

​
Writing a good prompt

The Builder decides four things from your description: the kind of extension, the trigger, the execution mode, and the shape of the outbound call. A prompt that settles those needs no follow-up.
The first names the event, the condition, the destination, the auth style, and the payload — it builds in one pass. The second could be a dozen different extensions, so the Builder asks rather than guesses. Three things worth stating explicitly when they matter:
  • Which event, if it’s an automation. “When an order is paid” is unambiguous; “when something changes” is not.
  • Where it runs. Say “I’ll host the endpoint myself” for a remote extension, or let it choose.
  • What the other system expects — the header, the body shape, the auth. The Builder cannot inspect your API.

​
Reviewing the output

Read notes first: it explains what the extension does and flags anything unfinished. Then check four things.
order.paid and order.created are not the same event — one fires when money arrives, the other when the order is placed, which may be before payment. An automation on the wrong one runs at the wrong moment.
secret_refs lists aliases, not values. Connect each one in the extension’s settings; until you do, the handler reads nothing and the call to your system goes out unauthenticated.
This is the part the Builder is least able to verify — it knows Galactic Core’s API exactly, and yours not at all. Check the URL, the headers and the body shape against your own documentation.
Sync providers default to fail_mode: 'open' so a broken extension never blocks a sale. Switch to closed only for a genuine compliance stop, and understand that it will reject orders when the extension is down.
Then run the test plan before enabling. A test run executes the extension once with sample input and shows you the real result — including the actual request your endpoint received.

​
Boundaries

  • It references only what is deployed. Endpoints, events and fields come from the indexed API surface; anything outside it is a question back to you, not an approximation.
  • It never writes a credential. Secrets are referenced by alias and connected separately, so the extension source never contains one.
  • It never enables anything. A build is a draft. Nothing executes until you review it, connect its secrets, and turn it on.

​
Keeping it current

The Builder’s grounding is re-indexed whenever the API surface changes, so a newly-added endpoint or event becomes available to it. If it seems unaware of something recent, the index is the thing to refresh — the model itself has no memory of your store between builds.
Each build sees only your prompt and the grounded API surface. It does not see your catalogue, customers, orders, or previous builds.

​
The other builder

The same describe-it-and-get-it-built idea appears once more in Galactic Core, aimed at a different job. The ad campaign builder takes a plain-language brief — what to advertise, and what the campaign is for — and produces a complete campaign: structure, keywords, audiences, budgets, and ad copy, grounded in the store’s own catalogue and margins rather than generic suggestions. Where this page’s Builder writes an integration you review and deploy, that one drafts advertising a merchant reviews and publishes. It is documented with Advertising.

​
Next

Extensions

The contracts, execution modes, and safety guarantees behind what the Builder generates.

Bring your own compute

Running extension code on your own infrastructure.

Advertising

The ad campaign builder, and the automation rules that keep spend on profitable stock.

Agentic commerce

The in-app assistant that prepares gift cards, promotions, and pricing rules for approval.