Pre-launch API. The concepts described here are settled, but the API shape is not: request and response fields, parameters and defaults can still change. Build against it, and talk to your Luigi's Box contact before you put an integration into production.
Distribution
Most of a discovery integration is storefront work: a search box, a results page with facets, recommendation strips, and the analytics wiring behind them. Distribution covers that side. Luigi’s Box hosts a git repository for your integration, pre-seeded with a working scaffold and a pack of skills written for coding agents. You clone it, tell your agent to integrate your site, review the result on a preview URL, and merge. The script your storefront loads is built and published from that repository.
This is the default path. Start here unless one of the cases below applies.
What you get
Section titled “What you get”| A repository | Hosted by Luigi’s Box, cloned and pushed with git and your Luigi’s Box credentials |
| A scaffold | Build tooling, the discovery library as a pinned submodule, and a place for your integration code |
| A skill pack | Procedures your coding agent reads and follows — /integrate runs the whole job |
| Branch previews | Every pushed branch is loadable on your real site behind a query parameter |
| A release path | A push to main builds, tests and republishes the script your site loads |
| A place to remember | A memory/ directory the agent keeps: measurements, catalog facts, decisions and why |
Why a repository rather than a snippet
Section titled “Why a repository rather than a snippet”An integration changes when your storefront’s markup changes, when you add a market, when a new surface goes live. A repository gives it:
- Reviewable changes — a diff, on a branch, with a preview URL.
- Controlled releases —
mainis the release branch, and merging to it is your decision. - Persistent context — the agent’s notes, decisions and reasons are in the repository, so the next session, yours or an agent’s, starts from them.
How it fits with the rest
Section titled “How it fits with the rest”Distribution owns the storefront half of the integration. Everything else in these docs still applies, and the repository is a consumer of it:
You still get your catalog in, you still need a channel and a publishable key, and the events the integration sends are the events documented under Analytics. The browser code is what the repository provides.
When to integrate by hand instead
Section titled “When to integrate by hand instead”Distribution is the default, not the only way. Call the API directly when:
- Your storefront renders results server-side. A backend that queries discovery and renders HTML has no place for a browser script — see Backend quickstart.
- You have a frontend framework and a component library you intend to use. If discovery results are rendered by your own components, call the API directly — see Browser quickstart.
- You are integrating something that is not a website. A mobile app, a kiosk, an internal tool.
These are not exclusive. A common shape is a distribution repository for the storefront and a backend integration for indexing and configuration.
| Your first integration | Create a repository and put an agent to work in it |
| Previews and releases | Branches, preview URLs, and what a push to main does |
| Repositories API | Creating, listing and deleting repositories |
See also
Section titled “See also”- Start here — the integration as a whole
- Authentication — the credentials the repository and your site need
Was this page helpful?
Thanks.