Skip to main content


In Altogic, you work on apps. An app is your workspace that packages all required design and configuration elements to run your backend app services. All application design elements are specified in snapshots, and all execution configurations are specified in environments.

Apps also hold additional data such as app parameters, client library keys, object level security settings, rate limit configurations, external connection configurations, custom nodes, access groups, and application team settings.


App parameters are name-value pairs that can be used in defining expressions and designing application services. You can define the default application parameters at the application level, and if needed, override them at the environment level.

Each app parameter has a name, type and value attribute. The type of the parameter can be either text, boolean, integer, decimal, date-time, email, link or identifier.

For example, you can define the default value of a 3rd party API key (e.g., Twilio authentication token) as a text application parameter.

Application parameters can be used across all snapshots of your app, and they are accessed through the expression editor while designing your services.


Altogic supports authentication of your application users using emails or phone numbers and through third-party providers such as Google, Apple, Facebook, and Twitter. In the authentication settings of an application, you can turn on or off email or phone number based authencation and define their configuration parameters. Additionally, you can specify the authentication providers that your application will use, the success and failure redirect URL for your front-end, and the required client id and client secret for the OAuth flow.

By default, you need to provide a permanent user data model where Altogic will store authenticated user information such as the user name, email, profile picture, provider name, provider id, sign-up date, and last login date. Whenever a user of your application is authorized through one of the selected and configured authentication providers, Altogic creates or updates the user entry in the database and returns an access token in the "response" query string parameter of the redirect URL.

Client library keys

Altogic has the client API which significantly speeds up integaration of your frontend apps with your Altogic backend. In order to use the Altogic's client API you need to create a client key which specifies the access rights and authorized domains. Using client keys you can manage (allow or restrict) client API access to the modules of your backend app and only allow client requests that are originated from a list of predefined domains.

Object level security

Object security rules define the conditions to allow or restrict certain operations on your app data. When the security rule expression evaluates to true or if the expression is left empty, then the requested action on the your app data object will be allowed.

In Altogic, you can define object level security rules for all your permament models, cloud storage buckets and files and your app's cache keys.

Rate limiting

Rate limiting puts a cap on how often someone can call an endpoint or client library method of your app within a certain timeframe – for instance, trying to log in to an account. By rate limiting, you can help stop certain kinds of malicious bot activity.

You can define default rate limits for endpoints and realtime messaging separately at application level. If needed you can also override the default app level rate limits for each endopoint and client key.


External connections are the configuration settings to connect your apps to legacy email and database servers. These settings are primarily used by service nodes while designing your services. You can define the default external connections at the application level and, if needed, override them at the environment level.


Altogic currently supports SMTP (email) server external connections. In the future, we will be adding additional external connections, such as connections to legacy databases and their associated core nodes, so that you can use them in your service designs.

Access groups

Access groups are used to authorize specific endpoints of your application. When you create an endpoint, you can specify the list of access groups that are allowed to access the service exposed by the endpoint. For example, you can create access groups based on the functions of an organization such as sales, finance, HR, or production and allow only sales and/or finance teams to call endpoints that create, update or delete new sales entries.

To use access groups, sessions need to be enabled for the endpoints in consideration, and when creating the user session, the access group key needs to be provided.

Custom nodes

Custom nodes are your preconfigured Call REST API Endpoint nodes that you can use in your service designs. For example, if you will be repetitively using a "Call REST API Endpoint" node, you can define this node as a custom node and use it in your services without the need to configure each parameter of the node repetitively.

If you believe other Altogic platform users can also utilize your custom nodes, you can submit your custom nodes to the marketplace so that other people can use them in their apps.


Altogic allows collaborative application development with role-based access controls. You can add team members to applications with specific roles. Altogic provides built-in roles such as owner, admin, member and guest that can be used when adding new team members. You can also define custom roles with different permissions and assign these custom roles to your team members.


You can restrict access to specific views and actions to authorized users using role-based access control defined around roles and permissions. Roles can be created for various team member profiles and permissions to perform certain operations assigned to specific roles. Team members are assigned particular roles, and through these role assignments, they can or cannot perform certain actions.

Each role has a predefined number of permissions that grant or restrict access to specific views or actions. Permissions also have a hierarchy, meaning if top-level permission is disabled, child permissions cannot be enabled. For example, if you disable view snapshots for a particular role, then permission like view models, view services, etc., are automatically disabled.

Altogic provides 4 default roles that can be assigned to team members. These default roles cannot be deleted and modified; however, you can create a new custom role as a copy of a default role and customize its permissions.

  • Owner - The owner has all the permissions to manage an application. As its name implies owner role is assigned to the user who created the application. Therefore, there can be only one owner in an application.
  • Admin - Admins also have almost full permissions to manage an application, except they are not authorized to delete the app or transfer ownership. Only the user with the Owner role can delete the app or transfer its ownership to another app team member.
  • Member - Member role provides permissions to design applications (create and update models, services, endpoints, tasks, queues, snapshots, etc.) but restricts administrative operations. For example, members cannot manage team members, add new team members, assign roles to a team member or create/update roles.
  • Guest - Team members with a guest role are only authorized to view application design elements and environments. Guest are only allowed to view snapshots, models, services, endpoints, tasks, message queues, and environments. They cannot create, update or delete these design elements. Even though guests are allowed to view environments, they are not authorized to view API keys of environments.


You can add team members to your applications so that you can work as a team in designing and managing your applications. In addition, you can assign a role to your team members that will allow access to specific views and actions to authorized users.

You can invite others to join you in developing your applications. All invitations of a particular application and their status can be viewed, and specific invitations can be resent or revoked.