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

Sparkpost api changing #34

Open
TomCrawshaw opened this issue May 8, 2019 · 7 comments
Open

Sparkpost api changing #34

TomCrawshaw opened this issue May 8, 2019 · 7 comments

Comments

@TomCrawshaw
Copy link

Hi,

This is a great extension, so please could you confirm that it will be updated to use the latest Sparkpost api, as the Message Events API is being withdrawn in October (email received from them 8th May 2019):

"SparkPost Product Update
Hello,
This is an operational notice that we are discontinuing the Message Events API on October 1, 2019. Starting on October 1, all API calls made to SparkPost must use the Events API. You are receiving this email because our data shows that the Message Events API is currently being used by your account.
Events Search’s robust searching capabilities provide ready access to the raw event data associated with the messages you send via SparkPost."

Thanks.

@herbdool
Copy link

herbdool commented Jul 2, 2019

The fetch bounce functionality is using the deprecated Message Events API. https://github.com/proexchange/com.pesc.sparkpost/blob/master/api/v3/SparkPost/Fetchbounces.php. Any plans on updating? Or do you recommend people use the CiviDesk version?

@joseltorres
Copy link
Contributor

We will eventually update. I think you can however you a combination of the cividesk extension the transactional email extension to accomplish the same result. I have not tested this, but it's an option.
https://github.com/fuzionnz/nz.co.fuzion.transactional
https://github.com/cividesk/com.cividesk.email.sparkpost

@herbdool
Copy link

herbdool commented Jul 8, 2019

Thanks @joseltorres, we might switch to the other extension. We've had debates on our team on whether to standardize on this extension or the other one. It's a bit of a time waster considering each extension does basically the same thing. Would be good to combine forces.

Regardless, perhaps this is the only change needed in FetchBounces.php (I haven't tested):

$ch_api ='https://api.sparkpost.com/api/v1/events/message?events='.$params['events'].'&from_addresses='.sparkpost_getFromAddresses();

@joseltorres
Copy link
Contributor

We both happened to develop extension at the same time without knowing the other was developing it. We'll be working on making updates for this and other items later in the summer (Aug-Sep).

@herbdool
Copy link

Hi @joseltorres. Just checking to see if you'll be updating this extension with looming deadline of the API change.

@davyrhys
Copy link

Thanks @joseltorres, we might switch to the other extension. We've had debates on our team on whether to standardize on this extension or the other one. It's a bit of a time waster considering each extension does basically the same thing. Would be good to combine forces.

Regardless, perhaps this is the only change needed in FetchBounces.php (I haven't tested):

$ch_api ='https://api.sparkpost.com/api/v1/events/message?events='.$params['events'].'&from_addresses='.sparkpost_getFromAddresses();

Hi @herbdool - did you ever test this suggested patch?

@herbdool
Copy link

@davyrhys I have not. We switched extensions for one client at least. Have you tried it out?

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

4 participants