Trigger notification for subscription activated via API

[jezzzm]

Hi there,

For manual subscription handling outside of our frontend, we can't just complete the setup in the Swell UI - in our case we want to end a trial on a specific date. This is okay though, because we can create the draft in the UI and then use the console to PUT date_trial_end = blah along with draft = false to activate it.

This works fine and things look correct in the UI, however it doesn't look like the email notification subscription.new is triggered. I'm wondering if there is a modifier we need to pass with the PUT to make sure this happens?

thanks!

[logeshswell]

@jezzzm Generally, New subscription email notification is sent only when an active subscription is directly created from the cart.
In other words, it is triggered only for new records with active: true and it won't be triggered for the updation of subscription record data.
But, you can still achieve sending email notification by adding additonal field in the PUT api call as follows:

"$notify": "new"

Screenshot for reference:

[ericingram]

To add to this: the reason it only sends this notification if it's created with active: true and not when it's updated in your example, is because the notification has a flag called new: true which is intended to signal that it should only be sent when the record is first created matching conditions (again, active: true).

In addition to @logeshswell's answer, you could remove that flag to cause it to send any time active is first flipped to true. Maybe that should be the default anyway, but it hasn't been tested.

For example, from the API console:

PUT /:notiications/subscriptions.new { "new": false }

[jezzzm]

awesome, thanks for the detailed info guys. the $notify prop is all i'd need. it's rare cases that we would need to do this so happy to leave the notifications config as is 👍

notification is sent only when an active subscription is directly created from the cart

this should perhaps be a separate question, however: this has made me wonder - we've been creating subscriptions not via cart, but instead via

POST /subscriptions

with checks in place to make sure the user has a default card set and is already logged in.

is there any issue doing this? the reason we didn't use the cart is that we needed to set a specific trial end date in the future, and the cart api doesn't seem to support customising subscriptions on item add. unless i've missed something?

[ericingram]

No issue with doing POST /subscriptions. The cart conversion logic does the exact same thing.

You're right there's no way to specify date_trial_end directly from a cart currently, although you can specify the billing schedule with trial days in case that would work. But either way is fine.