Skip to main content
A release freezes the current state of your project’s main stream into a version that never changes. Production always runs the latest release, never the version you are editing. This applies to the REST API, MCP, and the n8n HTTP and MCP Agent workflows. You can keep editing, testing, and reviewing changes without affecting anyone who calls your project. Your changes reach production only when you create the next release.
A project without a release has no working endpoints. Calls to the REST API or MCP are rejected until you create the first release. If you built a project and never released it, create a release before you connect it.

​
Public and private Blueprints

Every Blueprint in a project is either public or private: A project can have several public Blueprints, so one project can offer several entry points. It needs at least one. The Contents sidebar groups your Blueprints under Public and Private: The Contents sidebar of the Loan Application Scorecard project — Loan Application Scorecard and Quick Affordability Check listed under Public, Calculate Score under Private To change a Blueprint’s visibility, do one of the following:
  • Drag the Blueprint from one group to the other.
  • In the Specification view, open the ⋮ menu on the Blueprint’s heading and choose Make public or Make private.
Visibility is part of the release. After you make a Blueprint public, create a new release so callers can reach it. Calling a Blueprint that is private in the latest release returns an error that asks you to make it public and release again.

​
Create a release

You create releases from the main stream. If you are working on a draft, apply it to main first. See Change Workflow.
  1. Click Release in the top toolbar of the Blueprint Editor.
  2. Enter a Version name, for example v1.0. The name must be unique within the project.
  3. Optionally, add a Description of what changed in this version.
  4. Click Create release.
The Create release dialog for main v8 with the version name v1.0 and a short description filled in Leapter packages the project and confirms with Release created. The confirmation shows the version name, a Content ID that identifies exactly this content, and where the release came from — the stream version and the number of Blueprints. The Release created confirmation: v1.0 is ready, with its Content ID and the source main v8 with 3 blueprints You can also release from the Timeline: open a change on main and choose Create release to release the project as it was at that change.
The Options section in the release dialog is for validation rule libraries. Leave it unchanged for a normal release.

​
What the Release button tells you

The Release button shows whether production is up to date: The top toolbar after a release — the view switcher, the Release button showing Released v1.0, and the Share button If you try to release content that is already released, Leapter shows Already released and does not create a new release. Change something in the project first.

​
Which version runs where

Every production run records the release it ran on. You can filter by release in Insights. A release never changes once it is created. To change what runs in production, edit the project and create a new release.

​
View and download releases

All releases of a project are listed in Insights → Releases. Each entry shows the version name and description, its Content ID, who created it and when, the project version it was created from, and the number of Blueprints. Click Download to save the release package. Insights with the Releases section open — release v1.0 marked Latest, with its description, Content ID, project v8, 3 blueprints, and the Download button See Insights for details.

​
What to do next

  • Web API (OpenAPI) — call the public Blueprints of your latest release from any application
  • AI Protocol (MCP) — let AI assistants use your public Blueprints as tools
  • Insights — monitor how your release runs in production