🔗 Structure

This section generally explains how the structure works and what should be used in the interface. For code details, please refer to the API section.

Terms and definitions used throughout the document.

To use this structure, Developer Mode must be enabled. Visit the Profile page to enable it.

Once this mode is enabled, a Projects page will be added to the Home Page menu.

A developer may have multiple applications. The Projects page helps distinguish between these applications and organize each automation.

When creating a project, you need to provide a mandatory name and a webhook URL. As shown in the image above, each project is displayed as a card featuring its logo, name, and creation date.

In the API Tokens section, you can create tokens necessary for automation and other requests within this project.

In the Integrations section, register each application used in the project's automations. For OAuth applications, an additional form will be displayed, while other applications can be added directly.

The Danger Zone section includes the option to delete the project. Deleting the project will also remove all associated integrations, automations, tokens, external users, and connection records.

This tab is essentially a replica of the Automations page but with some differences. It displays the project title and tabs, and the Run button is hidden since these automations cannot be triggered manually. Additionally, clicking the Publish button does not automatically subscribe the automation to triggers.

The developer can run the automation in the editor interface for testing purposes. However, for the automation to run in the background, it must be triggered by the end user. For manually triggered automations, the user must initiate the request, and for automations with other types of triggers, the corresponding request must be made.

Left Section: Three statistics are displayed on the left side:

• Users: Shows the number of End User records registered to the project.

• Registrations: Indicates whether any application triggers have been subscribed to from the project's automations and displays the number of subscribed triggers.

• Used Daily Credits: Displays the number of credits used that day for the project's automations.

Right Section: A table showing the last 5 execution records.

Connected Users: You can export the information of users who have connected their accounts to OAuth-using components in the automations as a CSV file.

Developer Account Testing: When a developer tests a component in the editor, they connect their own account. However, when running the automation, the end user may need to connect their own account. This is indicated by a button in the interface.

Option to Replace End User's Connection: The Replace end user's connection option, as shown in the image, determines whether the connection added by the developer can be used by the end user.

Default Setting: This option is selected by default, meaning the end user needs to have a valid connection to run the component.

Example Scenarios:

Option Active: In an automation for creating tasks in Cubicl, the task creator is the person who runs the component. Thus, the task owner changes based on who runs the component.

Option Inactive: In an automation for sending messages via Twilio, a common phone number is used for sending messages. This means the phone number does not change based on the user. Therefore, regardless of who runs the component, it always uses the developer's account.