The plugin accepts a domain configuration value, but its asset source component does not pass that domain through when calling @frontify/frontify-finder’s create() function. As a result, the Finder can initialize without the expected auth/domain context, eventually causing a runtime error like Cannot read properties of undefined (reading 'bearerToken').
The general fix is to forward the configured domain into the Finder creation call, e.g. create({clientId, domain: userConfig?.domain, options}), and ideally show a clear configuration error when no domain is available. It would also help to ensure the field-level frontifyAssetSource(config) and Studio-level frontifyPlugin(config) paths both pass the same config through to the Finder.
The plugin accepts a domain configuration value, but its asset source component does not pass that domain through when calling @frontify/frontify-finder’s create() function. As a result, the Finder can initialize without the expected auth/domain context, eventually causing a runtime error like Cannot read properties of undefined (reading 'bearerToken').
The general fix is to forward the configured domain into the Finder creation call, e.g. create({clientId, domain: userConfig?.domain, options}), and ideally show a clear configuration error when no domain is available. It would also help to ensure the field-level frontifyAssetSource(config) and Studio-level frontifyPlugin(config) paths both pass the same config through to the Finder.