create_client
ChatGPTCreate a new client record. Search first with search_clients to avoid duplicates. Returns the new client id — pass it as
clientId when creating a proposal for them.By BRIGHTON BENEDICT MBOYA
Ratiba helps safari operators and travel teams manage proposal workflows in ChatGPT. The app can find and create clients, search accommodations and destination imagery, create and update itinerary proposals, inspect proposal details and pricing, and translate proposal content for client delivery.
clientId when creating a proposal for them.destination. Only for a genuine gap: search_destinations first, since a near-match there is almost always the right answer and a duplicate entry splits a destination's photo library and park fees across two records. Coordinates are required — look them up with search_places — because a destination without them cannot be drawn on the map. A place whose name already exists returns the existing id instead of creating a second one.useAutoPricing: true, call get_pricing_options and select the applicable vehicleId, vehicleCount, guideId, pickup/drop-off transfer-rate ids, and markupPct; omit markupPct only when the organization's displayed default/tier should apply. Pass a YYYY-MM-DD startDate for real seasonal rates. The result includes pricingReady and pricingIssues; never call an auto-priced quote send-ready while pricingReady is false. Returns canonical shareUrl/editUrl; never construct them. Call get_proposal afterward to verify persisted client, itinerary, pricing, imagery, and theme. Translate only after the content is final.useAutoPricing: true), also includes a freshly-computed pricingSummary (cost by category, markup, sell total), plus pricingReady and actionable pricingIssues.accommodation on a proposal day. Search by name, or filter by country (accommodations have no destination/park field, only a country and coordinates — use judgment, or cross-check latitude/longitude against the day's destination, when narrowing beyond country). Always search before guessing an id.clientId on create_proposal/update_proposal.destination. That id is what puts the day on the client-facing map, and for a fee-bearing park it is also what applies park fees under useAutoPricing, so look the destination up here rather than relying on the written destinationName — beware near-namesakes such as "Arusha City" and "Arusha National Park", which are different places with different fees. Results without coordinates cannot be drawn on the map. An empty query returns a sample of the catalog.destinationImages), accommodation names (returning that lodge's photos in accommodationImages), and this organization's own uploaded image library (matched by name/caption, returned in organizationImages). Every national park already has a curated library — call this once per distinct destinationName in the itinerary (e.g. once for "Serengeti", once for "Tarangire", once for "Arusha"), then set each day's previewImage from that day's own destination's destinationImages, and pick the proposal's heroImage from the primary/opening destination's destinationImages. Always use this instead of inventing an image URL — check the organization's own library first, since those are often Makisala-branded or trip-specific photos not tied to any single destination/lodge.startCity/endCity pins (pass the chosen result's name as startCity and its latitude/longitude as startCityLat/startCityLng), and the coordinates create_destination needs for a place the catalog is missing. Check search_destinations first — a place already in the catalog should be referenced by its id, not re-geocoded. Results are ranked by proximity to countries but not restricted to them, so read displayName before choosing.days is supplied it replaces the itinerary. Auto-pricing selectors can be changed or cleared using ids from get_pricing_options. The result includes pricingReady and pricingIssues. Editing translatable content on a translated proposal switches it back to English so stale translated copy is never served; run translate_proposal again afterward.