Skip to content
This repository has been archived by the owner on Aug 18, 2023. It is now read-only.

Multi-tenant applications #4

Open
cipater opened this issue May 24, 2022 · 1 comment
Open

Multi-tenant applications #4

cipater opened this issue May 24, 2022 · 1 comment

Comments

@cipater
Copy link

cipater commented May 24, 2022

The readme notes a limitation with respect to the api_key:

The api_key is set at the global level: this means that if you manage multiple stores, you will need to run the code for each store in a different environment.

This is a regression from the existing library, and the proposed solution of "you will need to run the code for each store in a different environment" is not feasible for anyone running a multi-tenant application. This potentially makes this library unusable for anyone doing so. However...

After looking at the source, an untested workaround seems to be:

begin
  config =
    Klaviyo::Configuration.new do |config|
      config.api_key['ApiKeyAuth'] = 'YOUR API KEY'
      # config.max_retries = 5 # optional
      # config.max_delay = 60 # optional
    end

  client = Klaviyo::ApiClient.new(config)

  Klaviyo::TrackIdentifyApi.new(client).track_post(data)
end

If there is no planned support for multi-tenant applications, perhaps this can be noted in the readme's appendix.

@dano-klaviyo
Copy link
Collaborator

dano-klaviyo commented Jun 5, 2022

@cipater Thanks for bringing this up.

Also the private api key can be set per request using this workaround (while we work on a permanent solution):

opts = {
  query_params: {
    'api_key': 'private-key',
  },
  debug_auth_names: []
}
 
response = Klaviyo::Templates.get_templates(opts)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants