MMPY-172 SPIKE Research NewRelic webhook events

- source :: https://multimediallc.atlassian.net/browse/MMPY-172

- epic :: MMPY-198 Compliance Holds, Fraud Holds, and Banned Payees

- tags :: Falcon Nest Project Falcon Nest Project Spike

- status :: Status - Complete

DONE Research NewRelic hooks

researchmultimediallcworkspike

ID: 25c036e7-5f1e-d309-0012-f1e3d17bdc68

- Note taken on Mon Jun 30, 202511:59

Looks like setting up Webhooks should be pretty easy:

https://docs.newrelic.com/docs/alerts/get-notified/notification-integrations/#webhook

The upshot is that we'd need to:

1. Setup a way to create a bearer token that we would then send in a header from the NewRelic webhook configuration.

2. Decide on an event template for our use case and configure it in the NewRelic webhook admin.

3. Setup a view in Nest to accept the NewRelic endpoint.

The biggest hurdle to getting started is not having NewRelic webhook creation access, and needing something like Ngrok setup to make sending webhook to local dev possible.

Questions

How does NewRelic format webhook events?

Short answer is, we setup our own template for a given notification. I am not fluent in NewRelic dashboards, but I bet someone is. We'd need to send the alert that an account was Active but not processing and offer an action that would dispatch the custom webhook template with the account ID and using a valid bearer token.

How does NewRelic handle authentication and authorization?

The easiest method would be to configure a bearer token that is setup in Nest settings and configured in the NewRelic webhook as a header sent with every webhook.

More complicated, but also more secure, we could use an HMAC signature with each webhook that would encode the timestamp of the event with a secret key. The major benefit here would be ability to know when a request came, but that seems like fringe-to-no benefit here.

How can we make authz/authn generic but built around NewRelic?

I don't think that we need authorization. And ChatGPT holds up the notion that Bearer tokens are probably sufficient for this use case:

"Conclusion: Bearer tokens are sufficient for most webhook setups, especially

where New Relic is the only caller and your endpoint is not public-facing."

We could also build out a small webhook bearer token Django app that could take an application name and generate a token for it. This could also include an expiration date and a warning as that date approaches that could send slack/email notifications to an admin account and ask you to update the tokens.

This is probably overkill fora v1 of a simple webhook which, when the correct payload and bearer token are sent, moves a given account from "Active but not processing" to "Active." There is very little sensitive information passing thorugh here and the consequence of this being abused seems minimal.