<blockquote>
<p>AFAIK, we currently don't an API to support this use case.</p>
</blockquote>
<p>Yes, we would need to add an API either for messages, or for a more unified notifications system.</p>
<blockquote>
<p>Would you think it makes sense to follow up on the proxy email concept I outlined earlier on?</p>
</blockquote>
<p>I'm not sure about this approach. We would then end up with a third party calling our API, to receive a proxy email address, that they then create and send emails to, in order to create messages in our API programmatically via emails, which need to be queued and parsed and acted on internally. That's instead of creating a message or notification directly via an API call. It seems a bit indirect to me, and it makes some things (like rate limiting API calls) harder to manage. If all we were doing was accepting messages and/or notifications then it would make more sense, but each client app will already be using our API anyway.</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/openstreetmap/openstreetmap-website/pull/1431#issuecomment-454846187">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/ABWnLUq2q5Cx6g1V8eeeb3NMwUp3Byh4ks5vD1RDgaJpZM4L7ara">mute the thread</a>.<img src="https://github.com/notifications/beacon/ABWnLbVY64eLx_UB6nlFbPBVF9JkyH6Zks5vD1RDgaJpZM4L7ara.gif" height="1" width="1" alt="" /></p>
<script type="application/json" data-scope="inboxmarkup">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/openstreetmap/openstreetmap-website","title":"openstreetmap/openstreetmap-website","subtitle":"GitHub repository","main_image_url":"https://github.githubassets.com/images/email/message_cards/header.png","avatar_image_url":"https://github.githubassets.com/images/email/message_cards/avatar.png","action":{"name":"Open in GitHub","url":"https://github.com/openstreetmap/openstreetmap-website"}},"updates":{"snippets":[{"icon":"PERSON","message":"@gravitystorm in #1431: \u003e AFAIK, we currently don't an API to support this use case.\r\n\r\nYes, we would need to add an API either for messages, or for a more unified notifications system.\r\n\r\n\u003e Would you think it makes sense to follow up on the proxy email concept I outlined earlier on?\r\n\r\nI'm not sure about this approach. We would then end up with a third party calling our API, to receive a proxy email address, that they then create and send emails to, in order to create messages in our API programmatically via emails, which need to be queued and parsed and acted on internally. That's instead of creating a message or notification directly via an API call. It seems a bit indirect to me, and it makes some things (like rate limiting API calls) harder to manage. If all we were doing was accepting messages and/or notifications then it would make more sense, but each client app will already be using our API anyway.\r\n"}],"action":{"name":"View Pull Request","url":"https://github.com/openstreetmap/openstreetmap-website/pull/1431#issuecomment-454846187"}}}</script>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/openstreetmap/openstreetmap-website/pull/1431#issuecomment-454846187",
"url": "https://github.com/openstreetmap/openstreetmap-website/pull/1431#issuecomment-454846187",
"name": "View Pull Request"
},
"description": "View this Pull Request on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>