How the Agapi Platform Works

A plain-language guide to the complete booking, fleet, membership, payment, and communication system.

Agapi helps a membership business share a fleet of boats. The platform must make sure that the right member can book the right boat, use it safely, report its condition, and pay the correct company. Staff need the same information to plan the fleet, help members, repair boats, and explain financial results.

The complete service journey

flowchart LR
    A[Member account] --> B[Find place and boat]
    B --> C[Request or confirm booking]
    C --> D[Prepare and check in]
    D --> E[Use the boat]
    E --> F[Check out and report condition]
    F --> G[Update balances and charges]
    G --> H[Messages, service work, and reports]

Every major feature supports part of this journey:

Area	Why it exists
Members	Decide who may use the service and keep their entitlement, contact, and payment history together.
Fleet	Describe each physical boat, where it belongs, whether it is available, and what condition it is in.
Bookings	Reserve a specific boat for a member without creating time conflicts.
Booking requests	Keep demand visible when the final boat has not yet been assigned.
Check-in and check-out	Record that custody changed and capture fuel, engine, condition, photos, and comments around the trip.
Maintenance	Turn reported problems into a usable history of issues and service visits.
Pricing and payments	Explain what should be charged, apply the right company and tax, and track the result in Stripe.
Messages	Tell affected members about bookings, service, or other important events.
Reports	Help staff understand use, problems, balances, and payments from saved operational records.

Why the system is split between two repositories

The split is historical and practical. The business still uses an established admin web application and compatibility services while more responsibilities also live in a Symfony API.

Repository	Its business role today
`agapi-member-booking`	Provides the staff web portal, compatibility HTTP API, real-time request service, uploads, and several long-running or scheduled jobs.
`api`	Provides the newer admin and member-facing API, shared business records, payment and notification services, reports, and external integrations.

The two repositories use the same business concepts and can access the same PostgreSQL data, but one user action does not always stay inside one repository. For example, an admin button can begin in the older web portal and finish in a Symfony endpoint.

flowchart TD
    Staff[Staff member] --> Admin[Admin web portal]
    Admin --> Compat[Compatibility HTTP and real-time services]
    Admin --> SymfonyAdmin[Symfony admin API]
    Member[Current member client] --> Compat
    Member --> SymfonyMember[Symfony member API]
    Compat --> Data[(Agapi business data)]
    SymfonyAdmin --> Data
    SymfonyMember --> Data
    SymfonyAdmin --> Providers[Stripe, messages, files, and fleet monitoring]
    Compat --> Providers

This is why the documentation describes a feature from the user's goal first, then names the system that performs each step. It does not pretend that one “central engine” owns everything.

The most important boundaries

Company and account

Agapi operates for more than one company/account. This context controls which members and boats an operator can see and which payment, currency, and tax configuration is used. It must travel with business records and financial actions.

Confirmed booking and request

A confirmed booking promises a particular boat for a period. A request records demand that still needs a decision. Converting a request into a booking is a real operational action, not just a status rename.

Issue and service visit

An issue describes a problem. A service visit describes when operational work or inspection took place. They are connected, but neither automatically proves the other is complete.

Local record and external provider

Stripe, mail, SMS, push, and fleet monitoring are separate systems. A local request can succeed while a later provider update is still pending or failed. Staff must compare both sides before repeating a financial or communication action.

Where to start

Admin Portal explains what staff do and why each screen exists.
Admin Web and Compatibility Services explains the current responsibilities of agapi-member-booking outside the excluded legacy mobile frontend.
Symfony Backend explains the business services provided by the api repository.
Developer and Operations Guide explains how to run, test, and deploy the two codebases.

Scope of this guide

The native iOS and Android client source is not present in these repositories, so this guide describes the server features those clients can use, not their screen design. The old web frontend under agapi/mobile is legacy and is not analysed. Its archive page exists only to prevent readers from mistaking it for the current product.

On this page