[Feature] Allow for displaying photos of specific people when using multiple users

[rsaffi]

I have searched the existing feature requests to make sure this is not a duplicate request.

• Yes

The feature

It would be very nice for kiosk to allow for displaying photos/videos of specific people on a setup with multiple users (each with its own API Key defined in config.yaml), without having to pass ?user=xxxxx to the URL.

My use-case: I have a dedicated tablet that runs immich-kiosk showing photos/videos from our kids. Currently it's only fetching from my immich account and it works as expected. But I also want to setup my wife's immich account in the config.yaml so that we have a bigger pool of photos/videos from our kids to be cycled through.

I know that the "person ID" for a single person differs between my account and hers. My idea is that something like this would/could work:

(...)

immich_users_api_keys:
  father: "XXXXXX"
  mother: "YYYYYY"

(...)

people:
  - bf2db1e5-3cfe-4b6d-a87e-9d9d314eaa2e # kid1 @ father
  - 1be07a85-dd9b-43cd-a690-7e062e16ead6 # kid2 @ father
  - fffa3626-bb0a-4b86-9dbb-98708acaa06b # kid1 @ mother
  - df2fc24a-64e1-43c6-8cd2-5ab19b85ae3e # kid2 @ mother

(...)

But of course it doesn't. Setting that and trying to load kiosk I see the error with a HTTP 400 for non-existent ID.

Perhaps a change in the type of the "people" key, from a list to a dict of lists, something like:

people:
  father:
    - bf2db1e5-3cfe-4b6d-a87e-9d9d314eaa2e
    - 1be07a85-dd9b-43cd-a690-7e062e16ead6
  mother:
    - fffa3626-bb0a-4b86-9dbb-98708acaa06b
    - df2fc24a-64e1-43c6-8cd2-5ab19b85ae3e

WDYT?

[damongolding]

One solution would be to bake in a retry method into Kiosk when it gets a 400 error back. It should in theory try any other submitted API keys until all are exhausted. That way the user wouldn’t need to add any more config other then the API key. The other would go to add a APIManger they would gather all the users people, albums etc IDs.Then kiosk could ask that “I need this ID, which api key will get it?” Both have pros and cons.

…

On 15 Feb 2026 at 3:35 PM +0000, Ricardo Saffi Marques ***@***.***>, wrote: I have searched the existing feature requests to make sure this is not a duplicate request. • Yes The feature It would be very nice for kiosk to allow for displaying photos/videos of specific people on a setup with multiple users (each with its own API Key defined in config.yaml), without having to pass ?user=xxxxx to the URL. My use-case: I have a dedicated tablet that runs immich-kiosk showing photos/videos from our kids. Currently it's only fetching from my immich account and it works as expected. But I also want to setup my wife's immich account in the config.yaml so that we have a bigger pool of photos/videos from our kids to be cycled through. I know that the "person ID" for a single person differs between my account and hers. My idea is that something like this would/could work: (...) immich_users_api_keys: father: "XXXXXX" mother: "YYYYYY" (...) people: - bf2db1e5-3cfe-4b6d-a87e-9d9d314eaa2e # kid1 @ father - 1be07a85-dd9b-43cd-a690-7e062e16ead6 # kid2 @ father - fffa3626-bb0a-4b86-9dbb-98708acaa06b # kid1 @ mother - df2fc24a-64e1-43c6-8cd2-5ab19b85ae3e # kid2 @ mother (...) But of course it doesn't. Setting that and trying to load kiosk I see the error with a HTTP 400 for non-existent ID. Perhaps a change in the type of the "people" key, from a list to a dict of lists, something like: people: father: - bf2db1e5-3cfe-4b6d-a87e-9d9d314eaa2e - 1be07a85-dd9b-43cd-a690-7e062e16ead6 mother: - fffa3626-bb0a-4b86-9dbb-98708acaa06b - df2fc24a-64e1-43c6-8cd2-5ab19b85ae3e WDYT? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[rsaffi]

Why not consider the option I mentioned, that people in the config file can have either a list or a dict of lists as its children? This would allow for:

• Flexibility for the aforementioned use-case
• Non-breaking change for whoever wants to stick to the simpler setup, where people is just defined as a list

Since you already validate the config file during application startup, it would just need to cover both cases. If the children of people is a dict, then its keys need to match the keys of the children of immich_users_api_keys; if people defines a list, then those are the IDs of the single account as defined in immich_api_key.

Do you foresee any cons to this approach?

I'm not particularly fond of the "retry method into Kiosk when it gets a 400 error back", as it seems to be more of a workaround than a feature implementation. And regarding the APIManager idea, it would also work and be rather clean, but possibly a bigger effort than allowing for different ways to specify people?

Just occurred to me: the same way Kiosk allows for immich_api_key (for single account setups) but also immich_users_api_keys (for multiple accounts setups), perhaps a new key could be introduced for defining people. The current people would remain for single accounts and maybe a users_people (or something along that line) would be the specific config for multiple accounts setups.

Then it could be something like:

users_people:
  father:
    - ID1
    - ID2
  mother:
    - ID3
    - ID4

Thoughts on this?

[damongolding]

The retry loop would be a workaround/patch in essence but adding the below would be a breaking change and does not convert to ENVs very well/at all.

immich_users_api_keys:
  father: "XXXXXX"
  mother: "YYYYYY"
  
people:
  father:
    - bf2db1e5-3cfe-4b6d-a87e-9d9d314eaa2e
    - 1be07a85-dd9b-43cd-a690-7e062e16ead6
  mother:
    - fffa3626-bb0a-4b86-9dbb-98708acaa06b
    - df2fc24a-64e1-43c6-8cd2-5ab19b85ae3e

Adding a new group like your users_people dict would raise the question of needing users_albums, users_tags, users_dates etc. Which is something I want to avoid.

I don't mean to be negative or dismissive, I'm just trying to think of the best solution that would cater for most users and work for config, ENVs and url params.

What about naming the api key to use in the string using a separator:

config.yaml

immich_users_api_keys:
  father: "XXXXXX"
  mother: "YYYYYY"
  
people:
    - bf2db1e5-3cfe-4b6d-a87e-9d9d314eaa2e # use default API key
    - father@bf2db1e5-3cfe-4b6d-a87e-9d9d314eaa2e  # use father API key
    - father@1be07a85-dd9b-43cd-a690-7e062e16ead6  #  use father API key
    - mother@fffa3626-bb0a-4b86-9dbb-98708acaa06b  #  use mother API key
    - mother@df2fc24a-64e1-43c6-8cd2-5ab19b85ae3e  #  use mother API key

# or

people:
    - bf2db1e5-3cfe-4b6d-a87e-9d9d314eaa2e # use default API key
    - bf2db1e5-3cfe-4b6d-a87e-9d9d314eaa2e@father  # use father API key
    - 1be07a85-dd9b-43cd-a690-7e062e16ead6@father   #  use father API key
    - fffa3626-bb0a-4b86-9dbb-98708acaa06b@mother  #  use mother API key
    - df2fc24a-64e1-43c6-8cd2-5ab19b85ae3e@mother  #  use mother API key

ENV

environment:
    KIOSK_PEOPLE="bf2db1e5-3cfe-4b6d-a87e-9d9d314eaa2e, father@bf2db1e5-3cfe-4b6d-a87e-9d9d314eaa2e"

URL
https://KIOSK_URL?person=father@bf2db1e5-3cfe-4b6d-a87e-9d9d314eaa2e

Something like this could work if you set the api key in the config but not to PERSON_ID but then later supply it via a url param.

or would this be too complex?

[rsaffi]

I don't mean to be negative or dismissive, I'm just trying to think of the best solution that would cater for most users and work for config, ENVs and url params.

I definitely didn't take it like that! :-)
I'm also just trying to be helpful by brainstorming. My suggestions are merely that, no pressure for having my ideas chosen!

What about naming the api key to use in the string using a separator

Ahaa, that's a great idea actually. And that functionality could then also be extended to albums, tags, and dates, couldn't it?
Between both, I particularly prefer having the @user after the API key:

people:
    - bf2db1e5-3cfe-4b6d-a87e-9d9d314eaa2e # use default API key
    - bf2db1e5-3cfe-4b6d-a87e-9d9d314eaa2e@father  # use father API key
    - 1be07a85-dd9b-43cd-a690-7e062e16ead6@father   #  use father API key
    - fffa3626-bb0a-4b86-9dbb-98708acaa06b@mother  #  use mother API key
    - df2fc24a-64e1-43c6-8cd2-5ab19b85ae3e@mother  #  use mother API key

I just didn't understand this question: "Something like this could work if you set the api key in the config but not to PERSON_ID but then later supply it via a url param."

I don't know if I'm drifting from answering your actual question, but when I thought about this feature request, it was thinking that no changes in the default Kiosk url would even need to be done to achieve being able to retrieve photos of specific people from either one of the multiple accounts configured. In other words, on the tablet I'm using as a digital frame, the URL that "Fully Kiosk Browser" loads would still be the same (in my case https://photos-kiosk.mydomain.com) and the images/videos served there could come from either one of the defined accounts in the config.yaml.

So, thinking of a config like this (and using no other filters since I'm particularly only interested in this exact scenario):

(...)

immich_users_api_keys:
  father: "XXXXXX"
  mother: "YYYYYY"

(...)

people:
  - bf2db1e5-3cfe-4b6d-a87e-9d9d314eaa2e@father
  - 1be07a85-dd9b-43cd-a690-7e062e16ead6@father
  - fffa3626-bb0a-4b86-9dbb-98708acaa06b@mother
  - df2fc24a-64e1-43c6-8cd2-5ab19b85ae3e@mother

(...)

Loading https://photos-kiosk.mydomain.com would display a mixed collection of photos/videos that can vary from kid1@father, kid2@father, kid1@mother or kid2@mother.

[damongolding]

What I meant was if a user did not add any people, albums, tags etc in the config.yaml file. They could still add them via the url e.g. ?person=XXX@father and it would still work. As long as they had the api key in the config file.

Some users add people_ids via the URL and this method would work of them too.

[damongolding]

I've done a little work on this branch https://github.com/damongolding/immich-kiosk/tree/feature/multi-account.

Quick tests shows it's working with albums and people. This feature is a LOT bigger (to code) then I originally anticipated 😅

[rsaffi]

I'm happy to try it out and give feedback! I saw in ghcr.io the 0.33.0-prerelease tag for immich-kiosk, but that was pushed 7 days ago, and I see commits from yesterday on the multi-account branch. In the immich-kiosk-development package, I see tag 0.33.0-beta.1 from 8 days ago, so probably also not up-to-date.

How do you advise me to test the implementation in the multi-account branch? Should I build the image myself? If so, do you have some guideline for that (didn't find anything in the docs)? Otherwise I can find my way through the GHA workflow. :)

[damongolding]

There isn't currently a docker image built for this branch.

I can possibly make one a little later (I'm currently nap trapped by my poorly son).

Your other option is to clone the branch and either build the binary by running task build or build the image.

There is a page on the docs here https://docs.immichkiosk.app/contributing/ but I have recently moved away from NodeJS and pnpm to Bun. So you would need Bun, Go and task to build the binary locally. There is also a nix flake if you are a nix user.

[damongolding]

I've quickly created a dev image with this WIP feature in it @rsaffi. The image is ghcr.io/damongolding/immich-kiosk-development:0.33.0_multi-account

config.yaml example

immich_users_api_keys:
  - john: XXX

people:
  - 1234 # will used default api
  - 1234@john

albums:
  - 5678 # will use default api
  - 5678@john

or you can use these in the url e.g. http://KIOSK_URL?person=1234@john

[rsaffi]

Thank you for that! I just ran kiosk with this image and have some feedback:

I followed your sample config from below and noticed you changed immich_users_api_keys from object to array, so I adjusted my config accordingly:

immich_users_api_keys:
  - john: XXX

But as it turns out immich_users_api_keys is actually/still expecting an object, not an array. I caught it in the container logs when I noticed the application failed to start:

immich-kiosk  | 2026-02-21T09:06:37.234099239Z 10:06:37 ERRO Config validation failed:
immich-kiosk  | 2026-02-21T09:06:37.234141545Z 10:06:37 ERRO - immich_users_api_keys: Invalid type. Expected: object, given: array
immich-kiosk  | 2026-02-21T09:06:37.234148655Z 10:06:37 FATA Invalid configuration

After adjusting this back to the previous format I then ran into another similar issue (incorrect data type), this time regarding weather. This is what I have in my config (from the beginning, when I first configured kiosk and followed the docs, so I have never changed it):

weather:
  - name: berlin
    lat: ##.#######
    lon: ##.#######
    api: "<REDACTED>"
    unit: metric
    lang: en
    forecast: false
    default: true

But when I started the container for immich-kiosk-development:0.33.0_multi-account, I got:

immich-kiosk  | 2026-02-21T08:59:01.396529597Z 09:59:01 ERRO Config validation failed:
immich-kiosk  | 2026-02-21T08:59:01.396574227Z 09:59:01 ERRO - weather: Invalid type. Expected: object, given: array
immich-kiosk  | 2026-02-21T08:59:01.396958164Z 09:59:01 FATA Invalid configuration

So for now I just commented out the whole weather block. Then the container started and I could check the results. And for that, some additional feedback:

• I temporarily enabled show_user: true to see from which account the images were being fetched. I can see them being sucessfully fetched from both father and mother accounts, so that's great (thanks!). I also noticed that whenever kiosk would display two portrait images side-by-side, they would always be from the same account (either from father or from mother, but never one from each account). Is this by design or just the way the current implementation handles this?
  • It could be interesting, to have a more diverse mix of photos, that when two portrait images are displayed, they could be from different accounts.
• I noticed that when kiosk is displaying a video, it doesn't show from which account it's being pulled (so it's not respecting show_user: true). For me it doesn't matter, as I'll disable show_user in the end, once a new release is done, but since I caught this, I just thought worth mentioning. ;-)

[damongolding]

You're correct that the immich_users_api_keys is a dict/object. I haven't changed this I just mistyped in my comment, sorry about that.

In (currently unreleased) 0.33.0 the weather config will change a little. This is to accommodate a new rotation feature. That's the error you are getting. The new structure will be

weather:
  locations:
    - name: London 
      # etc 

Splitview tries to display related images side by side e.g two images from the same album or two images of the same person. I am not looking to change this behaviour.

This is just a bare bones implementation, so I haven't looked at videos or live photos yet. I expected there would be issues with those formats.

Thank you for taking time to help test this. It's requiring more code changes than I thought it would, so having more eyes on it helps.