# Backend as a service The modular backend-as-a-service platform eliminates the need to build and manage the application backend [Norbix](https://norbix.ai) is a vital toolset for each developer who wants to achieve daily development tasks rapidly. Norbix provides many common backend services for you so you can focus on your front end. Services such as database, email and push notifications, authentication, file storage, and many others are already implemented and can be easily accessed through the Norbix dashboard or API. ## Getting Started Welcome to Norbix! Getting started is simple and free. ### **Step 1: Create Your Free Account** Go to [norbix.ai](https://norbix.ai/) and sign up—no payment or credit card required. Your account gives you instant access to the Norbix dashboard and unlocks all the platform’s possibilities. ### **Step 2: Choose How You Want to Use Norbix** Once you’re signed in, you have three flexible paths to build and scale your project: **Cloud** Start your project instantly in our managed cloud environment with a 30-day free trial. No setup or infrastructure needed—just create a project and begin. **Self-Hosted** Prefer to run Norbix on your own infrastructure? You can generate a license from your dashboard and follow our guides to deploy Norbix wherever you want. **Enterprise** For advanced, large-scale, or custom needs, choose our Enterprise solution. Contact us for a tailored onboarding and deployment experience.
PlanWho is it for?Key Benefits
CloudAnyone who wants a quick start and zero DevOps hassle
  • Instant setup & 30-day free trial
  • Fully managed & scalable
  • No infrastructure worries
Self-HostedHackers, indie makers, small entrepreneurs, tech enthusiasts
  • Deploy on your own servers
  • Full control & flexibility
  • Try Norbix for free locally
EnterpriseLarge companies & organizations with custom needs
  • Custom deployment & scaling
  • Advanced security & compliance
  • Full data control
**What’s next?** \ After you sign up and decide which option fits you best, you’ll find step-by-step guides and resources in the dashboard to help you launch your project—whether in the Cloud, Self-Hosted, or Enterprise environment. Ready to build? [Sign up for free at norbix.ai](https://norbix.ai/) ## Installation Getting started with Norbix is fast and flexible. After you create your free account, you can immediately launch a Cloud project by clicking the **“+ Add New Project”** button in your dashboard—no installation required.If you prefer to deploy Norbix on your own infrastructure or need a custom enterprise setup, see the installation options below. {% hint style="warning" %} **Note:**\ All installation scripts are dynamically generated in your [cloud.norbix.ai dashboard](https://cloud.norbix.ai/). Simply choose your license (Self-Hosted or Enterprise), select your preferred deployment method, and your personalized script will be ready for you. {% endhint %} ### Self-Hosted Installation Options
Deployment OptionDescription
KamalAutomated Docker-based deployment using Kamal.
Docker ComposeQuick and easy local/server deployment using Docker Compose.
TerraformInfrastructure-as-code deployment for any cloud provider.
AWS CDKAWS-native deployment using AWS Cloud Development Kit.
### Enterprise Installation Options
Deployment OptionDescription
Helm ChartsAdvanced Kubernetes deployments with Helm for large-scale needs.
TerraformAutomated, infrastructure-as-code deployment.
AWS CDKDeep AWS integration with Cloud Development Kit.
Kubernetes ManifestsCustom YAML for highly controlled, compliant environments.
Azure, Google Cloud, etc.Support for major cloud platforms—contact us for details.
Custom/AssistedTailored deployments with Norbix support & onboarding.
## Let's build your backend The following are the services provided by Norbix:
Membership - Manage users authentication and authorization, roles and permissionssecurity-300x184.pngMembership
Create a database with No Code and get instant dynamic API over it.database-Converted-1-300x252.pngDatabase
Store files for your project, optimize for separate screens and automatically bind files with the records from the databasefile-service-249x300.pngFiles
Serverless code for your project. Write code in any language you have experience with or choose from dozens of pre-written built-in functions.code3-300x263.png
Send personal or bulk push notifications to your clients. Schedule them, plan to send by client time zone, and have different languages over each message you deliver.notifications-300x296.pngPush
Send personal or bulk emails to your clients. Schedule them, plan to send by client time zone, and have different languages over each message you deliver.email-marketing-2-1-300x217.pngEmail
Web Standard with better HTTP fidelity than WebSockets. Receive push notifications from Norbix Servers
Seamless payments integration. Choose any provider you like itpricing-300x228.pngPayments
Schedule your code functions by time, timezone, and frequency you want to run it.tasks-300x273.pngScheduler
Grasp at what's happening on your project. Have tracing and application logs in one place.analytics-300x269.pngLogs & Monitoring
## AI Norbix is an **MCP-native backend**. Connect Claude Code, Cursor, Windsurf, or any MCP-compatible agent and let it scaffold schemas, configure providers, and deploy modules — against a backend that already enforces security and structure. The agents you ship call the same backend through MCP, SDKs, or REST. * [Norbix + AI](/ai/ai) * [MCP Server](/ai/mcp-server) * [Connect Your AI Tool](/ai/connect-your-ai-tool) ## SDK You can manage all the resources using [API](/api-reference/get-started). Even if the API is all you need, we know how convenient it is to have an SDK over the programming language you are working with. Please check out the languages we support: * [JavaScript / TypeScript](https://github.com/Isidos-co/codemash-docs/tree/main/sdk/javascript-typescript.md) * [.NET](https://github.com/Isidos-co/codemash-docs/tree/main/sdk/net.md) * [Go Lang](https://github.com/Isidos-co/codemash-docs/tree/main/sdk/go-lang.md) * [Flutter](https://github.com/Isidos-co/codemash-docs/tree/main/sdk/flutter.md) * [Swift](https://github.com/Isidos-co/codemash-docs/tree/main/sdk/swift.md) * [Kotlin](https://github.com/Isidos-co/codemash-docs/tree/main/sdk/kotlin.md) * [Python](https://github.com/Isidos-co/codemash-docs/tree/main/sdk/python.md) * [React / Redux](https://github.com/Isidos-co/codemash-docs/tree/main/sdk/react-redux.md) ## API [API section](/api-reference/get-started) describes all the details about Norbix - API Gateway and Hub (tools to manage Norbix projects from a developer perspective). We put comprehensive documentation on each topic to allow you to understand and use Norbix at a higher level. Each section references any SDK language we support, so you can easily link explanations with your beloved programming language. ## Other topics [Other topics](/other-topics/apple) explain miscellaneous topics that are common across several modules. # Roadmap Our product roadmap is where you can learn about what features we're working on, what stage they're in, and when we expect to bring them to you. ### Guide to the roadmap Every item on the roadmap is an issue, with a label that indicates each of the following: * A **release phase** that describes the next expected phase of the roadmap item. See below for a guide to release phases. * A **feature area** indicates the product area to which the item belongs. For a list of current product areas, see below. * A **feature** that indicates the feature or product to which the item belongs. For a list of current features, see below. ### Release phases * **alpha:** *Primarily for testing and feedback*\ Limited availability, requires a pre-release agreement. Features are still under heavy development and are subject to change. Not for production use, and no documentation, SLAs, or support is provided. * **beta:** *Publicly available in a full or limited capacity*\ Features are mostly complete and documented. Timelines and requirements for GA are usually published. No SLAs or support is provided. * **ga:** *Generally available to all customers*\ Ready for production use with associated SLA and technical support obligations. Approximately 1-2 quarters from Beta. Some of our features may still be in the exploratory stages and have no timeframe. These are included in the roadmap only for early feedback. These are marked as follows: * **in design:**\ Feature in the discovery phase. We have decided to build this feature but are still figuring out *how*. * **exploring:**\ Feature under consideration. We are considering building this feature and gathering feedback on it. ### Feature Areas The following is a list of our current product areas: * **cloud:** Administrative features specific to Norbix Dashboard * **supervisor portal:** Administrative features specific to the Norbix owner. * **api:** REST API functionality * **sdk:** SDK development for client applications (Desktop, Mobile, Watch) * **devops**: Operations and Security * **learning:** Education and learning features * **insights:** Continuous learning and insights features * **client-apps:** Client applications (Desktop, Mobile) * **other:** Other features ### Feature The following is a list of our current features and products, with distinct labels for filtering: * **project:** Norbix project * **membership:** Norbix membership - Identity and Access Management * **database:** Norbix Database - Mongo database + JSON Schema * **files:** Norbix Files - It's an easy way to store and access files from any device, anywhere. * **code:** Norbix Code - Serverless functions. * **scheduler:** Norbix Scheduler - an easy way to perform application background processing in applications. * **logs:** Norbix Logs - Monitor logs, metrics, and request traces in one platform for full-stack visibility of your application. * **payments:** Norbix Payments - plug in your favorite payment provider into your app. * **emails:** Norbix Email is a cloud-based email sending service designed to help digital marketers and application developers send marketing, notification, and transactional emails. * **push:** Norbix Push Notifications - Push notifications are the top driver of app re-engagement and it's very easy to incorporate push notifications from well-known market leaders like OneSignal, CataPush and Amazon SNS. * **server-events** *More labels will be added in the future as needed.* ## 2023-05-01 ### v3 Norbix was designed to be the most powerful, flexible, and easy platform for you to build any web and mobile application. We built many web and mobile apps within the last four years using Norbix. We are a group of developers and tech-savvy folks making the platform easy from version to version. In the next version, we will focus on: * [ ] gRPC protocol support * [ ] database caching support * [ ] a new JSON field to store poor JSON as a field in the database. * [ ] bug fixes ### Community Edition (alpha) At Norbix, we believe in the power of community. We also believe that developers are at their most creative when they have time and space to hack their ideas into reality. That's why we want to start Norbix with the Community edition where you can install Norbix into your local machine. Using Docker compose file you can start the development environment and build your ideas. ### Enterprise Licence for AWS Cloud We have received a lot of requests from clients who want to use the Norbix stack in their AWS environments. We are super busy providing the capability to install Norbix into your AWS Cloud environment, so you can use your tools and incorporate Norbix stack into your daily routine. ## 2023-12-01 ### Code We will provide a new "Deploy" functionality for the Norbix Code module. You will be able to describe your app deployment in YAML format. The idea is to provide the capability to bootstrap your app into GitHub with all the necessary assets and allow you to customize it. ## 2024-01-30 ### Sms Norbix provides you with a simple and reliable messaging system built for apps. Our transactional **email** and **push** solutions effectively support developers and marketers alike. On top of the messaging service, we will be able to send messages using SMS services like Twilio. ## 2024-03-01 ### Translations We will provide a new module called "Translations" - localization features that simplify your work. You will get an environment where you can do translations, invite people to enroll as contributors, and export translations into favorable formats: i18n (lightweight, simple translation module with dynamic JSON storage), resx (XML-based files), and other popular formats. # Release Notes Review all Norbix releases in detail. Check out the entire release history for more info about new modules and functionalities. ## Versions Norbix is a large and complex system composed of many microservices, frontends, and deployment components. Some components are redeployed and versioned several times daily, while others are more related to some business meaning. We relate Norbix generations to how our API evolves. Many breaking changes when backward compatibility doesn't make sense lead us to the new version. The following table displays currently available API method versions. | v3 (alpha) | 2023-05-01 (expeted release date) | | ---------- | --------------------------------- | | v2 | 2020-05-18 | | v1 | 2019-10-21 | ## SSE - June 2021 In June 2021, we released a new module for Norbix called **Server-Sent Events (SSE)**. This module allows developers to quickly implement real-time updates in their web and mobile applications, making it ideal for applications that require live data, such as chat rooms, live sports updates, or stock tickers. SSE is a powerful web technology that allows a server to send data to a web page in real-time without the need for the web page to request it. It can be thought of as a mix between long polling and one-way WebSockets and contains many benefits over each. This makes it easy for developers to create engaging and interactive user experiences. ### Added * Server-Sent events module ### Changed * we have made many improvements across the board, including enhancements to the user interface, new and updated SDKs, and numerous bug fixes. ## V2 - May 2020 In May 2020, we released a major update to Norbix, improving our API from version 1 to version 2. This update included several new features and enhancements, including the addition of a payments module that allows developers to integrate their apps with popular payment gateways like Stripe, Apple Pay, Google Pay, and more. ### Added * Added support for Apple Pay, Google Pay, Stripe, Decta, Paysera, Kevin * Added plans, discount, and orders module for managing subscriptions, promotions, and purchases ### Changed * Improved the scheduler module to support scheduling jobs based on user timezones * Many other enhancements and bug fixes for improved performance and stability ## V1 - October 2019 In 2019, Norbix had its first significant release, V1. We added support for multiple modules because our customers were building complex apps that required more and more integrations. We wanted to create a seamless environment where all of these connections could be managed easily in one place. This release was a major milestone for Norbix and marked the beginning of our journey toward becoming a leading web developer provider of tools and services. By supporting multiple modules and providing robust integrations, we were able to serve our customers better and help them build the apps they needed to succeed. Overall, the release of Norbix in 2019 was an essential step in the evolution of our company, and it set us on the path toward becoming a trusted and respected provider of web development tools and services. ### Added * Added support for MongoDB and NoSQL technology * Using JSON Schema, we created a new way to manifest database schema for both data structure and relations, and UI * Added support for triggers on insert, update, and delete actions in the database service * Implemented the ability to use event data from triggers to call serverless actions * Implemented email service to send transactional emails * Implemented push notifications service to send transactional push notifications * Implemented file service with support for AWS S3 file storage ## MVP - May 2015 As the founder of Norbix, I had more than a decade of software development experience and several years of experience working with MongoDB. I was always looking for ways to use it more effectively. In May 2015, I wrote a [blog post](https://domantasjovaisas.wordpress.com/2015/05/20/jsonform/) about how to use the JSON standard to create dynamic forms. At the time, creating dynamic forms with relational databases was difficult. Still, I believed that by combining MongoDB with JSON Schema, I could create a dynamic API that would be easy to work with and highly flexible. I bought a domain name called jsonform.com, and we created the GitHub repo "formschema." Eventually, we saw that it's not only about dynamic form rendering but more about backend services that can serve mobile, web apps, IoT, and wearable apps. Then Norbix was born. ## Initial commit - October 2013 ... or building POC(Proof of concept)

Initial commit

Work in progress

# Managed Service Norbix managed service Every day we face new challenges, and our Norbix Managed Service helps us cope with them. This service is the right decision for you if you want to focus on your business and don't have time to deal with hosting issues, planning security, or deploying software updates. There’s no need to bother yourself with deployments, hosting, security, scaling, and other infrastructure issues. **Once you’re ready to launch your application into production, Norbix offers a production-ready environment where growth and scale are needed.** Please follow [this instruction](/norbix-cloud/cloud) to create the Norbix account. **Ready for:** * [x] No operational hustle * [x] Production-ready * [x] Scalability and security in place * [x] Start realizing ideas quickly #### There are several ways to interact with Norbix and use its services. ## Norbix Cloud First, users can connect to the Norbix management console [Norbix Cloud](/norbix-cloud/cloud) using a web browser. From the management console, users can create projects, connect to third-party tools and services, and manage the backend for their app without writing any code. This is a user-friendly and intuitive way to start with Norbix and take advantage of its services. ## SDKs Another way to interact with Norbix is to use its [SDKs](https://app.gitbook.com/s/-LwSkuCpTNI_AerL8J2a/sdk) or restful API. Norbix provides SDKs in various languages, including TypeScript, .NET, and Go Lang. These SDKs make it easy to call the Norbix services, such as the database, notifications service, file service, and many more, from within an app. This allows developers to easily integrate Norbix into their app and take advantage of its services. ## Norbix CLI Finally, users can interact with Norbix using the [Norbix CLI](https://app.gitbook.com/s/-LwSkuCpTNI_AerL8J2a/cli). This command-line tool allows users to automate the creation of projects, manage DevOps tasks, and call the Norbix API. This is a powerful and flexible way to work with Norbix and streamline the development process. Overall, there are several ways to interact with Norbix and take advantage of its services. (Please note that Norbix is currently in development mode, and some features may not be available yet.)
# AWS-CDK Deploy Norbix to the AWS using AWS CDK. {% hint style="info" %} The following samples are intended for use in **production** **environments** such as having complete control over operations, integrating the Norbix stack within a company structure, tools and policy, developing internal tools, etc. Installing Norbix in any cloud system requires Enterprise Licence. Please refer to our [pricing page](https://norbix.ai/pricing/) for more details. {% endhint %} {% hint style="info" %} You are here, so that means a lot to us. We track what's interesting for developers and Norbix users, so we can prioritize our upcoming activities and bring you joy shortly. This topic is here because we are already working on this. Please check out the [Roadmap](/roadmap) and get more insights when it will be ready. {% endhint %} Currently, we are in the **alpha** phase. Please refer to the [Roadmap](https://docs.norbix.ai/roadmap#release-phases) "Release phases" section for more information. # Azure Deploy Norbix to the Microsoft Azure. {% hint style="info" %} The following samples are intended for use in **production** **environments** such as having complete control over operations, integrating the Norbix stack within a company structure, tools and policy, developing internal tools, etc. Installing Norbix in any cloud system requires Enterprise Licence. Please refer to our [pricing page](https://norbix.ai/pricing/) for more details. {% endhint %} {% hint style="info" %} You are here, so that means a lot to us. We track what's interesting for developers and Norbix users, so we can prioritize our upcoming activities and bring you joy shortly. This topic is here because we are already working on this. Please check out the [Roadmap](/roadmap) and get more insights when it will be ready. {% endhint %} Currently, we are in the "**exploring"** phase. Please refer to the [Roadmap](https://docs.norbix.ai/roadmap#release-phases) "Release phases" section for more information. # Docker Install Norbix using Docker Compose. At Norbix, we believe in the power of community. We also believe that developers are most creative when they have time and space to hack their ideas into reality. We want to start Norbix with the Community edition, where you can install Norbix on your local machine. Using Docker compose file, you can start the development environment and build your ideas. One way that Docker can be used is in the "Indie Hacker" plan. The Indie Hacker plan is designed for personal, internal company, or subsidiary use. It allows developers to try out Norbix and see how it can help them create and manage the backend for their apps. However, the Indie Hacker plan has some restrictions, such as that any derivatives achieved by using Norbix cannot be provided, delivered, or sold to third parties as a service. This means developers who use the Indie Hacker plan cannot use Norbix to create a service or product sold or provided to others. Overall, the Indie Hacker plan is a good way for developers to try out Norbix and see how it can help them create and manage the backend for their apps. It is an excellent way to start with Norbix and see how it can benefit your development efforts. {% hint style="danger" %} The following samples are intended for use in **local development environments,** such as tinkering with the Norbix stack, having small and internal projects, etc. These samples **must not be deployed in production environments.** {% endhint %} {% hint style="info" %} You are here, so that means a lot to us. We track what's interesting for developers and Norbix users, so we can prioritize our upcoming activities and bring you joy shortly. This topic is here because we are already working on this. Please check out the [Roadmap](/roadmap) and get more insights when it will be ready. {% endhint %} Currently, we are in the **alpha** phase. Please refer to the [Roadmap](https://docs.norbix.ai/roadmap#release-phases) "Release phases" section for more information. # GC Deploy Norbix to the Google GC. {% hint style="info" %} The following samples are intended for use in **production** **environments** such as having complete control over operations, integrating the Norbix stack within a company structure, tools and policy, developing internal tools, etc. Installing Norbix in any cloud system requires Enterprise Licence. Please refer to our [pricing page](https://norbix.ai/pricing/) for more details. {% endhint %} {% hint style="info" %} You are here, so that means a lot to us. We track what's interesting for developers and Norbix users, so we can prioritize our upcoming activities and bring you joy shortly. This topic is here because we are already working on this. Please check out the [Roadmap](/roadmap) and get more insights when it will be ready. {% endhint %} Currently, we are in the **exploring** phase. Please refer to the [Roadmap](https://docs.norbix.ai/roadmap#release-phases) "Release phases" section for more information. # Terraform Deploy Norbix to the AWS using Terraform. Terraform is a tool for building, changing, and versioning infrastructure safely and efficiently. The `terraform init` and `terraform apply` commands are two of the most commonly used commands in Terraform. ## Installation {% hint style="info" %} The following samples are intended for use in **production** **environments,** such as having complete control over operations, integrating the Norbix stack within a company structure, tools and policy, developing internal tools, etc. Installing Norbix in any cloud system requires **Enterprise Licence**. Please refer to our [pricing page](https://norbix.ai/pricing/) for more details. {% endhint %} To install and use Norbix, follow these steps: 1. Download the Norbix repository from GitHub by cloning the repository or downloading a zip file. 2. Open a terminal or command prompt, navigate to the folder where you downloaded the Norbix repository, and run the `terraform init` command to initialize the working directory. This will download and install any required plugins and verify the configuration files. 3. Run the `terraform apply` command to create and manage the infrastructure for your Norbix projects. This will apply the changes specified in the configuration files, creating or modifying resources as needed. Once these steps are complete, you can use Norbix to create and manage the backend for your app. For more information on how to use Norbix, see the documentation on GitHub.
# Overview Norbix Cloud — the admin dashboard, screen by screen. **Norbix Cloud** is the web dashboard where you manage everything in your Norbix backend — projects, users, data, files, messaging, payments, and automation. Everything you can do here is also available [from code](/sdks-and-cli/install) and through the [API](/api-reference/api-reference); the dashboard is the visual way to do the same work.

Sign in and you land on your account home.

This section walks the dashboard exactly as it is organized in the app: first the account level (your projects and team), then the project level — one chapter per module, one page per screen. On every page you will find a screenshot of the screen, what it is for, what you can do there, and links to do the same from the SDKs or the raw API. ## Modules behind feature flags The router also defines screens for **Marketing** (contacts, campaigns, metrics), **Contacts**, **Server events**, and **Translation**. These modules are feature-flagged and not visible in the standard module rail yet, so they are not documented here. They join this section when they ship. # Projects Your account home — every project you own. A **project** is the top-level container in Norbix. Everything else — modules, data, users, messages — lives inside a project. Your account home lists every project you own or collaborate on. The tabs at the top switch between **Projects**, **Team**, and **Current month costs**.

The account home. Tabs: Projects, Team, Current month costs.

## What you can do here Each project card shows the project name and a status badge: | Badge | Meaning | | ------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | | Region badge(s), e.g. `nb-eu-germany` | The project is active. One green badge per region — the primary region plus any additional regions. Self-hosted projects show no region badge. | | `PROVISIONING` | The project's database cluster is still being set up. The list refreshes itself until setup finishes. | | `SETUP FAILED` | Provisioning did not finish — the project needs attention. | | `NO DATABASE` | The project has no database yet. | | `DISABLED` | The project is switched off and rejects all operations. | The card footer carries module and team-member counters. Click a card to open the project's [General Info](/cloud/project) page. **Create a new PROJECT** opens the new-project screen; the counter next to it (e.g. `[1/1]`) shows your active projects against the cap your plan allows. The **Team** tab manages the people who can administer your account, and **Current month costs** shows your usage-based spend for the running month. ## Use it from code Create and manage projects with the SDKs — see [Account & Projects → Projects](/sdks-and-cli/account/projects). ## API reference Endpoints: [Account & Projects](/api-reference/account). # Project General Info — one card per module, with its integrations at a glance. When you open a project you land on **General Info** — the project's home page. The header shows the project icon, name, primary region badge, and description. The **Invite members** button on the top right opens the account **Team** page, where project access is managed.

Project → General Info. One card per enabled module, with its integration count and an Open module shortcut.

## What you can do here Every enabled module gets a card. Modules that connect to external providers (Membership, Database, Files, Code, Emails, Push, Payments, Logs) show their **Integrations** count and how many of those are active, e.g. `2` with `1 active`; modules without integrations simply show **Active**. Each card has an **Open module** shortcut to the module's main screen. Below, **Available modules** lists what is not enabled yet ("You have N modules left till your full power with Norbix"). **Enable** takes you into that module to switch it on. The action is locked while the project's database cluster is still provisioning — modules need a working database first. You only see the modules your role has permission for. The full set: Membership, Database, Files, Code, Emails, Push notifications, Payments, Scheduler, Logs. ## Use it from code Module toggles and project data are SDK methods — see [Account & Projects](/sdks-and-cli/account); every module also has its own `enable*` / `disable*` methods. ## API reference Endpoints: [Account & Projects](/api-reference/account). # Integrations Connect LLM providers and MCP servers to your project. This screen connects **AI integrations** to your project: LLM providers (OpenAI, Anthropic, Ollama, Groq, Google, Mistral, OpenRouter, Grok) and **MCP servers** (Model Context Protocol) — so AI agents and the built-in AI chat can work with your backend.

Project → Integrations. LLM providers and MCP servers connected to the project.

## What you can do here The screen has two tabs, each its own list: * [**LLM**](/cloud/project/integrations/llm) — columns: Integration Name, Provider, Default Model, Enabled, Default. The **Default** badge is per environment (e.g. "Default for PROD"); the backend assigns it to the first integration you create. When several integrations are active and none is the default, the list shows a warning. * [**MCP**](/cloud/project/integrations/mcp) — columns: Integration Name, Provider, Transport, Enabled. **Add New Integration** opens the provider gallery for the active tab. Clicking a row opens the integration's edit page, where you can also **enable, disable, test, or delete** it. Connection tests run automatically — the backend probes the provider and stores the result, so there is no manual confirmation step. Once an LLM integration is active, the project's AI features (like AI chat) can use that model. ## Use it from code See [AI Integrations](/sdks-and-cli/ai) in the SDK reference. ## API reference Endpoints: [AI Integrations](/api-reference/ai). # LLM providers Connect large-language-model providers for AI features. **Where:** Project → Integrations → LLM · `/projects//ai/llms/integrations` Connect an LLM provider so the project's AI features — chat, completions, agents — can use its models. {% hint style="info" %} Screenshot TODO — capture comes from testing-plan area **07-llm-integration**. {% endhint %} ## The list Columns: **Integration Name**, **Provider**, **Default Model**, **Enabled**, and a per-environment **Default** badge. The backend marks the first integration you create as that environment's default; there is no manual "set as default" action. If several integrations are active and none is the default, the list shows a warning. ## Add a provider **Add New Integration** opens the gallery (`…/pick`) with one card per provider: OpenAI, Anthropic, Ollama, Groq, Google, Mistral, OpenRouter, Grok. Pick one to open the form: | Field | What it does | | ---------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | | API Key | Required for every provider except Ollama (which has no key — you point at your own server instead). Stored encrypted and never returned by the API. | | Endpoint | Optional custom endpoint URL; empty uses the provider's default. For Ollama this is your server address, e.g. `http://localhost:11434`. Hidden for Google. | | Default Model | Optional — the model used when a request does not specify one, e.g. `gpt-4o-mini` or `claude-sonnet-4-6`. | | Integration Name | How the integration is listed, e.g. `My OpenAI Connection`. | Saving runs an automatic connection test (the backend sends a probe request to the provider); the last test result is shown on the edit page. Edit reopens the same form, where you can also **enable, disable, or delete** the integration. Per-provider details: [Providers](/cloud/project/integrations/llm/providers). ## API reference Endpoints: [AI](/api-reference/ai). # Providers All providers you can connect as Project → Integrations → LLM integrations. **Where:** Project → Integrations → LLM → Integrations → **Add** · `/projects//ai/llms/integrations/pick` Pick a provider below to see what it is for and what its configuration form asks. In the app the same catalog appears as a gallery on the pick screen; providers you already connected are marked. | Provider | What it is | | ------------------------------------------------------------------ | ----------------------------------------------------------------------------------------- | | [OpenAI](/cloud/project/integrations/llm/providers/openai) | Connect OpenAI to use GPT models for chat, completions, and embeddings. | | [Anthropic](/cloud/project/integrations/llm/providers/anthropic) | Connect Anthropic to use Claude models. | | [Ollama](/cloud/project/integrations/llm/providers/ollama) | Connect a self-hosted Ollama server to run open-source models on your own infrastructure. | | [Groq](/cloud/project/integrations/llm/providers/groq) | Connect Groq for ultra-low-latency inference of open-source models. | | [Google](/cloud/project/integrations/llm/providers/google) | Connect Google to use Gemini models. | | [Mistral](/cloud/project/integrations/llm/providers/mistral) | Connect Mistral AI to use Mistral models. | | [OpenRouter](/cloud/project/integrations/llm/providers/openrouter) | Connect OpenRouter to access many models from different vendors behind one API. | | [Grok](/cloud/project/integrations/llm/providers/grok) | Connect xAI to use Grok models. | ## API reference Endpoints: [AI](/api-reference/ai). # OpenAI Connect OpenAI as a Project → Integrations → LLM integration provider. **Where:** Project → Integrations → LLM → Integrations → **Add** → OpenAI · `/projects//ai/llms/integrations/new/openai` {% hint style="info" %} Screenshot TODO — capture comes from testing-plan area **01-integrations**. The description below is complete and verified against the app's provider-picker code. {% endhint %} Connect OpenAI to use GPT models for chat, completions, and embeddings. Requires an OpenAI API key. Create and edit use the same form; editing loads the saved values (secrets stay hidden). ## API reference Endpoints: [AI](/api-reference/ai). # Anthropic Connect Anthropic as a Project → Integrations → LLM integration provider. **Where:** Project → Integrations → LLM → Integrations → **Add** → Anthropic · `/projects//ai/llms/integrations/new/anthropic` {% hint style="info" %} Screenshot TODO — capture comes from testing-plan area **01-integrations**. The description below is complete and verified against the app's provider-picker code. {% endhint %} Connect Anthropic to use Claude models. Requires an Anthropic API key. Create and edit use the same form; editing loads the saved values (secrets stay hidden). ## API reference Endpoints: [AI](/api-reference/ai). # Ollama Connect Ollama as a Project → Integrations → LLM integration provider. **Where:** Project → Integrations → LLM → Integrations → **Add** → Ollama · `/projects//ai/llms/integrations/new/ollama` {% hint style="info" %} Screenshot TODO — capture comes from testing-plan area **01-integrations**. The description below is complete and verified against the app's provider-picker code. {% endhint %} Connect a self-hosted Ollama server to run open-source models on your own infrastructure. No API key required — just point at your Ollama endpoint. Create and edit use the same form; editing loads the saved values (secrets stay hidden). ## API reference Endpoints: [AI](/api-reference/ai). # Groq Connect Groq as a Project → Integrations → LLM integration provider. **Where:** Project → Integrations → LLM → Integrations → **Add** → Groq · `/projects//ai/llms/integrations/new/groq` {% hint style="info" %} Screenshot TODO — capture comes from testing-plan area **01-integrations**. The description below is complete and verified against the app's provider-picker code. {% endhint %} Connect Groq for ultra-low-latency inference of open-source models. Requires a Groq API key. Create and edit use the same form; editing loads the saved values (secrets stay hidden). ## API reference Endpoints: [AI](/api-reference/ai). # Google Connect Google as a Project → Integrations → LLM integration provider. **Where:** Project → Integrations → LLM → Integrations → **Add** → Google · `/projects//ai/llms/integrations/new/google` {% hint style="info" %} Screenshot TODO — capture comes from testing-plan area **01-integrations**. The description below is complete and verified against the app's provider-picker code. {% endhint %} Connect Google to use Gemini models. Requires a Google AI API key. Create and edit use the same form; editing loads the saved values (secrets stay hidden). ## API reference Endpoints: [AI](/api-reference/ai). # Mistral Connect Mistral as a Project → Integrations → LLM integration provider. **Where:** Project → Integrations → LLM → Integrations → **Add** → Mistral · `/projects//ai/llms/integrations/new/mistral` {% hint style="info" %} Screenshot TODO — capture comes from testing-plan area **01-integrations**. The description below is complete and verified against the app's provider-picker code. {% endhint %} Connect Mistral AI to use Mistral models. Requires a Mistral API key. Create and edit use the same form; editing loads the saved values (secrets stay hidden). ## API reference Endpoints: [AI](/api-reference/ai). # OpenRouter Connect OpenRouter as a Project → Integrations → LLM integration provider. **Where:** Project → Integrations → LLM → Integrations → **Add** → OpenRouter · `/projects//ai/llms/integrations/new/openrouter` {% hint style="info" %} Screenshot TODO — capture comes from testing-plan area **01-integrations**. The description below is complete and verified against the app's provider-picker code. {% endhint %} Connect OpenRouter to access many models from different vendors behind one API. Requires an OpenRouter API key. Create and edit use the same form; editing loads the saved values (secrets stay hidden). ## API reference Endpoints: [AI](/api-reference/ai). # Grok Connect Grok as a Project → Integrations → LLM integration provider. **Where:** Project → Integrations → LLM → Integrations → **Add** → Grok · `/projects//ai/llms/integrations/new/grok` {% hint style="info" %} Screenshot TODO — capture comes from testing-plan area **01-integrations**. The description below is complete and verified against the app's provider-picker code. {% endhint %} Connect xAI to use Grok models. Requires an xAI API key. Create and edit use the same form; editing loads the saved values (secrets stay hidden). ## API reference Endpoints: [AI](/api-reference/ai). # MCP servers Connect Model Context Protocol servers as AI tools. **Where:** Project → Integrations → MCP · `/projects//ai/mcps/integrations` Connect an MCP (Model Context Protocol) server so AI features can call its tools — search the web, automate browsers, query databases and more. {% hint style="info" %} Screenshot TODO — capture comes from testing-plan area **06-mcp**. {% endhint %} ## The list Columns: **Integration Name**, **Provider**, **Transport**, **Enabled**. Clicking a row opens the edit form, where you can also **enable, disable, or delete** the integration. ## Add a server **Add New Integration** opens the gallery (`…/pick`) with six providers: Brave Search, GitHub, MongoDB, Obsidian, Playwright, Stripe. The transport is fixed per provider and decides the form fields: | Transport | Providers | Fields | | ------------------------------- | ----------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Stdio (runs as a local process) | Playwright, MongoDB, Obsidian | **Command** (optional, defaults to `docker`) and **Arguments** (optional, one per line), plus a provider secret: a **Headless** toggle for Playwright, a required **Connection String** for MongoDB (e.g. `mongodb+srv://user:pass@cluster.mongodb.net`), and **Environment Variables** for Obsidian. | | HTTP stream | GitHub, Stripe, Brave Search | A required **Server URL** (e.g. `https://mcp.example.com/mcp`), plus the secret: **Access Token** for GitHub, **API Key** for Stripe and Brave Search. | Every form ends with an **Integration Name** (e.g. `My Stripe MCP Connection`). Secrets are stored encrypted and never returned by the API; on edit you must re-enter the secret, since saving rebuilds the stored value. Saving runs an automatic connection test; the last result is shown on the edit page. Example: to let AI chat work with your Stripe account, add the **Stripe** provider, enter its Server URL and your Stripe API key, and save — the test confirms the server answers before you enable it for real traffic. Per-provider details: [Providers](/cloud/project/integrations/mcp/providers). ## API reference Endpoints: [AI](/api-reference/ai). # Providers All providers you can connect as Project → Integrations → MCP integrations. **Where:** Project → Integrations → MCP → Integrations → **Add** · `/projects//ai/mcps/integrations/pick` Pick a provider below to see what it is for and what its configuration form asks. In the app the same catalog appears as a gallery on the pick screen; providers you already connected are marked. | Provider | What it is | | ---------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | | [Brave Search](/cloud/project/integrations/mcp/providers/brave-search) | Connect the Brave Search MCP server to give your AI workloads web, image, news and video search. | | [GitHub](/cloud/project/integrations/mcp/providers/github) | Connect the GitHub MCP server to work with repositories, issues and pull requests. | | [MongoDB](/cloud/project/integrations/mcp/providers/mongodb) | Connect the MongoDB MCP server to query and manage your databases and collections. | | [Obsidian](/cloud/project/integrations/mcp/providers/obsidian) | Connect the Obsidian MCP server to read, search and write notes in your vault. | | [Playwright](/cloud/project/integrations/mcp/providers/playwright) | Connect the Playwright MCP server to automate browsers — navigate, click, type and capture pages. | | [Stripe](/cloud/project/integrations/mcp/providers/stripe) | Connect the Stripe MCP server to work with customers, products, invoices and payments. | ## API reference Endpoints: [AI](/api-reference/ai). # Brave Search Connect Brave Search as a Project → Integrations → MCP integration provider. **Where:** Project → Integrations → MCP → Integrations → **Add** → Brave Search · `/projects//ai/mcps/integrations/new/brave-search` {% hint style="info" %} Screenshot TODO — capture comes from testing-plan area **01-integrations**. The description below is complete and verified against the app's provider-picker code. {% endhint %} Connect the Brave Search MCP server to give your AI workloads web, image, news and video search. Requires a Brave Search API key. Create and edit use the same form; editing loads the saved values (secrets stay hidden). ## API reference Endpoints: [AI](/api-reference/ai). # GitHub Connect GitHub as a Project → Integrations → MCP integration provider. **Where:** Project → Integrations → MCP → Integrations → **Add** → GitHub · `/projects//ai/mcps/integrations/new/github` {% hint style="info" %} Screenshot TODO — capture comes from testing-plan area **01-integrations**. The description below is complete and verified against the app's provider-picker code. {% endhint %} Connect the GitHub MCP server to work with repositories, issues and pull requests. Requires a GitHub access token. Create and edit use the same form; editing loads the saved values (secrets stay hidden). ## API reference Endpoints: [AI](/api-reference/ai). # MongoDB Connect MongoDB as a Project → Integrations → MCP integration provider. **Where:** Project → Integrations → MCP → Integrations → **Add** → MongoDB · `/projects//ai/mcps/integrations/new/mongodb` {% hint style="info" %} Screenshot TODO — capture comes from testing-plan area **01-integrations**. The description below is complete and verified against the app's provider-picker code. {% endhint %} Connect the MongoDB MCP server to query and manage your databases and collections. Requires a MongoDB connection string. Create and edit use the same form; editing loads the saved values (secrets stay hidden). ## API reference Endpoints: [AI](/api-reference/ai). # Obsidian Connect Obsidian as a Project → Integrations → MCP integration provider. **Where:** Project → Integrations → MCP → Integrations → **Add** → Obsidian · `/projects//ai/mcps/integrations/new/obsidian` {% hint style="info" %} Screenshot TODO — capture comes from testing-plan area **01-integrations**. The description below is complete and verified against the app's provider-picker code. {% endhint %} Connect the Obsidian MCP server to read, search and write notes in your vault. Configure access via environment variables. Create and edit use the same form; editing loads the saved values (secrets stay hidden). ## API reference Endpoints: [AI](/api-reference/ai). # Playwright Connect Playwright as a Project → Integrations → MCP integration provider. **Where:** Project → Integrations → MCP → Integrations → **Add** → Playwright · `/projects//ai/mcps/integrations/new/playwright` {% hint style="info" %} Screenshot TODO — capture comes from testing-plan area **01-integrations**. The description below is complete and verified against the app's provider-picker code. {% endhint %} Connect the Playwright MCP server to automate browsers — navigate, click, type and capture pages. No credentials required. Create and edit use the same form; editing loads the saved values (secrets stay hidden). ## API reference Endpoints: [AI](/api-reference/ai). # Stripe Connect Stripe as a Project → Integrations → MCP integration provider. **Where:** Project → Integrations → MCP → Integrations → **Add** → Stripe · `/projects//ai/mcps/integrations/new/stripe` Connect the Stripe MCP server to work with customers, products, invoices and payments. Requires a Stripe API key. Create and edit use the same form; editing loads the saved values (secrets stay hidden).

The Stripe MCP form filled in.

Saved — the MCP server is connected.

## API reference Endpoints: [AI](/api-reference/ai). # Settings Project settings — brand, access, languages, environments, webhooks, bindings, admin portal, termination. **Where:** Project → Settings · `/projects//settings?tab=` Project **Settings** holds the project's identity and configuration, split into eight tabs. The open tab is part of the URL (for example `?tab=Webhooks`), so you can link straight to a tab. On managed and Enterprise plans the data **Region** settings are folded into the **Access** tab — old `?tab=Region` links redirect there; self-hosted installs have no regions.

Project → Settings.

## Tabs | Tab | What it holds | | ---------------------------------------------------- | ------------------------------------------------------------------------------ | | [Brand](/cloud/project/settings/brand) | Name, slug, project id, description, URL, logo and icon. | | [Access](/cloud/project/settings/access) | Deployment endpoints, allowed origins (CORS) and — on managed plans — regions. | | [Languages](/cloud/project/settings/languages) | The default language and the supported-language list. | | [Environments](/cloud/project/settings/environments) | The environment ladder (e.g. TEST → PROD), promotion and rollback. | | [Webhooks](/cloud/project/settings/webhooks) | Signed event deliveries to HTTP endpoints you own. | | [Bindings](/cloud/project/settings/bindings) | The `@Model.Project.*` values templates, triggers and code can use. | | [Admin Portal](/cloud/project/settings/admin-portal) | The portal's service user and its API keys. | | [Termination](/cloud/project/settings/termination) | Disable, re-enable or delete the project. | Most edits open a small modal; after a successful save the dashboard shows **"Project settings updated"**. ## Use it from code Every setting has an `updateProject*` method — see [Account & Projects → Projects](/sdks-and-cli/account/projects). ## API reference Endpoints: [Account & Projects → Projects](/api-reference/account/projects). # Brand Project name, description, URL, logo and icon. **Where:** Project → Settings → Brand · `/projects//settings?tab=Brand` The Brand tab holds the project's identity. These values are available across modules — triggers, code and templates — through project tokens such as `@Project.Name` or `@Project.Url` (see [Bindings](/cloud/project/settings/bindings)). {% hint style="info" %} Screenshot TODO — capture comes from testing-plan area **17-project-settings**. {% endhint %} ## Fields | Field | What it does | | ------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Brand assets — Logo, Icon | Project images, uploaded to the project's **default file integration**. Uploading needs at least one enabled file integration ([Files → Integrations](/cloud/files/integrations)); without one the tab shows a "No file service available" warning and blocks uploads. | | Project Id | The project's id (`pr_…`) — read-only, with a copy button. Used in API calls. | | Slugified name | The URL-safe project name — read-only; part of your dashboard links. | | Name | Friendly display name. Token: `@Project.Name`. | | Url | The project's public address — marketing site, app or dashboard. Token: `@Project.Url`. | | Admin portal URL | Optional custom domain for the end-user admin portal. Left empty, the canonical URL from [Access → Deployment endpoints](/cloud/project/settings/access) is used (the field shows it as "Using canonical URL (…)"). Token: `@Project.AdminUrl`. | | Description | Short text describing the project. Token: `@Project.Description`. | **Edit** next to a field opens a modal; a successful save shows **"Project settings updated"**. Example: with **Name** `Aurora Shop` and **Url** `https://aurorashop.com`, an email template containing `@Model.Project.Name` renders "Aurora Shop". ## Use it from code See [Account & Projects → Projects](/sdks-and-cli/account/projects). ## API reference Endpoints: [update-project-name](/api-reference/account/projects/update-project-name), [update-project-description](/api-reference/account/projects/update-project-description), [update-project-url](/api-reference/account/projects/update-project-url), [update-project-admin-url](/api-reference/account/projects/update-project-admin-url), [update-project-logo](/api-reference/account/projects/update-project-logo), [update-project-icon](/api-reference/account/projects/update-project-icon). # Access Deployment endpoints, CORS allowed origins and (managed plans) regions. **Where:** Project → Settings → Access · `/projects//settings?tab=Access` Control how your project is reached: the addresses SDKs and services should call, and the browser origins that may call them. On managed and Enterprise plans the data **Region** settings also live here; self-hosted installs have no regions. {% hint style="info" %} Screenshot TODO — capture comes from testing-plan area **17-project-settings**. {% endhint %} ## Deployment endpoints Read-only addresses discovered from the Hub `/echo` endpoint — use them when configuring SDKs or external services. Each URL opens in a new tab and has a copy button. | Field | What it shows | | --------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | | API URL / API version | Base address and version of the data API — on managed plans, for the project's primary region. | | Hub URL / Hub version | Base address and version of the management (Hub) API. | | Admin portal URL | The canonical portal address. If [Brand → Admin portal URL](/cloud/project/settings/brand) sets an override, the effective URL is shown underneath. | ## Allowed Origins (CORS) The websites that may call the project's API from the browser. **Edit** opens a modal with a comma-separated list; whitespace around entries is trimmed. Add every domain where your app or admin portal runs: ``` http://localhost:3000,https://myproject.com ``` A successful save shows **"Project settings updated"**. Requests from origins not on the list are blocked by the browser's CORS check. ## Region Settings (managed and Enterprise plans) * **Primary region** — where the project's main database and control data live. It is fixed once set and shown read-only. * **Additional regions** — rendered only when the backend marks the project as eligible for multi-region; other projects see an information notice instead. Tick the regions where app-data databases may also be placed and press **Save regions**. A region that still hosts a database cannot be removed — delete the database first. Constraint errors from the server are shown on the tab. ## Use it from code See [Account & Projects → Projects](/sdks-and-cli/account/projects). ## API reference Endpoints: [update-project-allowed-origins](/api-reference/account/projects/update-project-allowed-origins), [update-project-regions](/api-reference/account/projects/update-project-regions). # Languages Default and supported project languages. **Where:** Project → Settings → Languages · `/projects//settings?tab=Languages` Set the languages the project works with. Modules that render user-facing content — email, push and SMS templates — use them for localized variants. {% hint style="info" %} Screenshot TODO — capture comes from testing-plan area **17-project-settings**. {% endhint %} ## Fields | Field | What it does | | ------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Default Language | A dropdown. The default is used for all new content items and for the project's public API when no language is given. | | Supported languages | A badge list. **Edit** opens the language picker to add a language; removing a badge removes the language. Both changes save immediately and show **"Project settings updated"**. | The default language is also available in templates as the `@Model.Project.DefaultLanguage` binding — see [Bindings](/cloud/project/settings/bindings). ## Use it from code See [Account & Projects → Projects](/sdks-and-cli/account/projects). ## API reference Endpoints: [update-project-default-language](/api-reference/account/projects/update-project-default-language), [update-project-languages](/api-reference/account/projects/update-project-languages). # Environments The project's environment ladder — create, promote, roll back. **Where:** Project → Settings → Environments · `/projects//settings?tab=Environments` Environments keep separate sets of integrations, users, templates and campaigns — for example a **TEST** environment that never touches production. **PROD** always exists, cannot be deleted, and is the top of the promotion ladder. {% hint style="info" %} Screenshot TODO — capture comes from testing-plan area **17-project-settings**. {% endhint %} ## The ladder Each environment is listed with its rank (lower = further from PROD) and badges: **top of ladder** on PROD and **current** on the environment the dashboard is showing. Per row you can: * **Switch to this** — the whole dashboard switches to that environment's data. * **Move up / move down** (arrow buttons) — reorder non-PROD environments on the ladder. Promotion only flows up. * **Delete** (trash icon, non-PROD only) — the confirmation modal makes you tick a checkbox first, because the delete cascades and removes the environment's data. ## New environment **New environment** opens a full-screen create form (the same layout as the new-project wizard's Database step): 1. **Environment name** — e.g. `TEST`. 2. A database for the new environment: pick the provider, then either a cluster tier (managed) or a **Connection string** (e.g. `mongodb+srv://user:password@cluster.mongodb.net`), an **Integration name** (e.g. `Primary database`) and an optional **Database name** (defaults to the database in the connection string). On some plans creating extra environments is gated — the server's rejection (for example the trial gate) is shown inside the form. ## Promote When more than one environment exists, the **Promote** button copies content up the ladder: 1. Pick the source and target environments. 2. **Preview** runs a dry run and shows the plan: **Mirrored (created / overwritten)**, **Deleted in target**, **Integrations seeded**, **Integrations skipped (kept)** — plus any **blockers**. 3. **Apply** runs the real promotion. It stays disabled while blockers exist. Content (schemas, templates, triggers) is mirrored into the target. Integrations the target is missing are seeded with their own copy; once an integration exists in both environments, each keeps its own config and secrets — promotion never overwrites or removes them. After a successful apply the tab shows a card like *Promoted **TEST** → **PROD** (at version 12)* with a **Roll back** button that restores the target to its state before that promotion. ## API reference Endpoints: [create-project-environment](/api-reference/account/projects/create-project-environment), [get-project-environments](/api-reference/account/projects/get-project-environments), [delete-project-environment](/api-reference/account/projects/delete-project-environment), [set-environment-rank](/api-reference/account/projects/set-environment-rank), [promote-environment](/api-reference/account/projects/promote-environment), [rollback-promotion](/api-reference/account/projects/rollback-promotion). # Webhooks Signed event deliveries from this project to HTTP endpoints you own. **Where:** Project → Settings → Webhooks · `/projects//settings?tab=Webhooks` Push event notifications from this project to HTTP endpoints you own. Every delivery is a signed JSON envelope POSTed to each destination subscribed to the event. The project has **one** webhook integration — a shared signing secret, shared extra headers, and any number of destinations. A badge shows whether it is **Configured** (the signing secret exists) or **Not configured**; you can define destinations either way, but deliveries only start once the secret is generated. {% hint style="info" %} Screenshot TODO — capture comes from testing-plan area **17-project-settings**. {% endhint %} ## Signing secret One secret, shared by every destination on the project. Subscribers verify the `X-Norbix-Signature` header by computing HMAC-SHA256 of `{timestamp}.{body}` with this secret; the timestamp comes from the `X-Norbix-Timestamp` header. * **Generate** — provisions the secret the first time (turns the badge to Configured). * **Reveal** — shows the current secret so you can copy it into your subscriber. * **Regenerate** — after a confirmation: the current secret stops working immediately, and every subscriber must be updated with the new one. ## Extra headers Static headers added to every delivery from this project — for example an auth header your receiver expects. They are merged with each destination's own headers; the destination's header wins on conflict. Press **Save Headers** to apply. ## Destinations The endpoints that receive events. Each row shows the name, URL, subscribed events, an **Enabled** toggle (pause without deleting) and a **Change** link. **Add Destination** opens the same form: | Field | What it does | | ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Display name | How the destination is listed, e.g. `Billing service`. Required. | | Endpoint URL | Full http(s) URL that receives the POSTed envelope, e.g. `https://example.com/hooks/norbix`. Required and validated as a URL. | | Subscribed events | Checkboxes grouped by module — only the selected events are delivered. **Database:** `database.record.inserted`, `database.record.updated`, `database.record.deleted`, `database.record.replaced`, `database.record.responsibilityChanged`, `database.records.inserted`, `database.records.updated`, `database.records.deleted`. **Membership:** `membership.user.registered`, `membership.user.invited`, `membership.user.verified`, `membership.user.updated`, `membership.user.deleted`, `membership.user.blocked`, `membership.user.reactivated`. **Files:** `files.file.uploaded`, `files.file.deleted`. | | Extra headers | Headers sent only to this destination, on top of the integration-wide ones (destination wins on conflict). | | Enabled | Turn the destination on or off without deleting it. | In edit mode the form also has a red **Delete…** button; after the confirmation, deliveries to that endpoint stop immediately. ### Example A destination `Billing service` pointed at `https://billing.example.com/hooks/norbix`, subscribed to `database.record.inserted` and `membership.user.registered`: when a user registers, Norbix POSTs the signed envelope there, and your receiver recomputes the HMAC with the shared signing secret before trusting the payload. ## API reference Endpoints: [Webhooks](/api-reference/webhooks). # Bindings The live project values templates, triggers and code can reference. **Where:** Project → Settings → Bindings · `/projects//settings?tab=Bindings` A read-only table of every **project binding** — a value you can insert into triggers, code and templates with the `@Model.` prefix, for example `@Model.Project.Name`. Next to each binding the tab shows the value it resolves to right now, using the same lookup the email/SMS/push template builders use — so what you see here is exactly what a template renders. Bindings shown as *Not set* are still valid; they resolve once the underlying project value is configured. {% hint style="info" %} Screenshot TODO — capture comes from testing-plan area **17-project-settings**. {% endhint %} ## Available bindings | Binding | Resolves to | | --------------------------------------------------------- | ---------------------------------------------------------------------------------- | | `@Model.Project.Name` | The project display name. | | `@Model.Project.UniqueName` | The project unique (slug) name. | | `@Model.Project.DefaultLanguage` | The default language code. | | `@Model.Project.Url` | The project marketing URL. | | `@Model.Project.AdminUrl` | The effective admin-portal URL (developer override, else the canonical admin URL). | | `@Model.Project.Logo.Url` / `.Path` / `.IntegrationId` | The logo's public URL, its storage path, and the file integration that holds it. | | `@Model.Project.Icon.Url` / `.Path` / `.IntegrationId` | The same three values for the project icon. | | `@Model.Project.MainColor` / `@Model.Project.AccentColor` | The brand main and accent colors. | Example: an email subject `Welcome to @Model.Project.Name` renders as `Welcome to Aurora Shop` when the [Brand](/cloud/project/settings/brand) name is `Aurora Shop`. ## API reference Endpoints: [get-project-tokens](/api-reference/account/projects/get-project-tokens). # Admin Portal The service user and API keys behind the hosted admin portal. **Where:** Project → Settings → Admin Portal · `/projects//settings?tab=Admin Portal` The Admin Portal signs your end users in to a per-project portal. Its backend authenticates as a dedicated **service user** and reads the portal layout with an API key you issue on this tab. {% hint style="info" %} Screenshot TODO — capture comes from testing-plan area **17-project-settings**. {% endhint %} ## Admin Portal service user Create a service user under [Membership → Users](/cloud/membership/users) (role `AdminPortalManager`), paste its id (`usr_…`) into **Service user id**, and press **Assign service user**. A badge shows **Assigned** or **Not set**; once assigned, the current id is shown with a copy button and you can **Reassign** to a different service user. ## API keys This section appears once a service user is assigned. Keys follow a two-key model: * At most **two** keys per service user — delete one before issuing a new one (the tab warns when you hit the limit). * **Issue key** creates a key, with an optional **Key name** (default `Admin Portal key`). The plaintext is shown **once**, right after issuing — copy it before leaving the page; the server stores only a hash. * Put the key in your self-hosted portal's `API_KEY` environment variable. * The list shows each key's name, its first characters, the created date, an expiry date if set, and an inactive marker. **Delete** (with an inline confirm) is permanent and stops any deployment still using that key. There is no enable/disable switch — the portal works as long as at least one valid key exists. ## What end users see before sign-in The tab notes that brand, auth options and legal documents on the portal's sign-in screen are controlled by the expose toggles on the **Access** tab; this tab only manages the service user and its keys. ## API reference Endpoints: [assign-admin-portal-service-user](/api-reference/account/projects/assign-admin-portal-service-user), [get-admin-portal-structure](/api-reference/account/projects/get-admin-portal-structure). # Termination Disable, re-enable, or permanently delete the project. **Where:** Project → Settings → Termination · `/projects//settings?tab=Termination` Two guarded panels: the project's status (disable / enable) and project deletion. {% hint style="info" %} Screenshot TODO — capture comes from testing-plan area **17-project-settings**. {% endhint %} ## Disable or enable the project **Disable Project** (with a confirmation modal) stops all operations — you can still navigate through the project, but nothing can be changed. Re-enabling depends on your account: * Free capacity on your plan — the project is enabled right away. * Subscription expired or canceled — a **Subscription Expired** modal offers **Get Project Credits**, which sends you to Stripe checkout and returns you to this tab. * No capacity, but an active subscription — an **Update Subscription Required** modal offers **Go to Portal** (the Stripe billing portal) to raise your project cap. A project can also end up disabled without your action when the subscription behind it lapses. ## Delete project **Delete project** is permanent and removes the project with its data. The confirmation modal asks you to type the project id (`pr_…`) exactly; the delete only runs when the typed id matches. Afterwards you are taken back to the account home. ## API reference Endpoints: [disable-project](/api-reference/account/projects/disable-project), [enable-project](/api-reference/account/projects/enable-project), [delete-project](/api-reference/account/projects/delete-project). # Membership Identity, authentication, and access control for your project. **Membership** manages identity, authentication, and access control: the users of your application, the roles and policies that control what they can do (RBAC), sign-in methods (passwords, passkeys, social providers), and the module's automation triggers.

The Membership module home.

## Screens in this module **Users** — the people in your project directory. **Roles** and **Policies** — the RBAC building blocks. **Settings** — how authentication and authorization behave. **Triggers** — automation on user lifecycle events. **Integrations** — external identity providers. ## Use it from code [Membership](/sdks-and-cli/membership) in the SDK reference. ## API reference Endpoints: [Membership](/api-reference/membership). # Users Every person in your project directory. A **user** (contact) is a person in your project's membership directory, with one or more linked logins (identities), a profile, roles, and a lifecycle (invited → verified → active → blocked/deleted).

Membership → Users.

## What you can do here The list shows every person with their **Display Name**, **Primary Email**, **Primary Phone**, **Lifecycle**, and **Created** date. **Add New** opens the [create screen](/cloud/membership/users/new), where you invite a user by email, create a login directly (email, username, or phone based), or register a **service user** with an API key for server-to-server access. Opening a person shows the [detail screen](/cloud/membership/users/edit): their profile, assigned **roles**, **marketing preferences**, and the logins they authenticate with. Login-level actions — **block / unblock**, **verify**, **delete** — live on the login form. Merging duplicate contacts and managing identities (adding, promoting, removing email addresses or phone numbers) is done from code — see the SDK reference below. ## Use it from code [Membership → Users](/sdks-and-cli/membership/users) — 36 methods, from `inviteUser` to `mergeContacts`. ## API reference Endpoints: [Membership → Users](/api-reference/membership/users). # Invite a user Add a user — invite by email, create a login directly, or register a service user. **Where:** Membership → Users → New · `/projects//membership/users/new` {% hint style="info" %} Screenshot TODO — capture comes from testing-plan area **16-membership**. {% endhint %} The screen starts with a **Registration type** card picker. The card you pick decides the form below it: | Card | What you enter | Result | | ------------------- | ------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Email & password | Email address, Password, Display Name | An email login is created; the person can sign in right away. | | Username & password | Username, Password, Display Name | A username login, for apps that do not use email addresses. | | Phone | Phone Number, Display Name | A phone-number login. | | Invite | Email address only | An invitation email is sent; the person finishes registration themselves. | | User as a service | Display Name | A service user for machine-to-machine access, with an API key. | | Passkey | — | No form. Passkeys are created on the user's own device, so passkey users sign up through your app; the card links to the passkey settings and integration guide. | For the Email & password, Username & password, and Phone cards you can also fill optional **Personal Information** (first name, last name, full name, birth date, gender, contact email/phone), an **Address** block, and preferences such as **Language** and **Time Zone**. These same cards, plus User as a service, show a **Roles** picker — toggle "Managed only" to hide system roles. An invited user gets no roles picker: they start with the role set as **Default user role** in [Settings → Onboarding](/cloud/membership/settings/onboarding), and the invitation email template and token expiration come from the same place. ## Example Invite `ruta.k@acme.com`: pick the **Invite** card, type the email address, press **Save**. Norbix sends the invitation email (template: *User invitation email template*), the link stays valid for the configured *Invitation token expiration (in minutes)*, and the new user appears in the list with lifecycle `Invited` until they complete registration. ## Use it from code [Membership → Users](/sdks-and-cli/membership/users) ## API reference Endpoints: [Membership → Users](/api-reference/membership/users). # User details One user — profile, roles, marketing preferences, and logins. **Where:** Membership → Users → user · `/projects//membership/users//edit` {% hint style="info" %} Screenshot TODO — capture comes from testing-plan area **16-membership**. {% endhint %} Opening a user from the list shows the person (the *contact*, id `ct_…`) with their id shown as a copyable button, a **Delete** button, and four tabs. The active tab is kept in the URL hash, so you can link straight to it. ## Tabs * **User** — the editable profile: Personal Information (First Name, Last Name, Full Name, Display Name, Birth Date, Gender, Company, Phone) and Address (Country, Address, Address 2, City, State / Province, ZIP / Postal code). **Save** stores the changes on the contact. * **Roles** — a roles picker. Roles are stored on the person and applied to every login they authenticate with. **Save roles** sends the selected roles as their composite ids (for example `pr_4kX9mQvR2tYw7ZbC1dFgHj_nr_7pW2sKvB9qLm3XcT1yRfGh`); **Reset** restores the saved selection. * **Marketing preferences** — the topics this user receives, split into **Marketing** and **Transactional** tabs. For each topic (tag) you toggle the delivery channels it supports; the topics themselves are defined in [Settings → Communication](/cloud/membership/settings/communication). * **Identification** — the read-only list of logins (email, username, phone, social, service, or guest) with each login's type and status. Below it, **Map an existing login** is a recovery tool: paste a login id (`usr_…`) and press **Map** to attach a login that was not linked automatically. Deleting the user removes the contact and returns you to the list. ## Use it from code [Membership → Users](/sdks-and-cli/membership/users) ## API reference Endpoints: [Membership → Users](/api-reference/membership/users). # Roles Roles bundle policies and are assigned to users — Norbix RBAC. A **role** bundles one or more policies and is assigned to users to control what they can do — this is Norbix's role-based access control (RBAC). Roles are project-scoped: `content-editor` in one project does not exist in another.

Membership → Roles.

## What you can do here The list shows each role's **Role Name**, its **Type** (System or Custom), and how many **Policies** it carries. **Add New** opens the [create screen](/cloud/membership/roles/new); clicking a role opens the [edit screen](/cloud/membership/roles/edit), where you change its description and attached policies. System (built-in) roles are shown read-only and cannot be deleted. Assign roles to users on the **Users** screen. A practical pattern: keep roles few and human-readable (`admin`, `editor`, `member`) and put the fine-grained permissions into policies. ## Use it from code [Membership → Roles](/sdks-and-cli/membership/roles). ## API reference Endpoints: [Membership → Roles](/api-reference/membership/roles). # Create a role Define a role and attach its policies. **Where:** Membership → Roles → New · `/projects//membership/roles/new` {% hint style="info" %} Screenshot TODO — capture comes from testing-plan area **16-membership**. {% endhint %} Roles group one or more policies that can be assigned to users. ## Fields | Field | What it does | | ----------------- | ------------------------------------------------------------------------------------------------------ | | Role name | Required. The role's name, e.g. `content-editor`. It cannot be changed after the role is created. | | Description | Optional free text explaining what the role is for. | | Attached policies | A searchable picker of the project's policies. Expand a policy to preview the JSON document it grants. | After **Save** the role appears in the roles list and can be assigned to users on the [Users](/cloud/membership/users) screen. The role gets a composite id — project + role — for example `pr_4kX9mQvR2tYw7ZbC1dFgHj_nr_7pW2sKvB9qLm3XcT1yRfGh`; this is the value that travels in role assignments. ## Example Create `content-editor` with the description "Can edit database records" and attach the policies `database-read` and `database-write`. Every user who gets this role receives the union of both policies' permissions. ## Use it from code [Membership → Roles](/sdks-and-cli/membership/roles) ## API reference Endpoints: [Membership → Roles](/api-reference/membership/roles). # Edit a role Change a role's description and policies. **Where:** Membership → Roles → role → Edit · `/projects//membership/roles//edit` {% hint style="info" %} Screenshot TODO — capture comes from testing-plan area **16-membership**. {% endhint %} The same form as [Add New Custom Role](/cloud/membership/roles/new), loaded with the saved values — the screen title reads **Editing role**. The **Role name** field is locked; you can change the **Description** and the **Attached policies**. Saving applies the new policy set to every user who has the role. System (built-in) roles open as **Displaying system role**: name, description, and attached policies are shown read-only, and both **Save** and **Delete** are unavailable. Custom roles can be deleted from the actions menu (⋯ → Delete). ## Use it from code [Membership → Roles](/sdks-and-cli/membership/roles) ## API reference Endpoints: [Membership → Roles](/api-reference/membership/roles). # Policies Reusable permission sets attached to roles. A **policy** is a reusable set of permissions — allow/deny statements over modules and actions. Policies are attached to roles; a user's effective permissions are the union of the policies on all their roles.

Membership → Policies.

## What you can do here The screen has two tabs: **Custom Policies** (yours — create, edit, delete) and **System Policies** (built-in, read-only). **Add New** opens the [create screen](/cloud/membership/policies/new), where a policy is written as a JSON **policy document** — name, description, and permission statements in one place. The same policy can be attached to many roles, so a change in one place updates every role that uses it. ## Use it from code [Membership → Policies](/sdks-and-cli/membership/policies). ## API reference Endpoints: [Membership → Policies](/api-reference/membership/policies). # Create a policy Define a named set of permissions. **Where:** Membership → Policies → New · `/projects//membership/policies/new` {% hint style="info" %} Screenshot TODO — capture comes from testing-plan area **16-membership**. {% endhint %} A policy is a named set of permission statements — what its holders may do, per module and action. On this screen the whole policy is one **Policy document**: a JSON editor where the name, description, and permissions all live together. The editor validates against the Norbix policy schema in real time and highlights violations; **Save** stays disabled until the document is valid and has a `name`. ## The policy document * `version` — the schema version; new documents use `2026-09-17`. * `name`, `description` — the policy's metadata, taken from the document on save. * `permissions` — a list of statements. Each has an optional `sid`, an `effect` (`Allow` or `Deny`), a list of `actions` (such as `database:Read`), and a list of `resources` in the form `::::` — wildcards (`*`) are allowed and clamped to your own account and project. ## Example ```json { "version": "2026-09-17", "name": "database-read-only", "description": "Read access to every database collection in this project.", "permissions": [ { "sid": "Statement1", "effect": "Allow", "actions": ["database:Read"], "resources": ["acc_*:pr_4kX9mQvR2tYw7ZbC1dFgHj:database:collection:*"] } ] } ``` After **Save** the policy appears under **Custom Policies** and can be attached to [roles](/cloud/membership/roles). It gets a public id in the `pol_…` form. ## Use it from code [Membership → Policies](/sdks-and-cli/membership/policies) ## API reference Endpoints: [Membership → Policies](/api-reference/membership/policies). # Edit a policy Change a policy's permission statements. **Where:** Membership → Policies → policy → Edit · `/projects//membership/policies//edit` {% hint style="info" %} Screenshot TODO — capture comes from testing-plan area **16-membership**. {% endhint %} The same JSON editor as [Add New Custom Policy](/cloud/membership/policies/new), loaded with the saved document — the screen title reads **Editing policy**. The document now carries a `pid` field with the policy's public id (`pol_…`); leave it in place so the update validates. Saving applies the changed permissions immediately to every role — and through the roles, every user — holding the policy. System policies open as **Displaying system policy**: the document is read-only and cannot be saved or deleted. Custom policies can be deleted from the actions menu (⋯ → Delete). ## Use it from code [Membership → Policies](/sdks-and-cli/membership/policies) ## API reference Endpoints: [Membership → Policies](/api-reference/membership/policies). # Triggers Run an action automatically on user lifecycle events. A **membership trigger** runs an action automatically when something happens to a user — for example sending a welcome email when a user registers. Events: `OnRegistered`, `OnInvited`, `OnVerified`, `OnUpdated`, `OnDeleted`, `OnBlocked`, `OnReactivated`.

Membership → Triggers.

## What you can do here The list shows each trigger's **Trigger Name**, **When** (the event), **What** (the action, e.g. Send Email), and whether it is **Enabled**. **Add New** opens the [create screen](/cloud/membership/triggers/new), where you pick the **event**, the **action** (run code, send an email, push, or SMS, call a webhook, or send a realtime/SSE event), and the action's **delivery settings**. Opening a trigger lets you [edit, enable/disable, or delete it](/cloud/membership/triggers/edit). See the [Triggers overview](/other-topics/triggers) for the full concept. ## Use it from code [Membership → Triggers](/sdks-and-cli/membership/triggers) — the save page covers one working example per action type. ## API reference [Save Membership Trigger](/api-reference/membership/triggers/save-membership-trigger) documents the full polymorphic request. # Create a trigger React to user events with an action. **Where:** Membership → Triggers → New · `/projects//membership/triggers/new` {% hint style="info" %} Screenshot TODO — capture comes from testing-plan area **02-triggers**. {% endhint %} The form is a two-step flow: **If this** (the event) … **then** (the action). ## If this — pick the event | Event | Fires | | ---------------------------------- | ---------------------- | | When registered (`OnRegistered`) | A new user registers. | | When invited (`OnInvited`) | A new user is invited. | | When verified (`OnVerified`) | A user is verified. | | When updated (`OnUpdated`) | A user is updated. | | When deleted (`OnDeleted`) | A user is deleted. | | When blocked (`OnBlocked`) | A user is blocked. | | When reactivated (`OnReactivated`) | A user is reactivated. | The user's data is passed to the action, so templates and payloads can use tokens from it. ## … then — pick the action **Run Code** (invoke a serverless function), **Send Email**, **Send Push Notification**, **Send SMS** (all three from a template, with delivery settings for who receives it), **Call Webhook** (POST a signed event payload to your destinations — the webhook event name, e.g. `membership.user.registered`, is implied by the chosen event), or **Send In-App (Realtime / SSE)** (deliver live to connected apps or AI agents). Each action opens its own settings block. ## Finish Set the **Order** (lower numbers run earlier when several triggers share an event) and optionally **Break execution queue on failure**. Then **Name the trigger** (e.g. `When user registers, send welcome email`), add a **Description**, and switch **Is this trigger enabled?** on when it is ready. Saving returns you to the list. How triggers work in general — events, action types, and delivery settings — is explained in [Triggers](/other-topics/triggers). ## Use it from code [Membership → Triggers](/sdks-and-cli/membership/triggers) ## API reference Endpoints: [Save Membership Trigger](/api-reference/membership/triggers/save-membership-trigger). # Edit a trigger Change a trigger's event, action, or state. **Where:** Membership → Triggers → trigger → Edit · `/projects//membership/triggers//edit` {% hint style="info" %} Screenshot TODO — capture comes from testing-plan area **02-triggers**. {% endhint %} The same form as [Add New Trigger](/cloud/membership/triggers/new), loaded with the saved trigger. The header shows the trigger's copyable id, and the actions menu (⋯) offers **Enable** / **Disable** and **Delete trigger…**. A disabled trigger shows the banner "Trigger is disabled, but you can still edit it." — your edits are kept even while it does not run. ## Use it from code [Membership → Triggers](/sdks-and-cli/membership/triggers) ## API reference Endpoints: [Save Membership Trigger](/api-reference/membership/triggers/save-membership-trigger). # Integrations External identity providers for social sign-in. Membership **integrations** connect external identity providers so your users can sign in to your app with accounts they already have — without creating a new password.

Membership → Integrations.

## What you can do here The list shows each integration's **Integration Name**, **Provider**, and whether it is **Enabled**. **Add New Integration** opens the provider picker with the available providers: **Google Sign In**, **Apple Sign In**, **Microsoft (Azure AD)**, **GitHub**, **Meta (Facebook)**, **X (Twitter)**, and **Okta**. You add a provider with its client credentials, then **enable** it to make the sign-in method available to your app; integrations can be disabled or deleted at any time. See the provider pages under this section for per-provider setup. ## Use it from code [Membership → Integrations](/sdks-and-cli/membership/integrations). ## API reference Endpoints: [Membership → Integrations](/api-reference/membership/integrations). # Providers All providers you can connect as Membership integrations. **Where:** Membership → Integrations → **Add** · `/projects//membership/integrations/pick` Pick a provider below to see what it is for and what its configuration form asks. In the app the same catalog appears as a gallery on the pick screen; providers you already connected are marked. | Provider | What it is | | -------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- | | [Google Sign In](/cloud/membership/integrations/providers/google-sign-in) | Let users sign in with their Google account. | | [Apple Sign In](/cloud/membership/integrations/providers/apple-sign-in) | Sign in with Apple. | | [Microsoft (Azure AD)](/cloud/membership/integrations/providers/microsoft) | Sign in with a Microsoft work, school or personal account using an Azure AD app registration. | | [GitHub](/cloud/membership/integrations/providers/github) | Sign in with GitHub. | | [Meta (Facebook)](/cloud/membership/integrations/providers/meta) | Sign in with a Facebook account. | | [X (Twitter)](/cloud/membership/integrations/providers/x) | Sign in with X. | | [Okta](/cloud/membership/integrations/providers/okta) | Sign in via Okta. | ## API reference Endpoints: [Membership → Integrations](/api-reference/membership/integrations). # Google Sign In Connect Google Sign In as a Membership integration provider. **Where:** Membership → Integrations → **Add** → Google Sign In · `/projects//membership/integrations/new/google-sign-in` {% hint style="info" %} Screenshot TODO — capture comes from testing-plan area **01-integrations**. The description below is complete and verified against the app's provider-picker code. {% endhint %} Let users sign in with their Google account. Bring your own OAuth 2.0 client id and client secret from your Google Cloud project. Create and edit use the same form; editing loads the saved values (secrets stay hidden). ## API reference Endpoints: [Membership → Integrations](/api-reference/membership/integrations). # Apple Sign In Connect Apple Sign In as a Membership integration provider. **Where:** Membership → Integrations → **Add** → Apple Sign In · `/projects//membership/integrations/new/apple-sign-in` {% hint style="info" %} Screenshot TODO — capture comes from testing-plan area **01-integrations**. The description below is complete and verified against the app's provider-picker code. {% endhint %} Sign in with Apple. Provide your Apple Developer team id, services id, key id and the .p8 private key. Create and edit use the same form; editing loads the saved values (secrets stay hidden). ## API reference Endpoints: [Membership → Integrations](/api-reference/membership/integrations). # Microsoft (Azure AD) Connect Microsoft (Azure AD) as a Membership integration provider. **Where:** Membership → Integrations → **Add** → Microsoft (Azure AD) · `/projects//membership/integrations/new/microsoft` {% hint style="info" %} Screenshot TODO — capture comes from testing-plan area **01-integrations**. The description below is complete and verified against the app's provider-picker code. {% endhint %} Sign in with a Microsoft work, school or personal account using an Azure AD app registration. Provide tenant id, client id and client secret. Create and edit use the same form; editing loads the saved values (secrets stay hidden). ## API reference Endpoints: [Membership → Integrations](/api-reference/membership/integrations). # GitHub Connect GitHub as a Membership integration provider. **Where:** Membership → Integrations → **Add** → GitHub · `/projects//membership/integrations/new/github` {% hint style="info" %} Screenshot TODO — capture comes from testing-plan area **01-integrations**. The description below is complete and verified against the app's provider-picker code. {% endhint %} Sign in with GitHub. Provide the client id and client secret of your GitHub OAuth App. Create and edit use the same form; editing loads the saved values (secrets stay hidden). ## API reference Endpoints: [Membership → Integrations](/api-reference/membership/integrations). # Meta (Facebook) Connect Meta (Facebook) as a Membership integration provider. **Where:** Membership → Integrations → **Add** → Meta (Facebook) · `/projects//membership/integrations/new/meta` {% hint style="info" %} Screenshot TODO — capture comes from testing-plan area **01-integrations**. The description below is complete and verified against the app's provider-picker code. {% endhint %} Sign in with a Facebook account. Provide your Meta app id and app secret. Create and edit use the same form; editing loads the saved values (secrets stay hidden). ## API reference Endpoints: [Membership → Integrations](/api-reference/membership/integrations). # X (Twitter) Connect X (Twitter) as a Membership integration provider. **Where:** Membership → Integrations → **Add** → X (Twitter) · `/projects//membership/integrations/new/x` {% hint style="info" %} Screenshot TODO — capture comes from testing-plan area **01-integrations**. The description below is complete and verified against the app's provider-picker code. {% endhint %} Sign in with X. Provide your API key and API secret key from the X developer portal. Create and edit use the same form; editing loads the saved values (secrets stay hidden). ## API reference Endpoints: [Membership → Integrations](/api-reference/membership/integrations). # Okta Connect Okta as a Membership integration provider. **Where:** Membership → Integrations → **Add** → Okta · `/projects//membership/integrations/new/okta` {% hint style="info" %} Screenshot TODO — capture comes from testing-plan area **01-integrations**. The description below is complete and verified against the app's provider-picker code. {% endhint %} Sign in via Okta. Provide your Okta org domain plus the OAuth client id and client secret. Create and edit use the same form; editing loads the saved values (secrets stay hidden). ## API reference Endpoints: [Membership → Integrations](/api-reference/membership/integrations). # Settings How authentication and authorization behave for this project. Membership **Settings** controls how sign-in and permissions behave for your application's users. The screen has five tabs, kept in the URL hash: [Onboarding](/cloud/membership/settings/onboarding) (`#onboarding`), [Authentication](/cloud/membership/settings/authentication) (`#authentication`), [Account](/cloud/membership/settings/account) (`#account`), [Communication](/cloud/membership/settings/communication) (`#communication`), and [Advanced](/cloud/membership/settings/advanced) (`#advanced`). Older deep links such as `#registration`, `#passkey`, or `#deactivation` still work — they redirect into the tab that now holds that section.

Membership → Settings.

## What you can do here **Onboarding** — registration rules, default and permitted roles, password settings, invitation and verification emails, custom profile fields. **Authentication** — logout redirects and passkey (WebAuthn) sign-in. **Account** — the user deactivation flow. **Communication** — the preference topics users can subscribe to. **Advanced** — disable the whole module. ## Use it from code [Membership → Settings](/sdks-and-cli/membership/settings). ## API reference Endpoints: [Membership → Settings](/api-reference/membership/settings). # Onboarding Registration, passwords, invitations, verification, and custom fields. **Where:** Membership → Settings → Onboarding · `/projects//membership/settings#onboarding` {% hint style="info" %} Screenshot TODO — capture comes from testing-plan area **16-membership**. {% endhint %} Everything about how users get into your project, in five sections. ## Registration | Setting | What it does | | ---------------------------------------------------------------- | --------------------------------------------------------------------------------------- | | Allow users to register with usernames, not just email addresses | Toggle username-based registration on or off. | | Default user role | The role applied to a newly registered user when no other role is specified. | | Permitted user registration roles | The roles you may assign when creating a user programmatically (outside the dashboard). | | Welcome email template | Send a welcome email to the new user. | | Guest registers as | The role applied to a guest user by default. | ## Password settings | Setting | What it does | | -------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | | Password complexity | Minimum/maximum length and required numbers, uppercase, lowercase, and special characters. Applies to registration, password reset, and password change. | | Password reset email template | The email used for password resets; without one, a newly generated password is sent instead. | | Password reset token expiration (in minutes) | How long the reset token stays valid. | | Password reset callback URL | Where the user is redirected after the reset. | ## Invitation via Email An **Enabled** switch, plus the **User invitation email template**, the **Invitation token expiration (in minutes)**, and the **Invitation callback URL** the user is sent to after confirming. Used when you [invite a user](/cloud/membership/users/new). ## Verification via Email An **Enabled** switch, plus the **User verification email template**, the **Verification token expiration (in minutes)**, and the **Verification callback URL**. ## Custom fields A **Custom schema** you edit at `…/membership/settings/meta` — it defines the extra profile fields users carry beyond the built-in ones. ## Example For a project where users self-register with email only: leave the username toggle off, set **Default user role** to `member`, pick your `welcome-email` template, and set the verification email with a 60-minute token expiration. A new sign-up then arrives as `member`, gets the welcome and verification emails, and must confirm within an hour. ## API reference Endpoints: [Membership → Settings](/api-reference/membership/settings). # Authentication Logout redirects and passkey sign-in. **Where:** Membership → Settings → Authentication · `/projects//membership/settings#authentication` {% hint style="info" %} Screenshot TODO — capture comes from testing-plan area **16-membership**. {% endhint %} Two sections: **Auth preferences** (logout redirects) and **Passkey** (passwordless sign-in with WebAuthn). The old `#auth` and `#passkey` links land here. ## Auth preferences | Field | What it does | | --------------------------- | ------------------------------------------------------------------------------ | | Default logout URL | Where to redirect users after logout when no environment-specific URL applies. | | Logout URL (\) | One row per project environment that has its own redirect. | | + Add logout environment | Pick a project environment and the URL to redirect its users to after logout. | ## Passkey An **Enabled** switch turns passkey sign-in on for the project, then: | Field | What it does | | ------------------------------------------------------------ | --------------------------------------------------- | | Accepted authenticators | Which authenticator types are allowed for passkeys. | | Max passkeys per user | Upper limit of registered passkeys. | | Allow magic-link recovery | Let users recover access via an emailed link. | | Email code lifetime (minutes) | How long emailed sign-in codes stay valid. | | Generate recovery codes at sign-up / Recovery codes per user | One-time codes for account recovery. | | Refresh token lifetime (days) | How long sessions can be renewed. | | Relying Party ID (advanced) | The WebAuthn domain binding for passkeys. | Passkey users create their credentials on their own devices, so they sign up through your app — the dashboard's [Add New User](/cloud/membership/users/new) screen only links here. ## API reference Endpoints: [Membership → Passkeys](/api-reference/membership/passkeys-recovery). # Account User deactivation flow. **Where:** Membership → Settings → Account · `/projects//membership/settings#account` {% hint style="info" %} Screenshot TODO — capture comes from testing-plan area **16-membership**. {% endhint %} Configures **Deactivation via Email** — the confirmation flow when a user deactivates their account. The old `#deactivation` link lands here. ## Fields | Field | What it does | | ------------------------------------------ | ------------------------------------------------- | | Enabled | Turn the email-based deactivation flow on or off. | | User deactivation email template | The email template sent to the user. | | Deactivation token expiration (in minutes) | How long the confirmation link works. | | Deactivation callback URL | Where the user is redirected after deactivating. | With the flow enabled, a deactivation request sends the chosen email; the user confirms through its link before the token expires, and is then redirected to the callback URL. ## API reference Endpoints: [Membership → Settings](/api-reference/membership/settings). # Communication Preference topics users can subscribe to, per channel. **Where:** Membership → Settings → Communication · `/projects//membership/settings#communication` {% hint style="info" %} Screenshot TODO — capture comes from testing-plan area **16-membership**. {% endhint %} Defines the **Communication Preferences** catalogue for the project: the topics (tags) users can subscribe to or block, organised into groups. Two tabs split the catalogue by communication type — **Marketing** and **Transactional**. ## What you can do here * **+ Add New Group** — create a preference group; each group holds one or more tags. * **Tags** — inside a group, add or edit a tag. A tag has a unique **Tag** name, an **Origin Channel**, the delivery channels it offers (**Email**, **Push Notifications**, **SMS**, **In-App Notifications**, **Web Push**, **Chat Bot**, **Chat Platform**), and per-language translations (**Tag friendly name**, **Tag description**) shown to end users. * **Orphaned tags** — tags no longer in any group; they appear as "Other options" in the end-user portal and can be edited or cleaned up here. Each user's own choices for these topics are managed on their [User Details → Marketing preferences](/cloud/membership/users/edit) tab. ## Example Under **Marketing**, create the group `Product updates` with the tag `newsletter`, offering Email and In-App Notifications, with the English friendly name "Monthly newsletter". Users can then opt out of `newsletter` without blocking transactional messages. ## API reference Endpoints: [Notifications → Contacts](/api-reference/notifications/contacts). # Advanced Advanced membership options. **Where:** Membership → Settings → Advanced · `/projects//membership/settings#advanced` {% hint style="info" %} Screenshot TODO — capture comes from testing-plan area **16-membership**. {% endhint %} Module-level settings and actions. The old `#generic` link lands here. The single action is **Disable membership module**: turns the module off for this project, and all related membership data is deleted. After confirming you are returned to the module's start page, where the module can be enabled again — but the previous data is gone. ## API reference Endpoints: [Membership → Settings](/api-reference/membership/settings). # Database A schema-driven data layer on top of MongoDB. The **Database** module gives your project a schema-driven data layer on top of MongoDB — structured collections with validation, a full CRUD + query API, record-level triggers, taxonomies, saved aggregations, and CSV imports. You host MongoDB (or use a managed Flex cluster); Norbix owns the schema layer and the API surface.

The Database module home.

## Screens in this module **Collections** — your records and their schemas. **Taxonomies** — hierarchical terms you attach to records. **Aggregates** — saved MongoDB pipelines. **Imports** — CSV loading. **Integrations** — the MongoDB connection(s). **Settings** — module behaviour. ## Use it from code [Database](/sdks-and-cli/database) in the SDK reference — including the end-user data API (`find`, `insertOne`, `findOwn`, ...). ## API reference Endpoints: [Database](/api-reference/database). # Collections Collections hold your records — schema, data, and triggers in one place. A **collection** holds your records. Its **schema** defines the fields, types, and validation; Norbix then generates a full CRUD + query API over the collection, with record-level ownership and triggers.

Database → Collections.

## What you can do here The list shows every published collection with its **Status** — `Published · v2`, or `Published · v2 · draft pending` when unpublished edits exist on top. Schemas that were never published sit below in **Schemas under development**; publish one to start adding records. A flame icon in the **Triggers** column marks collections that have triggers and jumps to their Triggers tab; the row menu has **Edit schema**. **Add New** creates a collection by creating its schema — see [Build a Schema](/cloud/database/collections/create-schema) for the full walkthrough (drafts, versions, publishing). Click a collection to work with its [records](/cloud/database/collections/records) in the generated grid and form, define [triggers](/cloud/database/collections/schema-triggers) that fire on `OnInserted`, `OnUpdated`, or `OnDeleted`, and check [index coverage](/cloud/database/collections/schema-indexes) for sorting on the List tab. Records respect **ownership**: switch **Records have an owner** on in the collection's Settings tab and the end-user API can be limited to "own" records (`findOwn`), so an app user only reads what belongs to them. ## Use it from code [Database → Collections](/sdks-and-cli/database/collections) for data calls, [Database → Schemas](/sdks-and-cli/database/schemas) for schema management. ## API reference Endpoints: [Database → Collections](/api-reference/database/collections) and [Schemas](/api-reference/database/schemas). # Create a Schema Build a collection schema — data structure, UI layout, and publishing. {% hint style="info" %} Creating a collection **is** creating its schema: start from a ready-made template you adjust, or from a blank schema (`/projects//db/collections/new` → builder at `…/db/schemas/new`). {% endhint %} Every collection is defined by **two schemas** that you edit together: * the **Data schema** — what is stored and validated: fields, types, and rules. It is standard JSON Schema — strings (with formats like `email`, `uri`, `uuid`), integers, numbers, booleans, dates, arrays, objects, plus Norbix widgets such as **geolocation**, file references, taxonomy terms, and record references. * the **UI schema** — how the record form looks: **tabs** → **containers** (with headers) → **cells** on a 12-column grid, each cell pointing at a field with its widget, label, and required flag. From these two documents Norbix generates everything: the validation, the record form in the dashboard, and the CRUD + query API. ## Step by step **1. Start a new schema.** Open **Database → Collections**, create a collection (or open one and go to its **Schema** tab). A new schema starts empty in the **Visual Builder**:

A new, empty schema in the Visual Builder.

**2. Open the JSON editor.** Press **JSON**, then **Edit JSON**. Two editors appear — the **Data schema** on top, the **UI schema** below. This view is ideal for pasting a schema from another project or a template:

The JSON view: Data schema (top) and UI schema (bottom).

**3. Define both schemas.** Fill the Data schema first (fields, types, validation), then the UI schema (tabs, containers, grid cells). Here both are filled with the kitchen-sink example that uses every field type:

Both schemas filled. The save button enables only when both documents are valid JSON.

**4. Save and switch to the Visual Builder.** Press **Save schemas' changes**, then **Visual Builder**. The builder hydrates from your JSON — tabs across the top, every field in its container and grid cell:

The Basics tab after hydration.

**5. Check every tab.** Each UI-schema tab becomes a builder tab — switch through them to verify the layout:

The Numbers & Dates tab — numeric and date fields with their widgets.

The Contact & Refs tab — email/URL formats, references, and the geolocation widget.

**6. Publish.** Schemas are **drafts** until you publish. Publishing creates a new schema **version**; records keep working during edits, you can diff versions, and you can discard a draft to return to the published version. Below — the builder after loading a "kitchen sink" schema that uses every field type, laid out in three tabs (Basics, Numbers & Dates, Contact & Refs):
Schema builder with every field type

The Visual Builder hydrated with all field types — tabs on top, containers and grid cells inside.

{% hint style="info" %} The same schema drives the record form your team uses in the dashboard and the validation applied to every API write — change it once, both follow. {% endhint %} ## Editing an existing schema Open a collection's **Schema** tab (`/projects//db/schemas//edit`) to reopen the same builder on a live schema. Changes are saved to a **draft** first — existing records are untouched until you **publish**. The version history lets you diff what changed between publishes. ## Use it from code Schemas are fully manageable from the SDKs — drafts, publishing, versions, diffs: [Database → Schemas](/sdks-and-cli/database/schemas). ## API reference Endpoints: [Database → Schemas](/api-reference/database/schemas). # Schema Triggers React to record changes in one collection. **Where:** Database → Collections → collection → **Triggers** · `/projects//db/schemas//triggers/new · …//edit` {% hint style="info" %} Screenshot TODO — capture comes from testing-plan area **02-triggers**. {% endhint %} Schema triggers fire on record events for **one collection**. That is why, unlike other modules, schema trigger API calls carry a `schemaId` (`sch_…`) next to the trigger id (`trg_…`). Collections that have triggers show a small flame icon in the Collections list — it deep-links to this tab. ## Fields * **When** — the event: **When inserted**, **When updated**, or **When deleted**. The record's data is passed to the action as tokens (`@Model.…`); the update event also carries the record's previous values. * **Then** — the action that runs: send an email, push, or SMS from a template, call a webhook, publish a realtime (SSE) event, run a code function, or run an installed marketplace function. * **Name the trigger** (required) — e.g. `When an order is inserted, call the fulfilment webhook` — plus an optional **Description**. * **Is this trigger enabled?** — a disabled trigger stays saved and editable but does not fire. * **Order** and **Break execution queue on failure** — control the run order when several triggers listen to the same event, and whether a failure stops the ones after it. How trigger actions and delivery settings work in detail is explained in [Triggers](/other-topics/triggers). ## Use it from code [Database → Triggers](/sdks-and-cli/database/triggers) ## API reference Endpoints: [Save Schema Trigger](/api-reference/database/schemas/save-schema-trigger). # Schema Indexes Indexes that keep record queries and sorting fast. **Where:** Database → Collections → collection → Schema editor → **List** tab {% hint style="info" %} Screenshot TODO — capture comes from testing-plan area **03-database-collections**. {% endhint %} There is no separate index-management screen. The dashboard reads the collection's MongoDB indexes (via `listIndexes`) and uses them in the schema editor's **List** tab to warn you before a slow sort ships to your team. ## How index coverage works Each index lists one or more fields as its **keys**; `_id` always has its built-in index. A sort on field `F` is only index-covered when `F` is the **first key** of an existing index. For example, an index with keys `[{ "field": "lastName" }, { "field": "firstName" }]` covers sorting by `lastName`, but **not** by `firstName`. On the **List** tab, every selected column that is not covered gets a ⚠ marker with the tooltip *No index on this field — sorting may be slow on large collections.* The same coverage rule decides whether the records list's default sort runs fast. Indexes themselves are created on the MongoDB side (your own cluster or the managed Flex cluster), not from this screen. ## Use it from code [Database → Collections](/sdks-and-cli/database/collections) ## API reference Endpoints: [Database → Collections](/api-reference/database/collections). # Records Working with records — the generated form and data grid. **Where:** Database → Collections → collection · `/projects//db/collections//records` Open a collection to work with its **records**. The page header shows the collection name with its published schema version — for example **Employees (v2)**. {% hint style="info" %} Screenshot TODO — capture comes from testing-plan area **03-database-collections**. {% endhint %} ## What you can do here * **Browse** — the grid shows the columns chosen on the schema's **List** tab (all schema fields when nothing was chosen). **Previous / Next** page through the records with cursors, 10 per page. * **Sort** — click a column header to switch between ascending and descending; a sort change jumps back to page one. Without a click, the **List** tab's default sort applies; without that, the newest records come first. * **Add New** — opens the record form generated from the schema (see [Add Records](/cloud/database/collections/add-records)). The button is disabled while the schema is still a draft: the page then shows the warning *Schema not published yet* with an **Edit schema** button, because records can only be added after **Save & publish**. * **Edit / Delete…** — each row has an Edit link to the record form and a Delete link with a confirmation dialog. * **Schema** split button — jumps straight into the schema editor's tabs: **Schema**, **List**, **Triggers**, **Settings**. An empty published collection shows the note *No records yet — use Add New to create the first record.* ## Use it from code [Database → Collections](/sdks-and-cli/database/collections) — `find`, `insertOne`, `updateOne`, `findOwn`, and the rest of the data API. ## API reference Endpoints: [Database → Collections](/api-reference/database/collections). # Add Records A form generated from the collection's schema. **Where:** Database → Collections → collection → Records → New / Edit · `/projects//db/collections//records/new · …//edit` {% hint style="info" %} Screenshot TODO — capture comes from testing-plan area **03-database-collections**. {% endhint %} The record form is generated from the collection's two schemas: the **Data schema** provides the fields and validation, the **UI schema** provides the layout — tabs, containers with headers, and cells on a 12-column grid. The page title carries the collection and its version, e.g. **Add New Record — Employees (v2)** or **Edit Record — Employees (v2)**. ## Fields Every schema field renders with its assigned widget: text (including `email`, `uri`, and HTML formats), number, date, rating, boolean, select, tags, file upload, geolocation, taxonomy-term picker, and record reference. The Data schema's validation rules (required fields, formats, ranges) run before save — an invalid form does not submit. For an `Employees` schema with a required `firstName` (string) and a `salary` (number), the form shows those two inputs in the layout the UI schema defines, and refuses to save while `firstName` is empty. Buttons: **Create** (new record) or **Update** (editing), **Cancel** back to the records list, and **Delete** with a confirmation dialog when editing. After a successful save you return to the records list. ## Use it from code [Database → Collections](/sdks-and-cli/database/collections) — `insertOne` and `replaceOne` run the same validation. ## API reference Endpoints: [Insert One](/api-reference/database/collections/insert-one) and [Replace One](/api-reference/database/collections/replace-one). # Taxonomies Hierarchical terms — categories and tags for your records. A **taxonomy** is a hierarchical set of terms — categories, tags, topic trees — that you attach to records. One taxonomy (e.g. `product-categories`) holds many terms (`electronics` → `phones` → `android`).

Database → Taxonomies.

## What you can do here The list shows every taxonomy with its **Description** and **Parent(s)**. **Add New** opens the [create form](/cloud/database/taxonomies/new); clicking a taxonomy name opens its [terms](/cloud/database/taxonomies/terms); the row menu has **Edit taxonomy**. Taxonomies can be chained: a taxonomy with a **Parent** taxonomy forces every one of its terms to sit under a parent term (a City must belong to a Country), and **Additional categories** let a term carry extra parents from other taxonomies. Records reference terms, and the query API can fetch term trees and children — useful for menus, filters, and category pages. ## Use it from code [Database → Taxonomies](/sdks-and-cli/database/taxonomies). ## API reference Endpoints: [Database → Taxonomies](/api-reference/database/taxonomies). # Create a taxonomy Define a classification tree for your records. **Where:** Database → Taxonomies → New · `/projects//db/taxonomies/new` {% hint style="info" %} Screenshot TODO — capture comes from testing-plan area **04-taxonomies**. {% endhint %} ## Fields * **Taxonomy name** (required) — e.g. `Cities`. * **Description** — free text. * **Parent** — one other taxonomy (default *— None —*). Setting it places this taxonomy in a tree: every term you later create must then pick a required parent term from that taxonomy. * **Additional categories** — checkboxes with the project's other taxonomies. Terms can then carry extra parents from those taxonomies. A taxonomy set as Parent cannot also be ticked here — the form rejects it with *A taxonomy cannot be both the Parent and an Additional category. Remove it from one.* **Save** stores the taxonomy (`txn_…`) and returns to the list; **Cancel** discards. After saving you add the actual [terms](/cloud/database/taxonomies/terms) records get tagged with. Example: create `Countries` with no parent, then `Cities` with **Parent** = `Countries`. Every city term must now name its country, and the API can fetch a country's cities as term children. ## Use it from code [Database → Taxonomies](/sdks-and-cli/database/taxonomies) ## API reference Endpoints: [Save Database Taxonomy](/api-reference/database/taxonomies/save-database-taxonomy). # Edit a taxonomy Rename or re-describe a taxonomy. **Where:** Database → Taxonomies → taxonomy → Edit · `/projects//db/taxonomies//edit` {% hint style="info" %} Screenshot TODO — capture comes from testing-plan area **04-taxonomies**. {% endhint %} The same form as [Create a taxonomy](/cloud/database/taxonomies/new) with the saved values loaded (`txn_…`) — the header reads *Editing Cities taxonomy*. Change the name, description, **Parent**, or **Additional categories**, then **Save**. A **Delete** button with a confirmation dialog removes the taxonomy. Terms are managed on their own screen — see [Terms](/cloud/database/taxonomies/terms). ## Use it from code [Database → Taxonomies](/sdks-and-cli/database/taxonomies) ## API reference Endpoints: [Save Database Taxonomy](/api-reference/database/taxonomies/save-database-taxonomy) and [Delete Database Taxonomy](/api-reference/database/taxonomies/delete-database-taxonomy). # Terms The values inside a taxonomy. **Where:** Database → Taxonomies → taxonomy → Terms · `/projects//db/taxonomies//terms (+ /new, //edit)` {% hint style="info" %} Screenshot TODO — capture comes from testing-plan area **04-taxonomies**. {% endhint %} Terms are the actual values records get tagged with — for example `electronics`, `books`, `clothing` inside a `categories` taxonomy. The list ( *"categories" Taxonomy Terms* ) shows each term with its **Parent** and **Order**; **Add New Term** opens the form. ## Fields * **Title** (required in at least one language) and **Description** — both translatable. When the project has several languages, language tabs switch which translation you edit. * **Order** — a number; lower numbers show first, empty means unordered (those sort after the ordered terms). * **Parent** — only shown when the taxonomy has a Parent taxonomy, and then **required**: the picker lists that taxonomy's terms (e.g. a `Cities` term must select its `Countries` term). The validation message is *Please select a parent from Countries.* * **Additional categories** — only shown when the taxonomy has Additional categories configured: checkbox lists of terms from those taxonomies. A term set as Parent cannot also be ticked here. **Save** writes the term and returns to the list; **Delete** (edit only) asks for confirmation. When other taxonomies use this one as their Parent, editing a term also lists its child terms below the form — e.g. editing a `Regions` term shows its `Countries`, each linking to that term's edit screen, with an **Add New** that pre-selects this term as the parent. ## Use it from code [Database → Taxonomies](/sdks-and-cli/database/taxonomies) ## API reference Endpoints: [Save Database Taxonomy Term](/api-reference/database/taxonomies/save-database-taxonomy-term), [Update Database Taxonomy Term](/api-reference/database/taxonomies/update-database-taxonomy-term), [Find Terms](/api-reference/database/taxonomies/find-terms). # Aggregates Saved MongoDB pipelines you run to compute and summarise data. An **aggregate** is a saved MongoDB aggregation pipeline you run on demand — to group, count, join, and summarise records without writing that logic into your app.

Database → Aggregates.

## What you can do here The list shows every saved aggregate with its **ID** (`maggr_…`), **Name**, and the **Schema** (collection) it runs on. **Add New** opens the editor — see [Create an aggregate](/cloud/database/aggregates/new) for the fields, the sample record panel, and the **TEST** run against live data. Click an aggregate's id to [edit it](/cloud/database/aggregates/edit). Because your app calls an aggregate **by id** (`executeAggregate`), the pipeline stays server-side — you can tune it here without redeploying anything. ## Use it from code [Database → Aggregates](/sdks-and-cli/database/aggregates); run one with `executeAggregate` from the data API. ## API reference Endpoints: [Database → Aggregates](/api-reference/database/aggregates). # Create an aggregate Write and test a MongoDB aggregation pipeline. **Where:** Database → Aggregates → New · `/projects//db/aggregates/new` {% hint style="info" %} Screenshot TODO — capture comes from testing-plan area **04-taxonomies**. {% endhint %} ## Fields * **Schema** (required) — the collection the pipeline runs on. Picking one shows a **Sample record** panel with the first record from that collection, so you can see the field names you are aggregating. * **Name** (required) and **Description**. * The **pipeline editor** — standard MongoDB stages as JSON. Strict JSON validation is off on purpose: you may embed tokens that start with `@Model`, e.g. `{ "$match": { "birthDate": { "$gt": @Model.userBirthday } } }`, and pass the values at execution time. * **TEST** — runs the pipeline against live data and shows the response as an expandable JSON tree. When the pipeline contains `@Model` tokens, a modal first asks for a test value per token. Example pipeline — paid orders per customer, biggest spenders first: ```json [ { "$match": { "status": "paid" } }, { "$group": { "_id": "$customerId", "orders": { "$sum": 1 }, "total": { "$sum": "$amount" } } }, { "$sort": { "total": -1 } } ] ``` **Save** stores the aggregate and returns to the list; it gets an id (`maggr_…`) your app calls with `executeAggregate`. **Create using AI Chat** opens the assistant, which reads your schema fields, drafts the pipeline into this editor, and leaves saving to you. ## Use it from code [Database → Aggregates](/sdks-and-cli/database/aggregates) ## API reference Endpoints: [Save Database Aggregate](/api-reference/database/aggregates/save-database-aggregate), [Test Database Aggregate](/api-reference/database/aggregates/test-database-aggregate), [Execute Aggregate](/api-reference/database/collections/execute-aggregate). # Edit an aggregate Change and re-test a saved pipeline. **Where:** Database → Aggregates → aggregate → Edit · `/projects//db/aggregates//edit` {% hint style="info" %} Screenshot TODO — capture comes from testing-plan area **04-taxonomies**. {% endhint %} The same editor as [Create an aggregate](/cloud/database/aggregates/new) with the saved pipeline loaded. The **Schema** is fixed — an existing aggregate cannot be moved to another collection; name, description, and the pipeline are editable, and **TEST** re-runs against live data. A **Delete** button with a confirmation dialog removes the aggregate. Because apps call the aggregate **by id** (`maggr_…`), you can tune the pipeline here without redeploying anything. **Edit using AI Chat** lets the assistant rewrite the open pipeline in place — you review the change and press **Save**. ## Use it from code [Database → Aggregates](/sdks-and-cli/database/aggregates) ## API reference Endpoints: [Save Database Aggregate](/api-reference/database/aggregates/save-database-aggregate), [Delete Database Aggregate](/api-reference/database/aggregates/delete-database-aggregate). # Imports Load records into a collection from a CSV file. **Imports** load records into a collection from an uploaded CSV file, with a column-to-field mapping — the fastest way to move existing data into Norbix.

Database → Imports.

## What you can do here **Import** starts the [import wizard](/cloud/database/imports/new). Each run appears as a row that updates **live** while the import processes: **Initiated On** (links to the [details](/cloud/database/imports/details)), **Schema** (links to the target collection's records), **Status**, **Imported / Total**, and **Errors** with a download link for the run's `errors.txt`. Statuses: `Created`, `Processing`, `Completed`, `Completed with issues` (completed, but some rows failed validation), and `Failed`. A **Delete** action removes a finished import together with its stored CSV and `errors.txt` — a running import cannot be deleted. Imports store their files in the project's **file storage**, so the Files module with an enabled files integration is required. ## Use it from code [Database](/sdks-and-cli/database) in the SDK reference. ## API reference Endpoints: [Database](/api-reference/database). # Import records from CSV Upload a CSV and map its columns to schema fields. **Where:** Database → Imports → Import · `/projects//db/imports/new` {% hint style="info" %} Screenshot TODO — capture comes from testing-plan area **05-imports**. {% endhint %} This page shows a worked example of the mapping step of the [import wizard](/cloud/database/imports/new). ## Example — importing employees A CSV with the header row `email,first name,salary,hired` into an `Employees` collection with fields `email`, `firstName`, `salary`, `hiredOn`: | CSV column | Mapping decision | Why | | ------------ | ------------------------------------------- | ------------------------------------------------------------- | | `email` | `email` (auto-matched) | Header equals the field name. | | `first name` | `firstName` (picked by hand) | Names differ, so no auto-match. | | `salary` | `salary`, **Don't import on error** checked | A malformed number should send the whole row to `errors.txt`. | | `hired` | **Don't import** | The collection tracks `hiredOn` from another source. | After the run, the import (`imp_…`) reports rows imported vs. rows in the file, and every rejected row lands in `errors.txt` with its validation error. ## Which fields can be a target A CSV column can map to **string** (including email, URL, HTML formats), **number**, **integer**, **currency**, **boolean**, **date**, **select** (enum), and **tags** fields. File, geolocation, and taxonomy/collection/user/role reference fields cannot be filled from a CSV import. ## API reference Endpoints: [Database](/api-reference/database). # Create an import The import wizard — source file, target collection, mapping. **Where:** Database → Imports → Import · `/projects//db/imports/new` {% hint style="info" %} Screenshot TODO — capture comes from testing-plan area **05-imports**. {% endhint %} The wizard has four steps shown as a progress rail: **Source**, **Target**, **Mapping**, **Result**. If the Files module is off or no files integration is enabled, the page shows *Imports need file storage* instead — the CSV and `errors.txt` live in your project's file storage. ## Step by step **1. Source.** Pick the **File Storage**, the **Delimeter**, and whether the file **has a CSV header**. Then upload one `.csv` (browse or drag & drop, up to 50 MB). The file goes straight to storage and is analyzed; changing the delimiter or header option afterwards re-analyzes it without a re-upload. **2. Target.** Pick the **Schema** — the collection the rows go into. **3. Mapping.** A table shows every CSV column with **Matched**, **Header**, **Column Preview** (sample values), and **Mapping**. Columns whose header equals a schema field name are pre-matched automatically. Map the rest by hand (each field can be used once), or mark a column as **Don't import**. Per column, **Don't import on error** decides what an invalid value does: checked — the whole row goes to `errors.txt`; unchecked — the row is imported with that field left empty (unless the schema requires it). **4. Result.** Press **Import**. The button stays disabled until every column has a decision — the hint reads *Map every column to a property or mark it as "Don't import".* You return to the Imports list, where the run's progress updates live; open it for the [details](/cloud/database/imports/details). See [Import records from CSV](/cloud/database/imports/csv-import) for a worked mapping example and the field types a CSV column can target. ## API reference Endpoints: [Database](/api-reference/database). # Import details One import's mapping and run results. **Where:** Database → Imports → import · `/projects//db/imports//edit` {% hint style="info" %} Screenshot TODO — capture comes from testing-plan area **05-imports**. {% endhint %} The **Import preview** shows one saved import (`imp_…`): its status badge, a copyable import id, and the facts of the run — * **Schema**, **Initiated On**, **Completed On**; * **Total rows in the file**, **Total rows imported**, **Total rows not imported because of errors**; * a **Failure reason** when the run failed; * the **Source file** (the uploaded CSV, downloadable) and the **Error file** `errors.txt` with one line per rejected row; * the frozen **Mapping** table — CSV column, header, target property (or *Not imported*), and the per-column *Don't import on error* choice. **Delete** removes the import together with its stored CSV and `errors.txt`; it is blocked while the import is still `Processing`. **Back** returns to the list. ## API reference Endpoints: [Database](/api-reference/database). # Integrations The MongoDB connection behind your project data. A database **integration** is the MongoDB connection your project's data lives in — a managed **Flex** cluster provisioned by Norbix, or your own MongoDB via a connection string.

Database → Integrations.

## What you can do here The list shows each connection with its **Provider** (*MongoDB Connection String* or *Norbix MongoDB Atlas (Flex Managed)*), **Last Test Succeeded**, **Enabled**, and a **Default** badge — the default is set per environment. With several active connections and no default, the page warns you until one is chosen. **Add New Integration** opens the provider picker: bring your own connection string, or let Norbix provision an Atlas Flex cluster (you pick the tier, and can reveal the connection string later when you need direct access). Open a connection to **test** it, set it as the **default**, or enable/disable it. ## Use it from code [Database → Integrations](/sdks-and-cli/database/integrations). ## API reference Endpoints: [Database → Integrations](/api-reference/database/integrations). # Providers All providers you can connect as Database integrations. **Where:** Database → Integrations → **Add** · `/projects//db/integrations/pick` Pick a provider below to see what it is for and what its configuration form asks. In the app the same catalog appears as a gallery on the pick screen; providers you already connected are marked. | Provider | What it is | | --------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- | | [MongoDB](/cloud/database/integrations/providers/mongodb) | MongoDB is a general purpose, document-based, distributed database built for modern application developers and for the cloud era. | ## API reference Endpoints: [Database → Integrations](/api-reference/database/integrations). # MongoDB Connect MongoDB as a Database integration provider. **Where:** Database → Integrations → **Add** → MongoDB · `/projects//db/integrations/new/mongodb` {% hint style="info" %} Screenshot TODO — capture comes from testing-plan area **01-integrations**. The description below is complete and verified against the app's provider-picker code. {% endhint %} MongoDB is a general purpose, document-based, distributed database built for modern application developers and for the cloud era. Norbix supports two connection modes: bring your own connection string, or let Norbix provision and manage an Atlas Flex cluster for you. Create and edit use the same form; editing loads the saved values (secrets stay hidden). ## API reference Endpoints: [Database → Integrations](/api-reference/database/integrations). # Settings Database module behaviour for this project. **Where:** Database → Settings · `/projects//db/settings` Database **Settings** holds the module-level switch: turning the Database module off for this project.

Database → Settings.

## What you can do here **Disable the module** — the panel at the bottom disables the Database module for the whole project. This is destructive: all related data is deleted with the module. Export anything you still need first. Per-collection behaviour (soft delete, record ownership, description) does not live here — it is on each collection's **Settings** tab in the schema editor (see [Build a Schema](/cloud/database/collections/create-schema)). ## Use it from code [Database → Module](/sdks-and-cli/database/module) — enable and disable the module from the SDKs. ## API reference Endpoints: [Disable Database](/api-reference/database/module/disable-database) and [Enable Database](/api-reference/database/module/enable-database). # Files Cloud storage that participates in your backend. **Where:** Files · `/projects//files` The **Files** module is cloud storage that participates in your backend — not an isolated bucket. Upload, deliver, and secure files with the same identity, permissions, and audit trail as the rest of your project. Files can be used as **File** fields in Database schemas, so a record can carry its own attachments.

The Files module home.

The bytes live in a storage **integration** you connect — AWS S3, Google Drive, Google Cloud Storage, or Azure Blob Storage. Until the module is enabled, `/files` shows the enable page ("Norbix Files"); after **Enable**, you land in the Browser. ## Screens in this module * [Browser](/cloud/files/browser) — the folder tree and files, with [upload](/cloud/files/browser/upload). * [Triggers](/cloud/files/triggers) — run an action on `OnFileUploaded` / `OnFileDeleted`. * [Integrations](/cloud/files/integrations) — where the bytes are stored, and which integration is the default. * [Settings](/cloud/files/settings) — disable the module. ## Use it from code [Files](/sdks-and-cli/files) — including the end-user API (upload URL, download, list own files). ## API reference Endpoints: [Files](/api-reference/files). # Browser Browse, upload, and manage your project files. **Where:** Files → Browser · `/projects//files/browser` The **Files Browser** shows the files of one storage integration as a folder tree. Folders are virtual — they are path prefixes, and a folder appears as soon as a file exists under it. That is why there is no "create folder" button: upload a file to a new path and the folder is there.

Files → Browser.

## What you can do here * **Upload file** — the button in the header uploads into the current folder. See [Upload Files](/cloud/files/browser/upload) for the flow behind it. * **Integrations** dropdown — shown when the project has more than one storage integration; each option lists the integration name and its provider. Switching it changes which storage account you are browsing. * **Breadcrumbs** — navigation is by path, starting at `root`. Click a folder row to go deeper, a breadcrumb to go back up. * **The list** — folders first, then files, with **Name** and **Size** columns. * **File details** — click a file to open the slide-over: an image preview for `png`, `jpg`, `jpeg`, `gif`, `webp`, `svg` (loaded through a short-lived signed URL), the file's size, **Extension**, **Provider**, and its **Path** with a copy button. From there you can **Download** the file or **Delete** it. The path is the file's address — for example `invoices/2026/invoice-4821.pdf` — and it is what the sign, download, and delete endpoints take. If no integration is connected yet, the page shows an alert linking to the [Integrations](/cloud/files/integrations) page. ## Use it from code [Files](/sdks-and-cli/files) — [Get Folder Files](/sdks-and-cli/files/folder/get-folder-files), [Get Signed Url](/sdks-and-cli/files/sign/get-signed-url), [Download File](/sdks-and-cli/files/download/download-file-api), [Delete File](/sdks-and-cli/files/module/delete-file-api). ## API reference Endpoints: [Get Folder Files](/api-reference/files/folder/get-folder-files), [Get Signed Url](/api-reference/files/sign/get-signed-url), [Download File](/api-reference/files/download/download-file-api), [Delete File](/api-reference/files/module/delete-file-api). # Upload files Upload files — the request-URL / commit flow. **Where:** Files → Browser → **Upload file** · `/projects//files/browser` In the dashboard, uploading is one action: press **Upload file**, pick a file, and it lands in the folder you are currently viewing (the button reads "Uploading…" while it works). Under the hood it is a three-step direct upload — the bytes go straight to your storage provider and never pass through Norbix. {% hint style="info" %} Screenshot TODO — capture comes from testing-plan area **10-payments-files**. {% endhint %} ## Step by step 1. **Request an upload URL** — the dashboard asks the API for a pre-signed PUT URL for the target path (current folder + file name) and content type. Endpoint: [Request Upload Url](/api-reference/files/upload-url/request-upload-url). 2. **PUT the bytes** — the browser sends the file directly to the storage provider using that URL. 3. **Commit** — the dashboard calls [Commit Upload](/api-reference/files/commit/commit-upload) with the path, file name, content type, and size. The backend records the file and raises the `FileUploaded` event, which runs any `OnFileUploaded` [trigger](/cloud/files/triggers). The browser list then refreshes. Example: uploading `invoice-4821.pdf` while viewing `invoices/2026` requests an upload URL for path `invoices/2026/invoice-4821.pdf` with content type `application/pdf`, then commits it with its size in bytes. The same flow is what your own apps use — request the URL, PUT, commit — so files uploaded by end users appear in this browser too. ## Use it from code [Request Upload Url](/sdks-and-cli/files/upload-url/request-upload-url) · [Commit Upload](/sdks-and-cli/files/commit/commit-upload) ## API reference Endpoints: [Request Upload Url](/api-reference/files/upload-url/request-upload-url), [Commit Upload](/api-reference/files/commit/commit-upload). # Triggers Run an action automatically when files are uploaded or deleted. **Where:** Files → Triggers · `/projects//files/triggers` A **files trigger** runs an action automatically on storage events — `OnFileUploaded` or `OnFileDeleted`. For example: notify the team when a file lands, or run a function that processes every upload.

Files → Triggers.

## What you can do here The **File Triggers** list shows every trigger with its name, event ("When uploaded" / "When deleted"), and action (Send Email, Send Push Notification, Send SMS, Send Webhook, Run code, …). Click a trigger to [edit it](/cloud/files/triggers/edit), or press **Add New** to [create one](/cloud/files/triggers/new). A trigger can be enabled, disabled, or deleted at any time from its edit page. Full concept — events, the action types, and delivery settings: [Triggers overview](/other-topics/triggers). ## Use it from code [Files → Triggers](/sdks-and-cli/files/triggers). ## API reference [Save Files Trigger](/api-reference/files/triggers/save-files-trigger), [Get Files Triggers](/api-reference/files/triggers/get-files-triggers), [Enable](/api-reference/files/triggers/enable-files-trigger) / [Disable](/api-reference/files/triggers/disable-files-trigger) / [Delete Files Trigger](/api-reference/files/triggers/delete-files-trigger). # Create a trigger React to file events with an action. **Where:** Files → Triggers → New · `/projects//files/triggers/new` {% hint style="info" %} Screenshot TODO — capture comes from testing-plan area **02-triggers**. {% endhint %} The form is a two-step flow: **If this** (the event) … **then** (the action). ## If this — pick the event | Event | Fires | | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | | When uploaded (`OnFileUploaded`) | A new file is uploaded — the dashboard's Upload commit or the API's [Commit Upload](/api-reference/files/commit/commit-upload). | | When deleted (`OnFileDeleted`) | A file is deleted. | The file's data is passed to the action, so templates and payloads can use tokens from it. ## … then — pick the action **Run Code** (invoke a serverless function with the event data), **Send Email**, **Send Push Notification**, **Send SMS** (all three from a template, with delivery settings for who receives it), **Call Webhook** (POST a signed event payload to your destinations — the webhook event name, `files.file.uploaded` or `files.file.deleted`, is implied by the chosen event; **Save** stays disabled until you select an enabled destination subscribed to that event), or **Send In-App (Realtime / SSE)** (deliver live to connected apps or AI agents). Each action opens its own settings block. ## Finish Set the **Order** (lower numbers run earlier when several triggers share an event) and optionally **Break execution queue on failure**. Then **Name the trigger** (e.g. `When an invoice is uploaded, email accounting`), add a **Description**, and switch **Is this trigger enabled?** on when it is ready. Saving returns you to the list. How triggers work in general — events, action types, and delivery settings — is explained in [Triggers](/other-topics/triggers). ## Use it from code [Files → Triggers](/sdks-and-cli/files/triggers) ## API reference Endpoints: [Save Files Trigger](/api-reference/files/triggers/save-files-trigger). # Edit a trigger Change a trigger's event, action, or state. **Where:** Files → Triggers → trigger → Edit · `/projects//files/triggers//edit` {% hint style="info" %} Screenshot TODO — capture comes from testing-plan area **02-triggers**. {% endhint %} The same form as [Create a files trigger](/cloud/files/triggers/new), loaded with the saved trigger. The header shows the trigger's id (`trg_…`) with a copy button, and an actions menu with **Enable** / **Disable**, **Delete trigger...**, and **See documentation**. A disabled trigger shows a banner — "Trigger is disabled, but you can still edit it." — and stays saved but never fires. Change the event, the action and its delivery settings, the **Order**, name, or description, then **Save**. **Cancel** returns to the list without saving. ## Use it from code [Files → Triggers](/sdks-and-cli/files/triggers) — [Get Files Trigger](/sdks-and-cli/files/triggers/get-files-trigger), [Enable](/sdks-and-cli/files/triggers/enable-files-trigger) / [Disable](/sdks-and-cli/files/triggers/disable-files-trigger) / [Delete Files Trigger](/sdks-and-cli/files/triggers/delete-files-trigger). ## API reference Endpoints: [Save Files Trigger](/api-reference/files/triggers/save-files-trigger), [Get Files Trigger](/api-reference/files/triggers/get-files-trigger), [Delete Files Trigger](/api-reference/files/triggers/delete-files-trigger). # Integrations Where your file bytes are stored. **Where:** Files → Integrations · `/projects//files/integrations` A files **integration** is the storage backend for your project's files. The **Files Integrations** list shows each one with its **Integration Name**, **Provider**, **Enabled** state, and a **Default** badge — defaults are set per environment ("Default for {environment}").

Files → Integrations.

## What you can do here * **Add New Integration** — opens the provider picker (`/files/integrations/pick`) with four providers: [AWS S3](/cloud/files/integrations/providers/aws-s3) (Cross-Account Role or IAM user), [Google Drive](/cloud/files/integrations/providers/google-drive), [Google Cloud](/cloud/files/integrations/providers/google-cloud) (Storage bucket), and [Azure Blob](/cloud/files/integrations/providers/azure-blob). * **Edit** — click an integration's name to open its form, test the connection, enable or disable it, or change credentials. * **Default** — the default integration is where new uploads go; existing files stay where they are. If several integrations are enabled but none is the default, the list shows a "No Default Set For Active Integrations" warning. The [Browser](/cloud/files/browser) reads and writes against the integration selected in its **Integrations** dropdown. ## Use it from code [Files → Integrations](/sdks-and-cli/files/integrations). ## API reference Endpoints: [Files → Integrations](/api-reference/files/integrations) — [Save](/api-reference/files/integrations/save-files-integration), [Set as Default](/api-reference/files/integrations/set-files-integration-as-default), [Enable](/api-reference/files/integrations/enable-files-integration) / [Disable](/api-reference/files/integrations/disable-files-integration) / [Delete Files Integration](/api-reference/files/integrations/delete-files-integration). # Providers All providers you can connect as Files integrations. **Where:** Files → Integrations → **Add** · `/projects//files/integrations/pick` Pick a provider below to see what it is for and what its configuration form asks. In the app the same catalog appears as a gallery on the pick screen; providers you already connected are marked. | Provider | What it is | | ------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | | [AWS S3](/cloud/files/integrations/providers/aws-s3) | Amazon Simple Storage Service (Amazon S3) is an object storage service offering industry-leading scalability, data availability, security, and performance. | | [Google Drive](/cloud/files/integrations/providers/google-drive) | Store project files in Google Drive using a service account. | | [Google Cloud Storage](/cloud/files/integrations/providers/google-cloud) | Store project files in a Google Cloud Storage bucket using a service account JSON key. | | [Azure Blob Storage](/cloud/files/integrations/providers/azure-blob) | Store project files in an Azure Blob Storage container using a storage account connection string. | ## API reference Endpoints: [Files → Integrations](/api-reference/files/integrations). # AWS S3 Connect AWS S3 as a Files integration provider. **Where:** Files → Integrations → **Add** → AWS S3 · `/projects//files/integrations/new/aws-s3` {% hint style="info" %} Screenshot TODO — capture comes from testing-plan area **01-integrations**. The description below is complete and verified against the app's provider-picker code. {% endhint %} Amazon Simple Storage Service (Amazon S3) is an object storage service offering industry-leading scalability, data availability, security, and performance. Connect your S3 bucket using a Cross-Account Role (recommended) or an IAM user. Create and edit use the same form; editing loads the saved values (secrets stay hidden). ## API reference Endpoints: [Files → Integrations](/api-reference/files/integrations). # Google Drive Connect Google Drive as a Files integration provider. **Where:** Files → Integrations → **Add** → Google Drive · `/projects//files/integrations/new/google-drive` {% hint style="info" %} Screenshot TODO — capture comes from testing-plan area **01-integrations**. The description below is complete and verified against the app's provider-picker code. {% endhint %} Store project files in Google Drive using a service account. Optionally scope storage to a specific folder. Create and edit use the same form; editing loads the saved values (secrets stay hidden). ## API reference Endpoints: [Files → Integrations](/api-reference/files/integrations). --- [Next Page](/llms-full.txt/1)