Pro App Pages

Add extra URL paths and public pages to Pro apps

Every Operator App has a Home page served by index.html at the root path /. Pro apps can define additional pages, each with its own URL path and access mode.

When to create a page

A Page is a distinct navigable destination in the application. Do not create a new Page merely because the UI shows different content.

Create a new Page when one or more of these apply:

The user explicitly asks for a page, URL, route, or independently accessible destination.
The destination should have its own stable/deep-linkable URL.
It has a different Page Access Mode.
It is a major top-level or hierarchical navigation destination, such as /pricing, /docs, or /account/orders.
It should be independently refreshable/bookmarkable and browser Back/Forward navigation should naturally move between it and other pages.
It needs page-specific browser metadata or hosting behavior, such as title, SEO, Open Graph metadata, or public indexing.

Do not create a new Page merely for:

dialogs, popovers, drawers, or modal editors;
tabs within the same logical destination;
filters, sorting, pagination, or selected records;
expandable sections;
wizard steps that belong to one continuous operation;
alternate views of the same workspace where a separate URL is not useful;
temporary UI state.

When uncertain, prefer keeping related functionality within the existing Page. Create another Page only when it represents a meaningful independent destination.

Why use pages?

Separate URLs for distinct screens — for example /dashboard, /settings, or /report.
Public landing pages — share a form or a dashboard with people who do not have an Operator account.
ERP.net internal pages — screens that only make sense when the visitor is connected to an ERP.net instance as an internal user.

How pages work

Pages are managed under Cloud → Pages in the App Builder workspace.

Each page is represented by a source file at pages/<page-name>/index.html.
The page's CSS and JavaScript files live in the same folder — the folder-per-page rule is strict.
Sub-pages are nested folders: pages/parent/child/index.html is served at /parent/child.
The path shown to users and the file path must match. If you move or rename a page, update both the folder and the page record.
Home is always index.html at /. Do not create a page record for it and do not delete it.
Links between pages can carry details after a ?. Example: a shop catalog links each product to product?id=…, and the product page reads the id to show the right item. The details are kept when the visitor clicks the link.

App access mode (the Home page)

The app itself has an access mode that controls who can open the Home page — and it is the default access mode for every new page you create. You set it when the app is created, and you can change it later under Cloud → Pages (the Home row).

Defaults for new apps:

ERP.net Internal User when an ERP.net instance is connected — the typical case for an "ERP data app".
Operator User when no instance is connected — the app still requires sign-in.

Choose Public only when people without an account genuinely need to open the app — for example a landing page, a public form, or a shareable dashboard. Public mode requires a Pro app. When the Home page is public, the app's address is https://app.operator.net/p/<app-slug> and the app is listed to crawlers accordingly.

The address to share. A public-home app has no instance in its address. Share https://app.operator.net/p/<app-slug> (add /<page-path> for a sub-page); you will also find it under Cloud → Pages and in the Deploy tab, and the maximize button in the app header opens it. If someone opens the signed-in style address /a/<app-slug>/<something>, the trailing part is read as a page path and served publicly — no login prompt. Access is always decided per page: a public page opens for everyone, while a page that requires an Operator or ERP.net user still asks for sign-in, even in the same app.

A public Home page also makes the app's public backend requests callable without sign-in — mark only the requests that are safe to expose as Public.

Access modes

Mode	Who can open it	Typical use
Public	Anyone with the URL; no sign-in required	Landing pages, public forms, shareable dashboards
Operator User	Signed-in Operator users	Internal tools and team screens
ERP.net Internal User	Signed-in Operator users with an active ERP.net internal connection	Screens that call ERP.net data directly

Public pages are Pro-only. They are served from /p/<app-slug>/<page-path>. A page with no explicit access mode inherits the app's access mode.

Public backend requests

A public page has no signed-in visitor, so it cannot use your ERP.net connection, the app's tables, stored files or secret values. Anything it shows from a server must go through an app web request marked Public.

A public request runs on the server with its own stored credentials, so it can read ERP.net data (via a service login) or any external API without the visitor signing in. The App Builder creates and marks these requests for you — you only enter the credential values under Secrets.

Building pages

Describe the new page to the App Builder in chat. For example:

"Add a public landing page at /register with a simple contact form."

The App Builder will:

Create the page record under Cloud → Pages.
Write the source files under pages/register/.
Update any navigation in the app so users can reach the new page.

Use the Design tab to preview the page, and Code to inspect or edit the generated source.