Application¶

An application is the backend of your client application. It encapsulates your data model (entities), security rules, file storage, email configuration, custom endpoints, and reports.

Create¶

To create a new Application, open Applications in the Portal and click New application. You need to define:

Upon creation, the application receives:

• A unique Application Token (GUID) — used to identify the application in every API request
• An Encryption Key (8 characters) — used for encrypting sensitive data. The token, the API server address and the key are shown under Info (a button on the application's screens, and in the menu of its card)
• The system entities Users, AuthTokens (read-only: the sign-in tokens) and Files, plus the differentiation entity if you named one
• A default report, "User registrations per day", on the Reports tab

In the Portal the application opens on its tabs: Entities, Data, Security, Custom endpoints, Email, Reports, Sharing (owner only), Import, Audit log (who changed what in the Portal) and Settings.

Application settings¶

After creating an application, you can configure these settings on its tabs in the Portal: authentication, files and IP access on the Security tab, mail on the Email tab, and the name, connection string and online status on the Settings tab.

Authentication¶

Files¶

Email¶

SMTP settings for sending confirmation and password reset emails. See Email Templates for details. All six fields are needed: with any of them empty the application sends no mail, and the Email tab shows "Incomplete".

Networking¶

Advanced¶

Differentiation entity¶

A differentiation entity allows you to conceptually "split" data on the application entities, depending on a system property on the system entity Users.

How it works¶

For example, if you are building an application shared between multiple companies, you can set a differentiation entity named Company. Then, each user will have access only to records of the company they are assigned to.

When a differentiation entity is set:

1. A new entity is created with that name (e.g., Company)
2. The Users and Files entities get an extra system property named {Entity}_ID (e.g., Company_ID). It cannot be written through the Data API
3. Every subsequent entity you create has the option to include a differentiation property
4. On every Data, Files and Stats call on an entity that has the differentiation property, Apilane automatically appends a filter based on the user's differentiation value. The people who manage the application in the Portal are not filtered, and custom endpoints get no automatic filter: write the condition in your SQL

It is a client application concern to decide how to assign values to that differentiation entity property for each user. For example, the application developer can use a Custom endpoint to assign the proper differentiation property value to a new user, depending on application needs.

Name the differentiation entity with letters only (a–z, A–Z), up to 40 characters: the name becomes a table name and part of the property name {Name}_ID. The differentiation entity is a system entity: it cannot be renamed or deleted, it has record change tracking on, and it starts with ID and Created, so add your own properties to it (for example a Name) on its Properties page.

Example¶

A new Application is created with Differentiation entity Company. Apart from the typical system entities, a new entity is created named Company. Additionally, on system entity Users there is an extra system property named Company_ID.

Every new user that is registered to the application, will by default be assigned the value null on the differentiation property Company_ID.

On every subsequent entity that is created, there is the option to add a differentiation property or not. That is because some entities may hold data that should be common for all companies. On entities where this option is enabled, an extra system property named Company_ID will appear.

If User_A creates a record on a differentiated entity, the record column Company_ID will have value null. If User_B creates a record, the record column Company_ID will have value 1. Subsequently, all users with the same differentiation value will see only their group's records.

Application lifecycle¶

Collaboration¶

Applications support a collaboration model where multiple Portal users can manage the same application. The application owner shares it on the Sharing tab, by entering the email address of another Portal user's account (in any letter case; an address that no account uses is refused, so the person signs up first). A human collaborator can do everything the owner can, even delete the application, except sharing it. You can also share an application with an agent: an account for a script or an AI agent, created by an administrator under Instance > Agents. Choose Share with agent and select its name; the dialog also shows its access to other applications you can see. An agent calls the Portal's management API with a key and starts read-only. The owner chooses its read, write and deletion rights for each area when sharing, or through Edit rights later. Rebuilding requires a separate grant; deleting the application and sharing remain unavailable to agents. Agents also cannot rename entities or properties, change the connection string or change mail settings, regardless of their grants. Email settings support Read only; older email-write grants are retired without removing other grants. Custom endpoint renames keep their existing permissions. No email is sent to an agent. See AI Agent Guidelines for the Portal for discovery and permission details.