Pages
What are Pages?
A page is a route or entry point in a mobile app that links a slug (URL path) to an optional asset (HTML). The mobile app fetches pages to build navigation (e.g. menus) and to load a specific page by slug, including its linked asset.
Pages are used for:
- In-app navigation – List of pages to build menus or navigation
- Deep linking – Slugs map to routes (e.g.
com.app://page/about-us) - Asset display – A page can link to an asset (HTML) that the app renders when that page is opened
Core Properties
| Property | Description |
|---|---|
| id | Unique identifier (Firebase push key) |
| name | Display title (internal reference) |
| slug | URL path identifier (e.g. about-us, shop) – must be unique |
| contentId | Optional – ID of linked asset (HTML) to display |
| published | Whether the page is live |
| archived | Soft-archive flag |
| deleted | Soft-delete flag |
Relationship to Assets
- An asset is HTML stored in the Visual Experience Engine (via the Assets feature).
- A page can optionally link to one asset via
contentId. - When the mobile app fetches a page by slug, the API returns:
- Page metadata (id, name, slug, contentId)
- The linked asset (id, name, slug, code, status) if
contentIdis set and the asset is published
- The app can then render the HTML on that page.
API: Fetching Pages
Get All Pages
GET /remote-pages?key=YOUR_API_KEY
Returns a list of published, non-deleted, non-archived pages, sorted by creation date (menu order).
Response:
{
"data": [
{
"id": "abc123",
"name": "About Us",
"slug": "about-us",
"contentId": "xyz789",
"createdAt": 1700000000000,
"updatedAt": 1700000000000
}
]
}
Get a Single Page (by slug)
GET /remote-pages?key=YOUR_API_KEY&slug=about-us
Or use the singular endpoint:
GET /remote-page?key=YOUR_API_KEY&slug=about-us
Response (with linked asset):
{
"id": "abc123",
"name": "About Us",
"slug": "about-us",
"contentId": "xyz789",
"createdAt": 1700000000000,
"updatedAt": 1700000000000,
"content": {
"id": "xyz789",
"name": "About Us Content",
"slug": "about-content",
"code": "<div>...</div>",
"status": "published"
}
}
Visibility Rules
A page is returned by the API only when:
- published –
published === true - Not deleted –
deleted === false - Not archived –
archived === false
If a page has a linked asset, that asset must also be published and (if scheduled) within its schedule dates.
How the Mobile App Uses Pages
- Navigation / menu – Fetch all pages and use them to build a menu or navigation list.
- Deep link – Use the slug in deep links (e.g.
com.app://page/about-us) to open a specific page. - Asset rendering – When opening a page, request it by slug; if it has
content, render the HTML.
Pages vs. Other Concepts
| Concept | Purpose | Platform |
|---|---|---|
| Pages | Routes + optional asset; in-app navigation | Mobile app |
| Assets | Reusable HTML blocks | Both (fetched directly or via Page) |
| Specifications | Versioned JSON config for layout | Mobile app |
| Scheduled Content | Scheduled promotional content | Both |
Workflow Summary
- Create an asset in the Assets section (HTML).
- Create a Page in the Pages section: set title, slug, and link to an asset.
- Publish the page (and the linked asset).
- The mobile app fetches pages to build navigation.
- When the user opens a page (e.g. via menu or deep link), the app fetches it by slug.
- The app renders the linked asset HTML when present.
Key Takeaway
A page is a route/entry point identified by a slug. It can optionally link to an asset (HTML). The mobile app uses pages for navigation and for loading and displaying linked assets when a page is opened.