API Overview
One platform. Two APIs. Clear responsibilities.
The Flowtig API is the foundation of the entire platform.
Every Flowtig client — whether it's the web application, a native macOS app or a background service — communicates through the same public API layer. Business logic lives in the backend, ensuring consistent behaviour across every client.
Flowtig follows an API-first approach, making the API the primary interface to the platform rather than an implementation detail.
API-first architecture
Every Flowtig application communicates through the same APIs.
There are no privileged clients, hidden endpoints or frontend-specific business logic.
Why two APIs?
Flowtig separates business functionality from platform functionality.
This results in two complementary APIs, each with a clearly defined responsibility.
| API | Purpose |
|---|---|
| GraphQL | Business applications and domain data |
| REST | Platform services and system operations |
This separation keeps the platform predictable, scalable and easy to maintain.
GraphQL
GraphQL is the primary API for Flowtig applications.
Every business application communicates through GraphQL, including:
- Contacts
- Worktime
- Time Tracking
- Invoices
- Warehouse
- Construction Log
- and many more.
GraphQL is responsible for:
- Business data
- Queries
- Mutations
- Strong typing
- Tenant-specific data
- Precise field selection
If you're developing a Flowtig application, GraphQL will be your primary interface.
→ Continue with the GraphQL documentation.
REST
REST is used for platform-level functionality.
Typical examples include:
- Authentication
- Organisation management
- Subscription management
- Billing
- System administration
- File distribution
- Update feeds
REST endpoints manage functionality that belongs to the platform itself rather than to an individual business application.
→ Continue with the REST documentation.
Tenant-Aware by Design
Every API request is executed within the context of a single organisation.
Flowtig automatically enforces:
- Tenant isolation
- Role-based permissions
- Membership validation
- Service permissions
- Token-based authentication
Applications never access data outside their assigned organisational context.
Learn more in the Architecture documentation.
Multi-Client Architecture
Flowtig is designed to support multiple clients without changing business logic.
Current clients include:
- Web application
- Native macOS applications
- Background workers
Additional clients such as mobile applications or command-line tools can be introduced without requiring architectural changes.
Design Principles
The Flowtig API follows a number of fundamental principles.
API First
Every feature is implemented through the API before it is consumed by a client.
Clear Responsibilities
Business functionality belongs in GraphQL.
Platform functionality belongs in REST.
Strong Contracts
APIs provide stable and predictable interfaces for all clients.
Tenant Isolation
Every request is evaluated within its organisational context.
Long-Term Evolution
New applications can be added without changing the platform architecture.
Where to Go Next
Depending on what you're building, the following guides are a good starting point.
| I want to... | Start here |
|---|---|
| Build a Flowtig application | GraphQL |
| Integrate with the platform | REST |
| Understand the platform | Architecture |
| Explore existing applications | Applications |
Need help?
Looking for additional information?
- Explore the Architecture documentation.
- Browse the available Applications.
- Contact us via https://flowtig.com/contact if you have questions about the platform.