[INTEGRATION REQUEST] Collect all integration requests here

[mauriceboe]

Integration Requests

This is the central place to collect and discuss integration requests for TREK.

We get a lot of requests for connecting TREK with external services. Since we can't integrate everything, this issue serves as a voting thread — upvote (👍) the integrations you'd like to see, and the most requested ones may be considered for future releases.

How to request an integration

1. Check the comments below to see if your integration has already been requested
2. If yes → upvote it with a 👍 reaction
3. If no → add a comment with:
   • Service name (e.g. "Komoot", "Google Calendar")
   • What it should do (e.g. "Import routes", "Sync trip dates")
   • Why it's useful for trip planning

Currently integrated

• Immich — Self-hosted photo sharing (Photos addon)
• Google Places API — Place search, details, photos
• OpenStreetMap / Nominatim — Free place search fallback
• Nager.Date — Public holiday data (Vacay)
• GPX import — Import waypoints from any GPX-compatible app

---

Not every integration can or will be built. TREK is a self-hosted tool and prioritizes integrations that align with the self-hosted philosophy (Immich, OSM, GPX). Cloud-only services with complex OAuth flows are lower priority.

[steffenrapp]

Papra for document storage

Is your feature request related to a problem? Please describe.
I want to attach documents but usually I try to avoid redundancy and don't want my travel related documents to be available only in TREK.

Describe the solution you'd like
Connect with the document management solution Papra to save documents directly from within TREK into Papra and search Papra for existing documents and link them in TREK.
Papra has an API that is capable of this and then redundancy could be avoided easily.

Describe alternatives you've considered
Create a link in Papra and attach it in TREK. But this wouldn't be seamless and an extra login would be required when opening the link.

[steffenrapp]

AirTrail

Is your feature request related to a problem? Please describe.
I have maintained all my flights in AirTrail. This is a great self-hosted tool for flight tracking, history and stats. I don't want to maintain those flights again and also want to keep using AirTrail.

Describe the solution you'd like
Integration with AirTrail to retrieve or link flight data from it that it's not necessary to maintain the flights again.

[mauriceboe]

@steffenrapp AIRTRAIL Import/Sync is coming in the next release :)

[dhruvb14]

Is there a plan for it to take stuff from Trek and push it to AirTrail. I saw 2 way sync but its not what I thought. I have all my flight numbers and stuff in Trek and just learned about AirTrail and want to be able to push everything to AirTrail somehow

[steffenrapp]

It's awesome! @mauriceboe what do you think of an additional setting that lets us define which is the leading system? In my case I want AirTrail to be the single source of truth for flights. So TREK should only read data from it and never write data to AirTrail.

Another thing is: Right now TREK imports the ICAO code of the airline as airline name. Maybe it's better to change that to the real name of the airline? Eg. "Eurowings" instead of "EWG"

[Akashic101]

Photoprism

Photoprism is very similar to Immich and has the advantage of a simple API that could be used to link to an album or get geo-tagged photos of a specific location. Integrating Photoprism should be simpler due to the documentation using DeepWiki

[is33]

Home assistant calendar sync?

[scottwallacesh]

TripIt

Being able to import data from TripIt would be amazing. TREK would become the archive of all past trips and with Immich integration would allow for easy trip photo viewing too.

[steffenrapp]

Do you think of it more like a migration than an integration?

[dhruvb14]

I would think of it as migration, this is the tool im migrating from. For now, I exported my important trips to PDF and had Claude with mcp setup to Trek import them in. But its less the ideal cause the 60 RPM limit on MCP which is hardcoded keeps slowing down the import.

[jubnl]

I would think of it as migration, this is the tool im migrating from. For now, I exported my important trips to PDF and had Claude with mcp setup to Trek import them in. But its less the ideal cause the 60 RPM limit on MCP which is hardcoded keeps slowing down the import.

The limits are not hard coded. Take a look at the README, there's a table with all environment variable you can set.

[jubnl]

Being able to import data from TripIt would be amazing. TREK would become the archive of all past trips and with Immich integration would allow for easy trip photo viewing too.

If by TripIt you mean tripit.com, this won't be possible
tripit/api#288

Instead, you can use the integrated MCP to import your trips if you are able to extract trip data from your tripit account

[scottwallacesh]

Booking confirmation parsing

It would be amazing if TREK could parse booking confirmations (text/HTML from emails, PDFs, etc.) to create booking entries to provide a seamless way of ingesting data.

[tiquis0290]

maybe we could parse ical files which some providers sent with train/bus tickets

[michidk]

I think this feature would work well with LLMS. Just need to use a good abstraction library, so that everybody can use the models they like. I would happily use OpenAI models for it as long I still have to select specific emails to forward to it.

Today I actually used the MCP to create entries from my booking confirmation pdfs via claude. Would be really nice If i dont have to run it locally.

[christofdamian]

I am interested in replacing my TripIt usage, and the booking imports via email is my main use case.
For now, I am trying out creating a separate service that parses the emails and then pushes the information to Trek.
I am at the early stages, and will probably take advantage of KDE Itinerary for the parsing and if that is enough, I use some AI APIs.
Let's see how it goes. I'll report back.

[christofdamian]

I managed to hack something together: https://codeberg.org/cdamian/trek-ingestor/
It consists of a service that reads an IMAP mailbox and then parses with Kitinerary and Anthropic AI, and adds it to Trek.
There is a simple web front-end to register, authenticate with Trek, and add some email addresses.
Kitinerary is quite limited, but it is free. AI costs with every parsed email.

The way I imagined it being used is in combination with a Trek instance, and users can then add their email addresses, and forward mail to the dedicated IMAP box.

Current status: It works for me. :-)
There are still some to-dos if you want to use it safely in a multi-user setting, like confirming email addresses.

[christofdamian]

I added registered email configuration and status replies to forwarded emails.
This required adding SMTP support.
I am overall pleased with the current status. I am eagerly awaiting my next trip. :-)
Ideally, this functionality would be built into Trek, which would make it more integrated.
But for now, this seems to work well.

[chazragg]

Various calendar syncs

I understand you can download the ical, but it is a snapshot and if anything changes after you need to redownload and reimport. It would be nice to have a live sync between your calendar and TREK

[idoodler]

I'd love it to have it like Tripsy. Each activity, transport, booking is its own entry. Those calendar entries are enriched with emojies so its always clear what type of entry it is.

There is one .ics file which updates in the background automatically, so the Calendar is always in sync, no need for Google or iCloud integration.

So it looks like this:

The entry itself is also enriched with all available information like location, Booking codes, phone numbers and of course the date and time.

[christofdamian]

I think there is work happening for this in #879

I, personally, would prefer emojis being optional 😄

[michidk]

Google Calendar Sync

Service: Google Calendar
What it should do: Sync trip dates and day-level itinerary items to a Google Calendar. Ideally two-way or at least one-way push so your trip schedule shows up alongside your regular calendar.
Why it's useful: Makes it easy to see trip plans in context with work/personal commitments, share the schedule with travel companions, and get reminders for upcoming activities.

[michidk]

Google Photos Integration (Link a Collection)

Service: Google Photos
What it should do: Link a Google Photos album/collection to a trip. Photos from the album would surface in the trip view — similar to the existing Immich integration but for Google Photos.
Why it's useful: Not everyone self-hosts Immich. Google Photos is where most people's travel photos already live. Linking an album is low-friction and avoids manual uploads.

[michidk]

Google Photos Integration — Technical Findings

I looked into what it would take to build this, mirroring the existing Immich integration as closely as possible. Here is a summary.

Cost & Quotas

• Google Photos Library API is free — no per-request charges.
• Default quota: 10,000 requests/day (adjustable in Google Cloud Console).
• Downloading photos via baseUrl hits Google CDN directly and does not count against the API quota.

Proposed Approach: Per-User OAuth App

Instead of TREK shipping a single Google Cloud project (which would require Google app verification for >100 users), each user creates their own Google Cloud project and provides their own client_id + client_secret in TREK Settings.

This keeps the model identical to Immich (user brings their own credentials) and avoids:

• Admin-level Google Cloud config
• Google app verification / security audit
• Shared quota bottlenecks (each user gets their own 10k/day)

Key Differences from Immich

	Immich	Google Photos
Auth	Static API key	OAuth 2.0 — consent screen + redirect flow + refresh tokens
Setup	User enters URL + key	User creates Google Cloud project, enters client_id + client_secret, completes OAuth grant
Image URLs	Stable, proxied through TREK	baseUrl expires after ~60 min — proxy needs to re-fetch before serving
API access	Full control (self-hosted)	Rate-limited, Google can deprecate

What Needs to Be Built

Server-side:

1. OAuth 2.0 flow — GET /auth/google-photos/start → Google consent → GET /auth/google-photos/callback → store encrypted refresh + access tokens per user (follows existing OIDC patterns)
2. Token lifecycle service — access tokens expire hourly, auto-refresh via refresh tokens
3. New routes mirroring Immich — search, albums, trip photos, asset proxy — hitting Google Photos Library API instead
4. Image proxy — must fetch a fresh baseUrl from Google before streaming (since URLs expire ~1h). Cache with short TTL
5. DB migration — add google_photos_client_id, google_photos_client_secret, google_photos_refresh_token, google_photos_access_token, google_photos_token_expiry to users table (all encrypted at rest like Immich credentials)

Client-side:

• Mostly reusable. MemoriesPanel already abstracts around asset IDs and thumbnail URLs.
• Add a provider selector (Immich vs Google Photos) in Settings and in the Memories panel.
• Swap API paths based on active provider.

Main Complexity

The only significant new complexity vs Immich is OAuth token management and the expiring image URL proxy. Everything else — route structure, DB schema shape, frontend component — mirrors what already exists.

[tiquis0290]

actually Google Photos Picker API is more corresponding for use except now you have to first select images to share to app which then could lead to doble selection from user one for getting acces one for assigning them, the limits there are generous but you need to specify return adress before so even than each instance will have to have own setup

[pcs305]

SMS Notification.
Add function to be able to send SMS (phone text).
I currently use Brevo, but would appreciate any SMS integration.

Give a choice between email, text or both.

[mathieulequinuniverspneus]

Hello :-)

Here are some ideas for a nextcloud integration

Comprehensive Backups: Facilitate full-system backups for all TREK data.
Centralized Storage & Editing: Use Nextcloud as the primary backend for uploaded files (enabling file linking without duplicates) and supporting real-time collaborative editing.
Media Management: Organize and display photo collections natively, structured trip-by-trip.
Calendar Sync (CalDAV): Ensure all itinerary dates are automatically synced with the user’s personal calendar.
Nextcloud Tasks for simple "to-do" lists.
Nextcloud Deck (Kanban boards) for complex travel logistics, such as visa applications or group coordination.
Nextcloud Talk, providing advanced features like encrypted voice and video calls.
Unified Authentication (SSO): Streamline the login process by using Nextcloud as the Identity Provider (OIDC/SAML).

[jubnl]

Comprehensive Backups: already present
Media Management: already present
Unified Authentication: already present

So if I resume correctly, what's really asked is a nextcloud integration ?

[matlox47]

Yes, but nextcloud can do many things, so I tried to list some integrations features that could benefits nextcloud users

[ragnarkarlsson]

Photon

For places lookup, aligned with OpenStreetmap

Can self host, I use the unofficial Docker image already with Dawarich.

Then of course Dawarich integration would be a further complimentary aspect.

[MikeDabrowski]

Mapy.com (formerly mapy.cz) as map tiles integration

Why? Mapy.com has very well network of hiking trails and excellent coverage in Europe (decent in the World) - Having trails visible helps planing trips.

I assume this might be difficult from the legal standpoint - they may not be too happy to share their map tiles. I already tried using them via existing option in the settings but it didn't work.

[jubnl]

seems feasable:

• https://developer.mapy.com/rest-api-mapy-cz/tutorials/map-display/
• https://api.mapy.com/v1/docs/maptiles/
• https://developer.mapy.com/rest-api-mapy-cz/function/routing/

[MikeDabrowski]

Though I am not using api key here. But the swagger has no mention of it either (no query param) 🤔
I may also be dumb because it says that parameter is invalid.

Yep, dummy me. API key required now

[tiquis0290]

Hi you need to create developer account and get api key, then used in url replace the {apikey} with your api key.
https://api.mapy.com/v1/maptiles/outdoor/256/{z}/{x}/{y}?apikey={apikey}

[MikeDabrowski]

Just did, waiting for it to become active. There's a note it may take 15mins to activate.
Thanks

Edit:
Confirmed - works, just need to wait a bit for the api token to become available.

So the feature request would become to let it be preserved and available similar to the built-in templates. The api-rate limit can run out and you'd need to change the template to see anything, or you may need to switch to other, more detailed map for specific things. Shall I update my original post with that change?

[JanKleine]

transitous.org

From the site:

Transitous [...] is a community-run provider-neutral international public transport routing service.

Using openly available data and a FOSS routing engine we operate a free to use routing service that does not stop at borders.

What it should do: Related to #587, I looked for ways to display train trips on the map, this would be my initial request. Maybe when you enter a booking with origin, destination, and departure/arrival times it could suggest possible matches to choose from to display on the map.

The API has data for trains, busses, trams, ferries, etc. across a wide range or regions. It can also do routing across borders and providers and even offers vehicle location data. I can't really comment on the quality of the data, but at least in central Europe it seems to be solid at first glance. I must admit, my mind was a bit blown that this exists.

Why it's useful for trip planning: Pretty much a no-brainer IMHO.

The usage policy is detailed here: https://transitous.org/api/. A quick glance at their matrix server suggests that they are very welcoming to open source projects.

[yannolerobot]

Dawarich

Fantastic selfhosted, privacy conscious Google timeline replacement. Tracks your location using many apps, home assistant and recently a new mobile app. It has an API that should make it straightforward to integrate for bringing in routes.

https://github.com/Freika/dawarich

[roel-de-vries]

A Dawarich integration would be a great addition to automatically suggest visited placed in the journey add-on!

[wimpel]

Wanderer

Wanderer is a self hosted trail database. I use it to plan (singleday and multiday) hikes,
https://github.com/open-wanderer/wanderer

It would be nice to integrate the trails loaded/generated in wanderer in a certain trip. Bonus would be an option to select/deselect waypoints from a trail in wanderer to add as as locations in TRIP.

Request is also mentioned in: #19 (comment)

[RayJW]

It would be really nice to see proper ntfy support for notifications. It is one of the most widely used, and easily configured self-hosted option for notifications, and from what I can gather it is usually the go-to. While it does support webhook as an option, the notifications then display raw, unformatted JSON which isn't very human-readable at a glance. From my understanding, this would only require adding topic to the JSON payload (https://docs.ntfy.sh/publish/#publish-as-json) instead of the webhook to the specific topic and should thus be a pretty trivial change. It would also be good to have the authentication configurable, as usually self-hosted instances require a token, but that could also be solved with the URL parameter initially.

[jubnl]

This is already something we added in trek. The v3 release which ships in about a week will have ntfy support sur notifications!

[RayJW]

Great news, thanks for letting me know. Definitely looking forward to that! :D

[Itschotsch]

OwnTracks

Very similar to @yannolerobot's Dawarich request.
I self-host OwnTracks, which is an alternative to the Google Maps Timeline.
All it does is track position (and battery) data for the configured devices throughout time.
It would be great to be able to see the my position timeline on Trek's map.
Since OwnTracks is capable of tracking multiple devices, e.g., each person's phone, each Trek user could be mapped to one (or more?) device(s).

[Itschotsch]

I have switched over to Dawarich but this may still be useful to some people.

[steffenrapp]

Synology Drive Integration for Document Linking

(Request is similar to Papra and Nextcloud)

Is your feature request related to a problem?
When attaching documents, I try to avoid redundancy and don’t want travel-related files to exist only within TREK. Managing duplicates across systems makes organization harder and increases storage overhead. Ideally, documents should remain in a centralized storage system while still being easily accessible and linkable within TREK.

Describe the solution you’d like
Integrate TREK with Synology Drive to allow users to browse, search, and link existing documents directly from their Synology storage without duplicating files. Additionally, enable uploading new documents from within TREK directly into Synology Drive, then linking them automatically. This would provide a seamless workflow where Synology Drive acts as the single source of truth for files, while TREK references them as needed.

Describe alternatives you’ve considered
A workaround would be to manually generate share links from Synology Drive and attach them in TREK. However, this is not seamless, requires extra steps, and may involve additional authentication when accessing the files.

[joachimpaulkgg]

OpenCloud / Nextcloud integration + Collabora support

First off, really really nice project! I've always wished for a vacation planner exactly like this. Planning with friends is so much easier now, and it lets you really focus on the important things.

I have two feature requests that would be amazing if added:

1. WebDAV connection to cloud storage (like OpenCloud or Nextcloud). It would be great to keep all important documents in one place, accessible offline via a native app, and easy to share with guys who don't use Trek.

2. Collabora integration.
   Being able to natively open and edit documents or spreadsheets (like Word or Excel) together directly from inside Trek would save a ton of hassle. It would seriously boost the collaborative part of the app.

Keep up the great work! Thanks