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 Integrations → 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, and a build you discard has already spent them. You can also reach it through the in-app assistant, which asks what it needs before building rather than taking the whole integration as one description. That route suits a request you have not fully worked out — the assistant can ask which provider you use, what should happen when the integration fails, and refine the result after you have seen it. The assistant can also check its own work. It runs what it wrote once, reads the result — status, duration, the error, and the log lines the code produced — and, when the run fails, rewrites and runs it again rather than handing back something that has never executed. What it wrote is stored switched off throughout, so it runs only when you test it or after you enable it.
A test runs in your store’s real runtime with your connected credentials, so an integration that reaches an external service genuinely reaches it — a message really is sent, a record really is created. The assistant says so when a test has an outside effect.

​
Looking up current documentation

A build can consult the live documentation of the provider you name before writing anything. This is on by default, because an integration written from a stale memory of an API is wrong in a way that is hard to see by reading it — the code looks reasonable and fails on the first call. It costs a little more and takes longer, and you can turn it off for an integration against an API that has not changed.

​
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. Where the description leaves one of them open, it asks a follow-up question instead of choosing.
The first names the event, the condition, the destination, the auth style, and the payload, and builds in one pass. The second matches a dozen different extensions, so the Builder asks rather than guesses. Three details the Builder cannot infer from the store itself:
  • 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

notes explains what the extension does and flags anything unfinished. Four further things decide whether a draft is ready to enable.
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.
The Builder’s grounding covers Galactic Core’s API and not your system’s, so the URL, headers and body shape here come from your description rather than from an indexed contract. They are worth reading 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, which is how an added endpoint or event becomes available to it. The index is the only thing carrying that knowledge — the model itself retains nothing about your store between builds — so an endpoint the Builder does not recognise is one the index has yet to pick up.
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

Galactic Core has a second builder, 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, drawn from the store’s own catalogue and margins. It shares this builder’s live-documentation lookup, checking the ad platform’s current guidance before it writes. Its output is advertising a merchant reviews and publishes, rather than an integration you review and deploy. It is documented with Advertising. Both are also reachable through the in-app assistant, which additionally sets up experiments comparing versions of a campaign and reports which is winning.

​
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.