Beeminder Forum

Beeminder webhook integration for derailing notification in Zulip


#1

Hello,
I am working on developing a Beeminder webhook integration for zulip. Back at zulip, we have a possibility that we get the user details using his/her email id. But while checking out the Beeminder API documentation, specially Webhook section, I analyzed through various Payload-variables that are passed by the Beeminder API webhook as a part of the “Derailing JSON object” to the user specified URL. However, is there any particular parameter that lets me get the user email id (not SLUG) of the user who has set up the goal? This would be a great help. Kindly let me know.


#2

Hmm, I guess not! Should this definitely be available in the API? Any privacy concerns? If a user authorizes an app to access their data on Beeminder should that include their email address? If so, maybe it should be part of the User object?

Either way, could we hear more about your use case? Thanks so much for building stuff with the Beeminder API!


#3

I am developing a webhook integration for zulip to notify whenever a derail JSON object is triggered by Beeminder by specifying the URL in goal’s settings. However, on the zulip side, the webhook integration(which I am presently working on) needs to know the email id of the user to send him a Personal Message telling him about his derailing information. For this purpose I needed email id because without the email id I cannot identify as to which user to send the Personal Message. Can you please help me with getting things working on the Beeminder API side?


#4

If I understand zulip rightly, this integration would be similar to slackminder, in which case I’m surprised that emails are needed, rather than token-based authorisation from both sides. It seems an odd design choice by the zulip folks.

Update: glancing at their API docs, it does seem true. My first suggestion would be that my sign-up / authentication with zulipminder would include telling @diptanshu my zulip email address, because it might not be the same as my Beeminder email!

@dreev: This might be the point at which we want to introduce more granular permissions. Most other applications don’t need personal information to do something useful. Similarly, permission to work with my public goals could be segregated from permission to even see my private goals. Can of worms, I admit.


#5

Personally, I don’t use the same email address for any two services, so my Beeminder email address would be different from my Zulip email address.

Even people with more consistent addresses often have personal and work email addresses that get used to sign up to different services at different times.

I think that your best course of action is to ask your users for their zulip email address at the same time that you’re asking them to authorise your app in Beeminder.


#6

@philip I totally agree with the possibility of users having different email ids for different services. In that case the only work around that could be imposed is to give a ?email=<xyz@example.com> in the Webhook Post URL.
The main reason I raised this topic was to have a clear clarification as to if such a configuration to obtain user email id is possible in Beeminder API’s Webhook derailing alert JSON object. So, the email id cannot be obtained at this point of time, right?


#7

correct.


#8

Hi, folks. My name is Steve, and I work on the Zulip project. My colleague, Sumana, is an enthusiastic user of Beeminder, and she proposed that we write a Beeminder integration for Zulip. Diptanshu is a new contributor on the Zulip project and has been attempting to write the integration, as you can see from the prior discussion on this thread.

Zulip is a chat program, which for the purpose of this discussion is pretty similar to Slack. We support many integrations currently, so, for example, if I have a Github account, I can automatically configure GIthub to send info about my commits and issues to Zulip to post on a public “stream” on Zulip, where “stream” is just another word for “channel.”

The challenge that Diptanshu is facing with Beeminder now is that we need some way for Beeminder to identify to Zulip which user it’s sending information for, in a secure way, so that we can direct Alice’s Beeminder activities to Alice’s private message stream and so that we can direct Bob’s Beeminder activities to Bob’s private message stream. Furthermore, if either Alice or Bob wants their goals to be public, we want them to be able to direct their Beeminder activities to some public stream on Zulip that would probably be called “beeminder.”

For the first problem the thing that would make our life easy is for Beeminder to supply the user’s email in the payload that Beeminder sends to Zulip. Since Beeminder authenticates a user’s email before allowing them to invoke the webhook mechanism, we would be able to treat that identification mechanism as secure and accurate.

We also want the user to supply Zulip with some notion that they want their Beeminder updates to go to a public stream/channel as well. That can probably be handled by having the user configure the URL, correct? Unless there is already a notion within Beeminder of whether your goals are “public,” and then this should be a field within the payload.

What are the barriers to including email in the webhook API on the Beeminder side of things?


#9

The challenge that Diptanshu is facing with Beeminder now is that we need some way for Beeminder to identify to Zulip which user it’s sending information for, in a secure way, so that we can direct Alice’s Beeminder activities to Alice’s private message stream and so that we can direct Bob’s Beeminder activities to Bob’s private message stream. Furthermore, if either Alice or Bob wants their goals to be public, we want them to be able to direct their Beeminder activities to some public stream on Zulip that would probably be called “beeminder.”


#10

Zulip now has a Beeminder integration (in its master branch – probably not yet deployed to zulipchat.com) – looking forward to seeing feedback on that from Beeminder users.