TripDesk365 in the tools your team already uses
Booking and disruption events in Slack, Microsoft Teams or your own systems, trip look-ups from a Slack command, calendar files for travellers, and a read-only API for your HR, expense and reporting tools.
The API and the Slack command only read, and events only report what happened. None of them can create, change or cancel a booking.
Events to Slack, Teams or your own systems
An administrator adds a destination on the Integrations page and picks the events it receives. A destination is a Slack channel through Slack's incoming webhook, a Microsoft Teams channel webhook, or your own HTTPS endpoint.
| Event | Sent when |
|---|---|
| Quoted, Held, Ticketed | A sale priced in TripDesk365 reaches that step. |
| Disruption, Disruption acknowledged | A cancelled, delayed or diverted flight is filed, and later resolved. |
| Date change asked for, Date change answered | A traveller asks from their trip link, and an agent answers. |
| Approval requested, Approval decided | An out-of-policy trip goes for approval, and is approved or refused. |
| Servicing requested | A refund, void, exchange or name correction is asked for. |
| Itinerary emailed, Itinerary link shared | A traveller is sent their itinerary or a private trip link. |
Each message carries the booking reference, its status, the route, the first departure in local time, the client's name and a link to the booking in your console. Never a traveller's name and never a price, because a channel can be wide.
- Signed. Webhook requests carry an X-TripDesk-Signature header: a timestamp and an HMAC-SHA256 of the timestamp and body, for your receiver to check within five minutes. The signing secret is shown once. When you rotate it, the old secret keeps signing alongside the new one for a while, so your receiver can switch without missing a delivery.
- Retried. A failed delivery is tried again after 1 minute, 5 minutes, 30 minutes, 2 hours and 12 hours, then daily three times. One that still fails is kept, visible and retryable by hand, and ten failures in a row pause the destination until someone resumes it.
- Safe addresses only. Only HTTPS addresses on the public internet are accepted. Private and internal addresses are refused at the moment of connecting.
Send a test from the Integrations page before you rely on a destination.
The /tripdesk command in Slack
Look up trips without leaving Slack:
/tripdesk recentlists the next five upcoming trips./tripdesk find ABC123finds a booking by our reference, the record locator or an airline confirmation, or by surname if your role may read names./tripdesk traveler Reyeslists a traveller's trips./tripdesk flight BA117lists your bookings on that flight with its latest status, delay, gate and baggage belt from live flight data, and when each was last updated. Add a date for one day.
How linking works
- An administrator installs the TripDesk365 app from the Integrations page. A Slack workspace can belong to one agency only.
- The first time someone types /tripdesk, they get a one-time link, valid for 15 minutes. They open it while signed in to TripDesk365 to link their Slack account to their own login.
- From then on, every answer is built with that person's permissions, exactly as the console would show them.
/tripdesk unlinkdisconnects them.
Answers are visible only to the person who asked. Slack guests are refused. Every request must carry Slack's signature and is refused if more than five minutes old. Answers carry references, routes and dates, names only for people whose role may read them, and never a price.
A read-only API
Four endpoints for your own systems, described in OpenAPI 3.1 at /api/v1/openapi.json on your TripDesk365 address:
GET /api/v1/bookings: the booking register, with the same filters as the console, paged.GET /api/v1/bookings/{id}: one booking with its flights, in local times.GET /api/v1/travellers: the traveller directory.GET /api/v1/clients: your client accounts.
| Scope | What it returns |
|---|---|
read:bookings | The booking register and single bookings, with cost centre and booking fields, without traveller names. |
read:travelers | Adds travellers' names to bookings, and the traveller directory. |
read:clients | Client accounts: code, name, kind and whether active. Never their settlement terms. |
An administrator issues keys on the Integrations page. A key starts with tdk_, is shown once, and only its hash is stored. It can expire after 1 to 730 days or never, and can be revoked at any time. An agency can hold 20 live keys, and each key can make 120 requests a minute. Net fares, markups and commission are never returned, and there is no write API.
Calendars, email and alerts
- Calendar files. Every itinerary can be added to a calendar as an .ics file, from the booking page or the traveller's private trip link. Each flight is one event with both airports' local times in its description, and importing an updated itinerary updates the events instead of duplicating them.
- Email forwarding. Forward airline and supplier confirmations to your agency's private address. See booking import.
- Browser alerts. Staff can turn on notifications in their browser for disruptions and for raised State Department advisories.
What is not here
- No write API: nothing outside TripDesk365 can create or change a booking through it.
- No ready-made connectors to expense, HR or accounting systems. They read from the API or receive webhooks.
- No connection to a GDS or airline for search or ticketing today. Bookings arrive by import and email forwarding.
Connect your team on day one
In the demo we will connect a Slack channel, send a test event and issue a read-only key, so you can see exactly what leaves TripDesk365.