Skip to content

API

The Flowtig API is the backbone of the platform.

Every interaction — whether from the web interface, a macOS client, or an internal worker — is executed through structured API boundaries.

There is no privileged frontend. There is no hidden access layer. The API is the system.

API-First by Design

Flowtig is built around a strict API-first architecture.

  • The React web frontend consumes the API.
  • Native macOS applications consume the API.
  • Background services consume the API.
  • Future clients will consume the API.

All business logic lives in the backend. Clients are replaceable. The core is not.

Clear Separation of Responsibilities

Flowtig uses two complementary API styles — each with a distinct role.

GraphQL — Service Domain Layer

GraphQL handles domain-specific service data.

All tenant-scoped service applications (Worktime, Invoices, Construction Log, etc.) operate through GraphQL.

GraphQL is responsible for:

  • Structured domain data
  • Strong typing
  • Precise data selection
  • Service-specific mutations
  • Client database isolation

If you are working inside a Flowtig service, you are working with GraphQL.

👉 See: GraphQL API

REST — System & Meta Layer

REST is used for system-level and meta operations.

This includes:

  • Client / organisation management
  • Authentication workflows
  • Subscription and billing operations
  • Cross-service administration
  • File distribution and update feeds

REST endpoints manage platform-level concerns that are not tied to a single service database.

If you are managing tenants or interacting with the core system layer, you are using REST.

👉 See: REST API

Tenant Isolation

Every request is evaluated within a strict organisational context.

The API enforces:

  • Database isolation per client
  • Membership-based access control
  • Service-scoped permissions
  • Token-based authentication

No service may access data outside its tenant boundary.

Isolation is structural — not optional.

Designed for Multi-Client Systems

Because business logic is centralized:

  • The web UI is only one client.
  • Native macOS apps operate independently.
  • Future mobile or CLI clients require no architectural changes.

Flowtig scales by extending the API — not by coupling new interfaces.

For Developers

If you are exploring Flowtig as a developer — welcome.

Whether you are:

  • Building a new service
  • Extending an existing application
  • Creating a native client
  • Automating workflows
  • Or simply evaluating the architecture

The API is your entry point.

Flowtig follows a clear structure:

  • Service domain logic → GraphQL
  • Platform & system logic → REST

This separation keeps the system predictable and scalable.

You don’t need to work around the platform. You build against it.

The contracts are explicit. The boundaries are intentional. The architecture is designed to support multiple clients and long-term evolution.

You are invited to explore the schemas and the tenant model. They form the foundation on which every Flowtig client and service is built.