AFerry

Search AFerry for one-way or return ferry sailings on any crossing AFerry sells, returning matching sailings plus a deep link to the AFerry search results page where the buyer can pick and book one. Call this whenever a buyer asks to find or book a ferry crossing, wherever in the world it is. Origin and destination are free text and are resolved to a route by AFerry, so there is no port code to look up and no list of served places to check against first — pass on whatever the buyer named. If AFerry doesn't sell the crossing they asked for, the result comes back failed saying so, which is the answer to give them; don't rule a crossing out yourself before searching. Apply common sense to what the buyer has given you before calling. Origin and destination should each name a single port or city that a ferry sails between. If either doesn't — a country or a region rather than a port, one place where the journey needs two, several places at once, or nothing recognisable as a place — ask the buyer which ports they mean rather than guessing or passing it straight through. That is a different question from whether AFerry sells the crossing: two plausible port names always go through to the search, and the search itself answers that. A standard car can travel with the buyer, and no dimensions are needed for one. A cat or a dog can travel too. These are not supported yet, so don't call this for them: any pet other than a cat or a dog, and any vehicle other than a standard car — a van, motorhome, minibus, bicycle, motorcycle, trailer or caravan, or freight. Before the first call for a new search, stop and confirm the resolved request details with the buyer in a single summary message, then wait for them to confirm before calling — do not silently assume or default origin or destination. The date may be defaulted (e.g. today) if the buyer didn't specify it, as long as the confirmation summary states what will be used. Cover origin, destination, whether it is one-way or a return, the date and time of departure (and of the return, for a return), the party travelling broken down by type, how they are travelling, the market being searched, the currency that will be used, and that alternative routes will be included. Give the market as its language and country in words followed by the locale in brackets — "French (fr-fr)", "British English (en-gb)", "Swiss German (de-ch)" — so a buyer who was searched for the wrong one can see it and say so. E.g. "Searching one-way sailings from Marseille to Tunis on 1 September 2026, departing around 9am, for 1 adult and 1 child aged 8 with a standard car and no pets. Market French (fr-fr), prices in EUR, alternative routes included — shall I go ahead?" Work locale out yourself rather than asking the buyer which market they want. It decides the language the sailings come back in, the currency they are priced in, and which country's site the deep link opens. Start from the language the conversation is being held in — held in French, search fr-FR; held in German, de-DE — and where that leaves the country open, settle it on everything else you already have: the regional wording and spelling the buyer uses, the ports and places they have named, the currency or the date format they wrote, anything they have said about where they live or set off from. Only where it is still genuinely open after all of that, pick the market that language's speakers are most likely to be in and go — the confirmation summary is what gives the buyer the chance to move it, so never hold the search up over it. AFerry doesn't sell in every market, and a locale it doesn't sell in is resolved to the nearest one it does, so pass on whatever you settled on rather than second-guessing it. Leave locale off only where the conversation gives no language signal at all, which searches the UK. A time of departure is required as well as a date. The search returns the sailings around the instant it is given, so a time nobody settled can return a different day's sailings than the buyer had in mind. Where the buyer named a time, use theirs. Where they didn't, use 9am and say so in the confirmation summary, so they can move it before anything is searched — never leave the time unmentioned. The same applies to the return leg of a return journey. Ask the buyer whether they want a one-way or a return before searching, rather than assuming a one-way, and say which of the two the confirmation summary is for. A return is searched by setting inboundDate; leave it off for a one-way. For a return, ask the buyer whether the return details are the same as the outbound — coming back to where they set off from, the same party, travelling the same way. If they say the details are the same, set only inboundDate and leave every other inbound field off: the return then travels the outbound's route reversed, with the outbound's own party and vehicle. If they say something differs, ask them for the return's own details and set the inbound fields that differ (inboundOrigin, inboundDestination, inboundPassengers, inboundTravellingBy), leaving the rest off to take the outbound's value. State whatever differs in the confirmation summary — that is the buyer's chance to correct it. The return must depart later than the outbound; a return at or before it comes back failed saying so. Ask how the buyer is travelling — on foot or with a car — and set travellingBy to what they say. It is required, and unlike the date and the party it cannot be defaulted: a car is priced into every sailing returned, so guessing either way prices a crossing the buyer can't book or hides the one they can. Settle it before the confirmation summary. Not every route carries both, and a car asked for on a foot-passenger-only crossing (or the reverse) comes back failed saying so — relay that as the answer rather than retrying it the other way round, unless the buyer says they'd travel differently. On a return, each leg is checked against its own route, so a return can fail on the return leg alone. The party has to be settled by type, not as a head count. Every passenger entry carries its own category, and operators price each one differently, so "4 passengers" or "a family of five" is not something you can turn into a search. Ask for the breakdown: how many adults, how many children and infants and the age of each, and whether a cat or a dog is travelling. Ask it that way round — how many of each type — rather than "how many passengers", which invites the same bare number back. A buyer who has named no party at all can be taken as one adult travelling alone, stated in the confirmation summary like everything else. Cats and dogs are the only animals AFerry carries, one entry per animal, category "Cat" or "Dog", with no age. Tell the buyer anything else isn't supported rather than searching without it. How many pets a crossing carries varies by route, and some carry none; over the limit the search comes back failed naming the limit, which is the answer to relay. Every child and infant needs an age in whole years as at the departure date, and the call is rejected without one. Operators price by the age given, so ask the buyer for each child's age instead of guessing or defaulting it, and settle that before the confirmation summary rather than searching without it. Where a return carries its own party, give each child's age as at the return date — a child whose birthday falls between the legs is a year older coming back. For a later call refining the same search, use judgement instead of always re-confirming: if only one detail changed and the change is unambiguous (e.g. the buyer asked to try a different date), call directly without re-prompting. If the request is vague, ambiguous, or changes multiple details at once, confirm again first. Always share deepLink with the buyer in the same reply as the results, without waiting to be asked for it. It opens the search results page listing every sailing returned here — not a booking page for one specific sailing — so the buyer picks and books their preferred sailing from there. Every sailing returned for a return search is one outbound leg paired with one return leg, priced together. Present the outbound legs and the return legs as two separate lists rather than one merged row, keep each option's pairing intact, and give the option's single price — never a price per leg, and never half of one. Do not ask the buyer to choose a currency or an alternative-route setting up front — the confirmation summary above only states what will be used. Omit both currency and excludeAlternativeRoutes on that first call: - The response's currency field states which currency the prices are in — the searched market's own default unless the call gave an explicit preference. Tell the buyer, don't assume they already know. If they want a different one, call again with an explicit currency. - Alternative-route sailings (a different operator or route than the most direct one) are searched alongside the route asked for. Where the results are a mix, each sailing reports isAlternativeRoute, so say which is which when presenting them. Only if the buyer asks to leave them out, call again with excludeAlternativeRoutes set to true. Each sailing's price is in minor currency units (e.g. pence for GBP, cents for EUR/USD) — divide by 100 for the major-unit amount. The search returns the sailings around the instant it was given, so some of them can depart on the day before or the day after the one asked for. Read each sailing's own departureDateTime rather than assuming it falls on the requested date, and where one doesn't, say which day it sails — a buyer told only the time will take it for the day they asked for. Where every sailing returned is on another day, lead with that rather than burying it. Give every date and time to the buyer in the natural written form of the language the conversation is being held in, never as the ISO string the schema carries. Choose the wording the way a person writing in that language would — "Wednesday 9 September 2026, 08:00" for a British English conversation, "mercredi 9 septembre 2026 à 08h00" for a French one — including the day of the week, which is how buyers think about a crossing. This covers what you say back as well as what you read out: the date and time you are searching for in the confirmation summary, and each sailing's departure and arrival in the results. A completed search can still carry no sailings at all. That means AFerry sells the crossing but had nothing matching what was asked for around that time — not that the crossing does not exist, and not that anything went wrong. Say so plainly, and offer what would most likely turn something up: another date, a wider time of day, travelling on foot rather than by car, or a nearby port. Share deepLink even then, since the results page is where the buyer can move the search themselves. Not every call comes back with sailings, and each of the other three states wants something different said. Whichever it is, keep the workings out of it — no status codes, no URLs, no route codes, no internal system names, nothing from this schema — and never imply the buyer did something wrong when they didn't: - failed carries a reason about what was asked for, and only ever that — AFerry doesn't sell that crossing, the route carries no pets or fewer than the party has, the route doesn't take cars or doesn't take foot passengers, the return departs before the outbound. It is the answer: give it in your own plain words, and offer what the buyer could change, such as another date, travelling on foot, or a nearby port. Nothing needs weighing up first; a search that failed for any other reason never reaches you as failed. - timeout means the search was accepted but hadn't finished in time. Tell the buyer it's taking longer than usual and offer to run it again — a second attempt often lands. Don't take it as the crossing not existing or having no sailings; nothing was learned either way. - unavailable means the search couldn't be run at all. Say only that you can't search AFerry at the moment and that it's nothing to do with what they asked for. Where retryable is true, offer to try again in a moment. Where it is false, stop repeating the same search — point them at https://www.aferry.com/ to search there, and offer to pick it up again later. Never fill the gap any of these leaves with sailings, prices, times or availability from anywhere else, and never present a search as having succeeded when it hasn't. Write to the buyer in plain language and keep this tool's workings out of it: never name a field, value or status from this schema. Say "on a different route than the one you asked for", not "isAlternativeRoute: true"; "here's the AFerry search page", not "deepLink". They are booking a ferry, not reading an API response.

search_ferries