APIs for all usages: internal, customers and partners, public.
Expand your organization to new usages and new customers with Public APIs.
As part of commercial partnerships, whether with customers or providers, APIs are the standard exchange format.
APIs are also meant to be used internally inside the organization.
Using an API must be simple and fast.
Using APIs should be as simple as possible. Think about the developer experience.
The best solution to validate adequacy with the need is to test the API quickly: a few minutes must be enough!
The platform must offer a graphical interface to test the API in a simple manner.
APIs usage must be controlled and understood.
Implement an API Management solution to manage quotas, throttling, authentication, and logging.
Collect metrics to manage monitoring, filtering, and reporting.
Set requirements for external systems and services integrated into the platform.
Require external systems to meet the same requirements as internal systems.
External systems must publish events and allow technical monitoring.
In the case where the external systems data must be integrated, total synchronization have to be possible.
The architecture must be designed as multi-tenant.
Even if white labelling is not considered at the beginning, set up a multi-tenant architecture. Your initial application is the first tenant.
Think of the functional multi-instantiation of the system right from the start.
Systems must be natively configurable.
Languages, currencies, business rules, security profiles must be simple to configure.
Beware of hyper-genericity, it is often useless and costly.
The configuration must be scalable and fast depending on needs.
Create flexible and generic systems using feature flipping.
Feature flipping is about designing an app as a set of features that can be enabled or disabled live, in production.
In a multi-tenant application, feature flipping allows you to customize by tenant.
Feature flipping simplifies A/B testing.