Build your first app on Createrun.

1. Install and sign in

The Setup installer comes as a single-file command-line tool and as a desktop wizard; download Setup from the Createrun Store (store.createrun.ai/instance/download) and follow the install guide on that page. Once the instance is running, sign in to the browser-based Editor with your account from the built-in identity provider (IDM) and create a workspace bound to that instance. Every artifact you design (a form, a query, a workflow, or a BPM flow) compiles into strongly typed assemblies on save.

You build apps from three kinds of artifact, and the runtime exposes their actions over HTTP as gate methods:

2. Your first app: a contact form

1. Create a solution and module. In the Editor, choose New → Solution and name it HelloContacts. Add a module named Contacts.
2. Create a form. Choose New → Form and name it ContactForm. Add a required Name text field, an Email field with email validation, and a Submit button part.
3. Bind the form to storage. Open the form's data binding panel and bind a table or stored procedure. The framework generates the typed model and the persistence calls.
4. Wire the submit action. Set the button action to Insert, or call a workflow (§3).
5. Compile. Save the form; the Compiler pipeline produces the app assemblies. Failures surface as Roslyn diagnostics mapped to COMPILER_SYNTAX or COMPILER_SEMANTIC.
6. Run it. Deploy to your instance and open it through CRPortal or the virtual site gate.

Editor tip: to remove a field, select it and use the ribbon command Selected → Remove. The neighboring command Remove Completely deletes the whole form.

3. Queries and workflows

A query is parameterized SQL. Choose New → Query, name it ContactsByEmail, enter the body SELECT Name, Email FROM Contacts WHERE Email = @email, declare the @email parameter, then bind the result to a grid or call it from a workflow. Compilation checks do not replace testing the query against its target database and representative data.

A workflow automates server-side logic. Add condition nodes and parallel tasks (an audit row and a notification, for example), then bind the workflow to the form's Submit action. A workflow can be promoted to a BPM flow for long-running work with human approvals. State-preserving workflows can be designed to resume after interruption; external transactional effects still require process-specific handling.

4. Publishing to the Createrun Store

The workflow below describes the publisher path: package, signature, review and publication. You can publish free apps under your own publisher profile. Confirm a supported package version before trying this part of the guide.

1. In the Editor, publish the solution to the Createrun Store. The platform collects your sources and manifest, generates a checksum map, and streams a signed .crpck package (ECDSA P-256) to the Createrun Store API.
2. The Createrun Store validates your IDM JWT, stores the package, re-signs the manifest, and sets the version status to submitted.
3. The Createrun Store reviews the submission; on approval the status moves submitted → approved → published and you receive an email.
4. Customers install your published app from the Createrun Store inside their own console; the install pipeline verifies the license JWT and the package signature.

Common publish failures map to documented codes: STORE_VERSION_CONFLICT (bump the version), STORE_CHECKSUM_MISMATCH (rebuild the package), and STORE_SIGNATURE_INVALID (signing key mismatch). See the error-code reference. A failed install keeps a step-by-step trace that your Createrun Store administrator can inspect; file a ticket from the Support page in the console and include the trace id.

5. The gate HTTP contract

Apps expose actions as gate methods over HTTP. The runtime routes a request to a gate method by name.

• URL shape: /gate/{app}/gatemethods.{group}.{method} (lowercase), for example /gate/crportal/gatemethods.integration.installapp.
• Envelope: JSON, wrapped in the standard Response<T> envelope, whose fields are a code, an optional data payload, and an errors[] array on failure.
• Encoding: UTF-8 request and response bodies.
• Auth: an instance or developer JWT Bearer token issued by the built-in identity provider (IDM) over OpenID Connect. A small number of gate methods are deliberately anonymous; every other one requires a token.
• Error mapping: every non-success response carries a registry code; resolve it with GET /api/v1/error-codes/{code} or on the reference page.

The error-code endpoints below are the only REST endpoints documented on this page. They are public and need no token.

6. Getting help

Error codes: the reference page or GET /api/v1/error-codes (public, no auth). Support: file a ticket from the Support page in the console and attach the install trace id when reporting a failed install. Developer tooling overview: the Developer Hub.