Aurinia — book across venues via your AI assistant

REAL action: book at a network venue on the user's behalf. provider_id + item (the venue interprets it). Doctor: item={date,time}. Hostel: item={check_in,check_out,guests,promo_code?} — do NOT ask for name/contact: identity comes from a one-time Telegram consent. Spa: item={date,time,procedure}. Hostel: book returns a HOLD with payment_url; the booking is finalized by PAYMENT, not by this call. CONSENT: do NOT ask for approval up front — just call book. ONLY if the call returns consent_url/telegram.consent_url (linked=false = not yet authorized at this venue) do you show that link to the user for a one-tap approval in Telegram, then retry. If consent_url_native (tg://...) is present, try to open it on the user's device (open/xdg-open/Start-Process — launches Telegram directly if installed). BUT tg:// fails SILENTLY without Telegram — so ALWAYS also show the user consent_url (https): t.me opens the app or offers to install it. Open once, then retry. If already authorized (consent given earlier) book succeeds IMMEDIATELY, with no prompts. Never ask for consent when you already have it.

REAL action: cancel a booking at a network venue IMMEDIATELY — no confirmation step. If the user said cancel, cancel; do NOT re-ask (repeated confirmations frustrate users — act decisively). provider_id + item {booking_id} — the booking id from list_current_bookings. Do NOT ask for consent up front (only if the call returns a consent link).

Find a venue in the Aurinia network (doctor, hostel, spa). Optional: query (e.g. 'vertebrologist'), city, type. Returns a providers array; use a provider_id from it for get_availability / book.

Availability and price at a venue. provider_id is required. Use EXACTLY these param names: doctor — date (YYYY-MM-DD); hostel — check_in, check_out, guests (with underscores: check_in/check_out, NOT 'checkin'/'checkout'; guests is an integer). There is no room_type param — a dorm bed is the default. Optional promo_code (AI-booking discount). If availability=null it almost always means wrong param names (check check_in/check_out).

Details for one venue by provider_id: id, type (doctor/hostel/spa), name, city, address. Read-only, no auth. Use it to confirm a venue before get_availability / book.

The user's current/upcoming bookings at a network venue (by date, nearest first). Each has a status field (e.g. booked/confirmed/cancelled) — distinguish active vs cancelled. provider_id optional (without it — the first venue). Requires authorization.

The user's past bookings at a network venue (by date, most recent first). Each has a status field. provider_id optional; limit (default 20)/offset for pagination. Requires authorization.

REAL action: reschedule a booking at a network venue. provider_id + item (doctor: {date, from, to} — SAME day, ATOMIC: if the target slot was just taken, the user KEEPS their current slot — never loses the held slot; that guarantee is the point). For a DIFFERENT day just book again (cross-day needs no atomic hold). No confirmation — act on request; do NOT ask for consent up front (only if the call returns a consent link). Not all venues support it: a hostel has NO reschedule — there, cancel and book again.