FleetSuite’s logic.
Your application.

Build the experience.
Define the boundary.

Your application owns the interface and the journey through it. Keep business operations and their rules with FleetSuite, accessed through versioned contracts. A custom screen should not have to invent a second answer to whether a vehicle is available or a booking exists.

Decide which information belongs in the interface, which belongs in your application server and which must remain authoritative in the platform. Use the documented operations and permissions for the records your application needs, across hire, sales, maintenance, financial reporting, pricing and predictions.

Start with one useful workflow.

Explore application examples to shape the experience, then use platform capabilities to identify the FleetSuite information and actions it needs.

A good integration brief describes an outcome, not a list of endpoints. For a rental operator, that might be “a customer can find an appropriate van, understand the full price and request a booking that the team can fulfil”. For an internal application, it might be a focused view of work and vehicle status.

1. Identify the people. Separate visitors, customers, staff and administrators. Write down what each may see and change.
2. Name the business records. Identify the vehicle or class, dates, quote, booking and customer information needed for the workflow. Keep personal data to the minimum necessary.
3. Define ownership. Agree which system creates each record and which may update it. Decide how existing staff workflows will see changes.
4. Specify a successful outcome. For each step, define the authoritative result and what the user sees while the result is pending or unknown.
5. Capture constraints. Record collection rules, turnaround time, opening hours, vehicle restrictions and other conditions that affect the result.

That brief exposes questions about allocation, quote validity and booking states before anyone commits to a contract. Use synthetic records and fictional customers while exploring it.

Map the first rental journey.

Explore how FleetSuite contributes at each stage, from customer requirements to the connected hire operation, on the rental booking API page.

Use the API contract to confirm each operation and its behaviour before implementation.

Availability

Capture dates, times, location and vehicle requirements. Ask whether results represent individual vehicles, a class or a capacity pool. Establish the time zone, turnaround rules and how maintenance or operational blocks affect results. A search result should not be presented as a reservation unless the contract explicitly gives it that meaning.

Quote

Agree what the price includes, how long it remains valid and which changes require a new quote. The interface should make optional items and any separate deposit clear. A price calculated in the browser is not a substitute for the agreed authoritative pricing operation.

Booking

Confirm what creates a booking, when capacity is reserved and which state the customer may treat as confirmation. A timeout is an unknown result, not proof that nothing happened. Establish a supported recovery method before adding automatic retries.

Result and recovery

Plan the customer confirmation and the staff view together. Record how to recover a lost response, reconcile an incomplete attempt and handle amendments or cancellations. Payment operations require separately confirmed scope and responsibilities.

Design for the awkward cases.

An attractive successful flow is only part of the integration. Put these scenarios into the acceptance brief, then implement and test them against the contract for your integration.

• Two customers attempt to reserve the last eligible vehicle at the same time.
• A price or availability result changes before the customer confirms.
• The customer presses the button twice, or the connection drops after a write.
• A member of staff loses permission or tries to access another business’s records.
• A dependent service is unavailable, delayed or returns a result out of order.
• The user abandons the journey with an unfinished booking or payment attempt.

Agree error meanings, retry rules, idempotency support and reconciliation responsibilities. Keep privileged credentials out of browser code, public repositories and AI prompts. Confirm authentication, permissions and tenant isolation from approved documentation rather than copying assumptions from a prototype.

One contract. Shared reference.

Use the shared OpenAPI contract as the source for your integration and its Swagger reference. Reference pages, types and executable examples should follow that same version so the website does not develop a separate definition of the API.

Check the operation coverage, permissions and contract version for your integration. Build against that agreed contract so the application and platform handle the same records and rules.

Use this guide to define the workflow and acceptance criteria. Keep API examples, client types and implementation instructions aligned with the contract version you use.

Bring a plan we can evaluate.

Share the intended users, workflow, frontend approach and business services you need. Include a short list of failure scenarios and explain who will own ongoing application support. There is no need to send a full technical specification, credentials or customer data.

• Scope: the smallest end-to-end journey that would create value.
• Contract: the operations and access needed, with unresolved questions explicit.
• Evidence: synthetic success, conflict, recovery and permission tests.
• Operation: support ownership, monitoring, version changes and release criteria.

Agree the integration scope, support responsibilities and commercial arrangements for your project.