How a distributed integration fits together

--- title: Distribution description: The managed integration repository Luigi's Box gives you — a working scaffold, a skill pack your coding agent reads, branch previews, and a released loader script. slug: distribution/overview docKind: concept hub: luigisbox-ai --- 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. :::hub[Config → Front-end Integration]{path="/frontend-integration"} Creating the repository and getting its clone URL needs no API call — everything after that is git and your agent. ::: This is the default path. Start here unless one of the cases below applies. ## 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 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** — `main` is 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 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](/indexing/feeds/), you still need a [channel and a publishable key](/authentication/browser-tokens/), and the events the integration sends are the events documented under [Analytics](/analytics/overview/). The browser code is what the repository provides. ## 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](/start-here/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](/start-here/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. ## Next | | | |---|---| | [Your first integration](/distribution/quickstart/) | Create a repository and put an agent to work in it | | [Previews and releases](/distribution/previews-and-releases/) | Branches, preview URLs, and what a push to `main` does | | [Repositories API](/distribution/repositories-api/) | Creating, listing and deleting repositories | ## See also - [Start here](/start-here/overview/) — the integration as a whole - [Authentication](/authentication/overview/) — the credentials the repository and your site need