A comprehensive guideline on how to submit an application to Ebriza
In order for you to add an application to Ebriza, you must submit the following details.
Application logo (required):
We strongly recommend submitting a square SVG with at least 150x150px size.
We recommend submitting square screenshots that are at least 500x500px size.
We accept any image file type (.jpg, .jpeg, .png, etc.)
If your application requires a local windows service installed or requires any additional executable, you can upload it here. The file will be available for download on the installed application page and it will be hosted on our side. If you want to explain to the user what should he do with this installer, you can use the Extra Information text area described below at the Application Configuration section.
Application name (required):
Internal name visible only by you and Ebriza's staff. This label serves as a loose identifier and it is not used for querying or identifying your application.
Application type (required):
Current supported application types are Global and Location.Global applications are installed once for a company and are available to all of the company's locations. This implies that we will provide only one identifier for a particular client.
The identifier mapping is one ebriza-clientid to one company.
Location based applications are installed multiple times for a company. This implies that we will provide multiple identifiers for a particular client, each of them mapped to a location. From your perspective a different location of the same company is a different client / user.
The identifier mapping is one ebriza-clientid to one location.
API claims (required):
The API claims serve as a security and data protection mechanism that limits your access only to the data under a specific claim.
Based on what API claims you select we will prompt the user during the application installation to agree that you have access to that specific data and also install any possible dependencies.
Example: Let's suppose you require access to the client's stocks. The client needs to have the Stock Management application installed before you can query our API. This means that the Stock Management application is a dependency to your application and needs to be installed first.
Represents the price of the application and is express in RON (Romanian New Leu). This is how much we will charge the client at the end of a billing cycle.
Price type (required):
You have multiple choices on how you want the application to be charged.
Free - The client won't be charged at all.
Monthly - We will charge a fixed amount each month regardless of the application usage. (Only applies when the application is installed)
Transaction - We will charge a fixed amount for each transaction. A transaction iswhenever you submit an Order through the Ebriza's API. If you require an additional type of transaction please contact us.
Transaction Percent - We will charge a percentage of the total transaction sum for each transaction
All client facing labels and resources should be translated in all the supported languages. This includes the application name, description, installation steps titles and descriptions, configuration fields labels and descriptions, possible configuration fields options values.
Represents the application name that we will display on all the client facing screens and views.
A general description of the application. Should contain at least basic information of what the application does and what are the benefits of using it. We will display it on the application details in Ebriza Marketplace.
During application installation we will show whatever steps you define here.
Possible installation step types are Description and Login Link.Description - You do not require any action or confirmation from the user. Should contain whatever steps the user must do in order for your application to function properly. (Example: Install a WordPress plugin manually)
Login Link - You will provide a login link that the user will use to authenticate in your system. After the user successfully authenticates in your system we will continue with our internal installation flow. It is in your responsibility to notify us when the authentication succeeds. More information can be found here.
Installation step name (required):
Internal identifier of the step, visible only by you and Ebriza's staff.
Installation step title (required):
The title of the installation step. Example: "Login on YourApp"
Installation step description (required):
A short description of the step. Example: "In order for you to successfullly install YourApp you must first download Excel."
Installation step Login Link (required *):
*Required only if the installation step type is Login Link.
The URL that will get opened in a new tab during the application installation.
Note: Only submit this field at the step you want it to be visible!
We provide you the ability to let the client customize the interaction with your application. You will need to provide possible configuration fields that the client can modify. We will make an API call towards you with the new values after the client saves the configuration in our system.
Example: You might have a functionality that sends emails to the client when an event happened. You want to give the option for the client to opt in or out of this feature through Ebriza. You will have to define a Boolean configuration field like Receive Email and whenever the client modifies it we will notify you. More information can be found here.
POST Url (required):
The URL where you want to be notified when the user changes a configurable field.
Note: this must be a public API. More information can be found here.
In this field you can add free html text that will be displayed on the installed app page once the user installs your application. You can use this text-area to add a short tutorial or steps (if needed) that the user has to do in order for the integration to work. For example, if your application requires an installer, you might explain how the user should use the installer.
Configuration field name (required):
Internal identifier of the configuration field, visible only by you and Ebriza's staff.
Configuration field label (required):
Represents the label of the configuration field.
Configuration field description (required):
A short description of the configuration field.
Configuration field type (required):
Possible configuration field types are:
Boolean - Value: true / false. Display type: checkbox
String - Value: unsanitized string . Display type: input
Date - Value: date in "YYYY-MM-DDTHH:MM:SSZ" format (ISO 8601). Display type: date-picker
Select - Value: selected option ID. Display type: drop-down
Configuration field select multi-select (required):
You can control if you want the user to select multiple options or just one. The difference in the API call that we make is that if the select has multiple options we will send the options IDs in an array.
Configuration field select type (required *):
*Required only if the configuration field type is Select.If the configuration field type is Select you can choose a pre-existing select like the client's users, locations, rooms or you can define your own. Possible select types are:
Users - We will show a dropdown with all the client's users.
Rooms - We will show a dropdown with all the client's rooms.
Location - We will show a dropdown with all the client's clients.
Custom - You will have to define the select options.
Configuration field select custom option ID (required *):
*Required only if the configuration field type is Select and select type is Custom.Represents the option identifier. We will send this value to you through the API call at the POST Url.
Configuration field select custom option value (required *):
*Required only if the configuration field type is Select and select type is Custom.Represents the option display value inside the dropdown. It is mapped 1 to 1 to the option ID.
During our internal review process we would like to manually test the integration with your app. You will need to provide any possible testing information that you can think of. We do not require a particular structure for this information, however one might expect a username and password for a staging environment, possible configuration keys, etc.