Member-facing Compatibility API

The compatibility API is the older /api HTTP surface in agapi-member-booking. It keeps established member journeys working while some features are also being provided by Symfony.

This page describes the server behavior. It does not describe the excluded legacy web frontend or claim that current native apps present the same screens.

Sign-in and account access

The first job of the API is to identify the caller and stop deactivated accounts from using protected member data.

Most routes require a token in the Authorization: Bearer ... header. Older callers can also send it as a jwt parameter. Login, password-recovery, app- version, and selected public map/service routes are allowed before normal token validation.

After token validation, the API also checks that the member or staff account is still active. A valid old token must not keep a deactivated account working.

Finding the service and fleet

Before a member can plan a trip, the client needs the current operating choices:

• regions and locations show where the service operates;
• country and company data explain the member's service context;
• categories, boat types, and boat records describe what can be booked;
• resource detail supplies information for one boat;
• location maps provide a visual collection point and nearby markers;
• tutorials, academy links, videos, and phone contacts provide operating and support information.

These are not independent catalogues. A boat belongs to a type and place, and a place belongs to a region/company context. Filters should keep those relationships consistent.

Availability and prices

Availability answers whether a suitable boat can be offered for a requested period. The API provides calendar data, available intervals, available boats, and booking-specific time-change checks.

Price endpoints estimate a booking or time change and can return fuel price information. The result depends on the caller, dates, place, boat/type, company, currency, and current pricing configuration. A displayed estimate does not by itself create a booking or collect money.

Bookings and requests

The API supports both confirmed bookings and requests that still need staff attention.

Confirmed booking

A member can list bookings, open one trip, page through past or upcoming trips, create a booking where allowed, and request supported changes or cancellation. The server also provides a cancellation check so the client can show the effect before the member confirms.

Changing time and calculating the new time price are separate operations. This allows the client to explain the new result before saving it.

Booking request

A request records desired dates, place, and boat/type when the trip is not yet fully assigned. The member can create it, list it, inspect it, check dates, or cancel it. Staff later solve or reject it through operational tools.

The request is not a promised boat. Only a confirmed booking should be treated as one.

Check-in and check-out

Check-in records the start of custody. Check-out records the return of the boat and the member's final trip information.

The compatibility API supplies the question sets and accepts the completed answers. Depending on the stage, those answers can include:

• fuel and engine-hour readings;
• boat condition and mooring checks;
• photos and newly reported issues;
• facilities used;
• refuelling information and receipt evidence;
• member experience and condition ratings;
• comments and confirmation items.

flowchart LR
    A[Confirmed booking] --> B[Read check-in questions]
    B --> C[Record starting condition and values]
    C --> D[Boat in use]
    D --> E[Read check-out questions]
    E --> F[Record ending values, issues, and feedback]
    F --> G[Update booking and start follow-up work]

Photos are uploaded separately and then referenced by the trip or issue. If an upload succeeds but the final save fails, the file can exist without being attached to the intended record.

Fuel, engine hours, and payment

Member profile routes show fuel, engine-hour, and cash-point transactions. Trip routes can add recorded fuel use, engine use, and related values.

The compatibility service also supports payment-intent creation, saved payment methods, charging a selected method, fuel payment confirmation, fuel invoice creation/cancellation, and subscription actions through the real-time layer.

These steps are separate for safety. A fuel reading, a calculated amount, a provider charge, and a local invoice state can disagree after a partial failure. Compare all four before retrying a payment.

Notifications and support content

The API can return recent notifications and unread counts, mark notifications as read, register a device token, and expose push-report or push-send compatibility routes. Some of these routes forward to another service rather than implementing the whole action locally.

Tutorial, video, phone, map, and manager-contact routes help the member get practical information around a trip. Video streaming supports range requests, and thumbnail generation is a separate media operation.

Route groups for developers

The exact method, parameters, and response shape must be taken from agapi/api/index.php and its traits. Several paths proxy to Symfony or call the real-time RPC service, so follow the concrete handler before changing behavior.