Yacht charter API integration: a data checklist for brokerages

Write down what the integration will do. A public website, a professional broker desk and a client-specific proposal are different distribution contexts.

Define the fields each audience needs and which must remain private. A feed that supports professional sourcing does not necessarily permit publishing all representative contact details to anonymous visitors. Nor does access to a yacht database grant ownership of its photographs or brochures.

Ask the provider to confirm the approved channel, media permissions and any caching or deletion requirements. Do this before selecting a layout that depends on restricted material.

Names are useful display labels. They are weak database keys. Two yachts may share a name, and the same yacht can appear under a changed name or with a revised marketing description.

Keep the provider's stable yacht identifier alongside your local reference. Treat a change in display name as an update to investigate, not an automatic new vessel. Keep source timestamps and provenance with the record so a broker can understand the information's origin.

Separate identity from changeable claims. A yacht's length and the rate applicable to a particular season should not be flattened into one undifferentiated text field.

Decide how the consuming interface will display null or absent fields. Missing guest capacity is not zero guests. An absent amenity is not evidence that the yacht lacks it. An unspecified refit year must not become the current year.

Use a field-mapping worksheet before launch. Test incomplete records deliberately. A page that looks accurate only when every field exists is not ready for a real catalogue.

A published weekly rate is not an all-in charter quote. Keep its currency and applicable period visible. Do not silently mix a daily offer with a weekly figure or select a rate from another season because it produces a lower headline price.

Record which components still need professional confirmation, including tax, APA, delivery and compulsory extras. If currency conversion is offered by the consuming product, label it as such and retain the source currency. Do not imply that the provider guarantees the conversion or the final contract figure.

The current Broker API exposes a weekly rate range, or null when no weekly rate is stored. It does not return a daily rate or an all-in quote. When the stored record has no currency, the response uses EUR. Treat that EUR as a platform default, not as evidence that the source quoted euros.

For the client-facing budgeting process, link the integration team to the working-budget guide rather than embedding an incomplete pricing assumption in the feed mapping.

An API response should not be treated as a contractual promise merely because it is recent. The current Private Charter Broker API yacht resource sets availability_status to confirmation_required on every published yacht. That value means the feed does not include a deal-specific confirmation. Do not render it as available.

The broker desk keeps a separate request record. Its workflow can show requested, held, confirmed, declined and expired against a specific enquiry. The published yacht feed does not return that request history, so a consuming product must not invent those states from a catalogue response. Where a hold exists in the desk workflow, it still needs its time-bound context. A previously cached catalogue record can still require a fresh professional check before a proposal.

The availability guide explains why the request and its commercial scope matter. This integration checklist deals with keeping the feed's actual meaning intact in another system.

Private Charter documents organisation-scoped bearer credentials for its read-only Broker API. Credentials belong in a managed server secret, not browser JavaScript, a public repository, a mobile bundle or analytics.

Give access only to the integration service that needs it. Plan rotation and a response to suspected exposure before going live. Logs should help diagnose a request without recording secrets or private client material.

Follow the documented failure semantics. Stop and investigate invalid credentials. Do not bypass a permission refusal by trying another account or exposing a different channel. Use bounded retries for temporary failures, and respect Retry-After when the account is rate limited.

The current API documentation is the authority for request examples and account-specific limits. This article does not assert a fixed request quota or cache period.

A first import is not the whole integration. Agree on what happens when a yacht is no longer visible, an image loses distribution permission or a record cannot be refreshed.

Use the provider's returned cursor for pagination where documented. Do not assume page numbering or infer that the first collection response contains the entire permitted inventory. The current Broker API collection returns published yachts only. A yacht that is no longer published is absent from a later response; the feed does not send a separate withdrawal event.

Check both the stored record and the page a broker or client sees. A technically successful import can still produce a misleading commercial statement. A useful acceptance test includes the cases below.

Validate a small approved working set before expanding the integration. Have the broker review the meaning of the displayed information, not just whether the cards look attractive. Have the developer demonstrate refresh, withdrawal, access control and error handling.

Private Charter's Broker API product page describes its separate paid subscription. API keys are not included in the broker trial or central-agent offer. Platform access also does not replace a source's distribution restrictions.

The aim is a dependable professional workflow: less repetitive copying, with the origin, limits and commercial context of the information still visible.