Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiple API credentials #264

Open
svoop opened this issue Nov 21, 2024 · 1 comment
Open

Multiple API credentials #264

svoop opened this issue Nov 21, 2024 · 1 comment

Comments

@svoop
Copy link

svoop commented Nov 21, 2024

For transactional mails, our Rails app has an initializer featuring Mailjet.configure with the API key/secret of the primary account. This is used by Action Mailer with delivery method :mailjet – so far, so standard, so good.

However, we'd like to move our marketing mails from Brevo over to Mailjet as well and use the API to manage campaigns, templates and sends. For this to work, I'd need to set up sort of a second Mailjet.configure with the API key/secret of the marketing subaccount. However...

MailjetMarketing = Mailjet.dup

...is probably not a good (and maybe not a thread-safe) idea since Mailjet is a module and won't be deep cloned.

Is there a best practice how to do this without having to monkey patch too much into the gem – in order not to trip over 💣 when updating the Mailjet gem down the road?


As a side note: For marketing, I'd like to use v3.1 to send, but then need v3 for the rest. This approach is pretty sleak, so it would be nice if it would integrate with a solution.

@svoop
Copy link
Author

svoop commented Nov 25, 2024

As a workaround, I'm configuring Action Mailer (transactional mails via primary account) with delivery_method :smtp manually set to the values from the Mailjet gem. This way, the Mailjet class is available for the marketing stuff via the subaccount using this hack to get sending via APIv3.1 and still have access to all the rest APIv3.

Needless to say that this is pretty hackish and since Mailjet does feature subaccounts with separate API keys (and also encourages the use of such subaccounts in order to isolate transactional from e.g. marketing), there should definitely be a better, and cleaner way to do this... maybe in a future version of the gem.

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

No branches or pull requests

1 participant