Spark is what generates this very simple DSL for the WebhookHandler module:
defmodule MyApp.StripeWebhookHandlers do
use PinStripe.WebhookHandler
handle "customer.created", MyApp.StripeWebhookHandlers.CustomerCreated
handle "customer.updated", fn data ->
// do stuff
end
end
That part is actually not in the Dashbit blog. They just do:
defmodule TeamsWeb.StripeWebhookController do
use TeamsWeb, :controller
plug :verify_signature
def create(conn, %{"type" => type}) do
# ...
end
defp verify_signature(conn, []) do
# ...
end
end
… the idea being that a dev reading it knows “ahh, I put some handling code in the create function.”
Whereas PinStripe’s WebHook controller is literally just this:
defmodule MyAppWeb.StripeWebhookController do
use PinStripe.WebhookController,
handler: MyApp.StripeWebhookHandlers
end
That injects all the sig verification code from the Dashbit controller and forwards webhook events to the WebhookHandler module.
So PinStripe is more opinionated, but it saves some fussy setup.
It’s actually possible though that the handle "stripe.event" ... DSL could just live right there in the controller though 
Then it would just be:
defmodule MyAppWeb.StripeWebhookController do
use PinStripe.WebhookController
handle "customer.created", fn(data) -> ... end
handle "customer.updated", MyApp.StripeWebhookHandlers.CustomerUpdated
end
Might do that! Not sure there’s a need to have the handler declarations live in a separate module. It would save a bit of indirection.
