Feature request: workflow action to link a still asset with its companion video (livePhotoVideoId)

[duruonanni]

What

A workflow action (or an equivalent plugin host function) that sets livePhotoVideoId on a still
asset — linking an image to a video that is already in the library, the way Immich does
internally for the live photos it recognises.

Why

In #26840 it was decided — reasonably — that
Immich should not parse brand-specific live-photo metadata:

We won't be adding support for random proprietary methods of doing this; there is a standard for it
that Immich supports, and as far as we're concerned that is sufficient. This seems like a good fit
for a custom tool that transforms that proprietary metadata into proper EXIF, or perhaps a plugin
for Immich when we release workflows.

I followed exactly that guidance and it works: an external tool detects the pair, merges the two
files into a standard Motion Photo, and links the resulting assets. But the link step has to
reach around the workflow engine — there is no action for it, so the tool needs its own API key with
asset.update and calls PUT /api/assets/{id} itself.

With a generic action the whole flow could stay inside the workflow:

AssetCreate ─► filter ─► webhook (external tool normalises the files)
                      ─► assetLinkLivePhoto(videoId)     ← the missing primitive

It is deliberately not brand-specific: it takes a video asset ID and links it. Anything able to
identify a companion video — a plugin, an external script, a future importer — can use it, and
Immich keeps owning the policy (visibility, websocket events, the onBeforeLink behaviour).

Notes

• Functionally this is what PUT /api/assets/{id} with livePhotoVideoId already does, so the
  backend semantics are settled; the ask is to expose it to the workflow/plugin layer.
• If plugins are the intended home, a host function would work equally well — httpRequest already
  lets a plugin achieve it the roundabout way today, but then the plugin (not Immich) is holding the
  API key.
• Happy to be told this belongs in a plugin instead. The goal is just to make the capability
  reachable without an out-of-band API key and without touching the database.

Background on the problem and the tool I built for it: #32598.

[github-actions[bot]]

This discussion has automatically been closed as it is likely a duplicate. We get a lot of duplicate threads each day, which is why we ask you in the template to confirm that you searched for duplicates before opening one. If you're sure this is not a duplicate, please leave a comment and we will reopen the thread if necessary.

[duruonanni]

I don't believe this is a duplicate, so I'd appreciate a reopen — happy to be corrected if it is.

The vivo threads (#22825, #26840) ask Immich to parse a proprietary format, which was declined, and I'm not asking for that again. My tool does the parsing outside Immich, exactly as suggested in #26840:

This seems like a good fit for a custom tool that transforms that proprietary metadata into proper EXIF, or perhaps a plugin for Immich when we release workflows.

What this thread asks for is the missing generic primitive that lets such a tool — or a future plugin — do its job through workflows: an action that takes a video asset ID and sets livePhotoVideoId on a still asset. It knows nothing about vivo or any other brand; the backend behaviour already exists in PUT /api/assets/:id.

Today the only way to link an existing pair is to hand the external tool an API key with asset.update and call that endpoint out of band, which is why the tool can't be a pure workflow step.

If the answer is "this belongs in a plugin once plugins can be installed" — that's a perfectly good answer, and I'll close the thread myself.

[bo0tzz]

This is a dupe of #29167. Also, please read main/CONTRIBUTING.md#use-of-generative-ai and post in your own words.