FAQs

The app is a business logic layer built on top of the APIs to solve a single problem or provide a limited scope of functionality. For example, User App includes functionalities such as onboarding or offboarding a user. An App could be of three types - Web, Mobile, and Backend.

Creating or registering an app is one and the same. A developer registers an app using the developer portal, which in return provides credentials such as client id, and client secret for making OS1 platform API calls. Once the app is registered, we assign it a unique identifier that is then used through its lifecycle to manage its metadata, subscription, AAA permissions, solution inclusion, etc.

A solution is a collection of compatible apps that solve an end-to-end business workflow. For example, a delivery management solution will include all apps such as dispatch, order management, routing, facility management, user management, etc required to manage last-mile deliveries.

The main attributes of a solution are below (not an exhaustive list). List of app ids along with display order and default app to open when the user logs in.The sequence of initialization of apps when the solution is onboarded.Solution’s name, description, category, icons, etc

We recommend that you use the Console in the web apps that you want to publish in the marketplace. By using the Console libraries, you can make your web apps accessible from one single place for the end customers. Otherwise, you will have to distribute your web app URLs individually to the end customers which will result in friction and inefficiencies for the discoverability of your web app.

At a high level, any entity that directly participates in the logistics process should be built on top of Participant Service (eg. users, facilities, vehicles, clients, warehouses, etc). For all other general database applications that require a readily available Data object and CRUD APIs Entity Service should be used.

No, we follow OAuth 2.0.

Yes, in order to be approved for production, all apps have to be multi-tenant. This also means if you are hosting with us max one instance of the deployment of a particular app will be allowed in one stack.

Stack is set out infra resources such as storage, networking, and computing on which we can create one or more tenants. Tenant enables storing of all customer's data in an isolated manner from one another. On OS1 we offer shared tenancy and dedicated tenancy model. In the shared tenancy model data is isolated but computing and networking are shared. In the dedicated tenancy offering there is only one customer in a particular stack by virtue of which the entire compute, storage, and networking resources are dedicated to a customer.

Core APIs by design are business agnostic and do not implement any business logic. These APIs provide basic building blocks to manage data and workflows. Framework APIs extend the Core APIs and bring in the business context to provide solutions for industry use cases.

Yes, in order to receive the production API keys your app will need to be approved by the OS1 product operations team.

Yes, in order for an app or a solution to be published, it needs to complete a detailed technical review. The review is done by the OS1 platform operations team after the app or solution is submitted for review.

Yes, you can build apps and solutions for your internal business operations team's usage and decide not to publish in the Marketplace.

Please use the contact us form here https://portal.getos1.com/#/contact-us to reach out to us. You could submit a query, a new feature request, or an issue using this form.

We store our logs in S3, which are then populated into Coralogix for analysis and troubleshooting purposes.

In Coralogix, we have an S3 bucket set only for logs/metrics. We have varying retention periods based on the environment:

Non-Prod Environment (Sandbox, QA, and Staging)

Prod Environment (Sl-Shared, Dlv-India)