Jiwa

Is there any documentation on web hooks?

And is there a user interface for setting up subscribers?

SBarnes wrote:Is there any documentation on web hooks?

And is there a user interface for setting up subscribers?

Hi Stuart,

We have an article on our docs page relating to webhooks.

There as yet is no user interface for adding subscribers and subscriptions, but there are API routes to manage subscribers, subscriptions and messages - even though the docs don't explicitly show how to manage subscribers (it does show subscriptions & messages) - the SwaggerUI does show how to manage subscribers... We'll have to update the docs to include subscriber management (the docs show how to manage subscribers via an SQL Insert but that's not ideal as it requires a service restart - but using the API does not require a restart).

Mike

Are there any plans to support incoming web hooks something akin to receivers in https://github.com/aspnet/AspNetWebHooks/tree/master/src ?

Hi Stuart,

As you already know, creating a plugin to extend our standard API and add a route is pretty simple. We hadn't intended on adding a suite of routes to handle things like MailChimp, Salesforce, and so on - because it is so simple to add a route, and whatever handler we provide, the logic / mappings won't suit everyone - so we think it best to leave this as bespoke plugins.

Have I interpreted your question correctly?

Hi Mike

What I am referring to is something like SalesForce or Zapier making an incoming webhook call that is not ServiceStack related, how would the web api (ServiceStack) interpret a post given the data/payload in not going to be a strictly typed object but Json or XML i.e. what type of function signature on a service class then would ServiceStack route correctly?

SBarnes wrote:the data/payload in not going to be a strictly typed object but Json or XML

Both Json and XML represent a data transfer object - so you just create a DTO type which fits the shape of the Json/XML you expect to be POSTed to the route.

ServiceStack at the server side doesn't route anything based on the type - when adding a route for a POST operation you specify the URI and the type you want the POST body to be deserialised into:

Code: Select all

AppHost.Routes.Add(typeof(CreateDebtorFromSalesForceRequest), "/Debtors/CreateFromSalesForceCustomer", "POST", "Creates a debtor from a SalesForce customer creation webhook", "");

Whatever Json or XML is provided in the body will be deserialised into an instance of the CreateDebtorFromSalesForceRequest DTO - which would simply be the properties of the sales force customer.

I still feel like I'm missing something in your question... perhaps you could give a specific example of something you cannot get to work?

How would you handle the need to send an acknowledgement back?

Here's and example of where the asp.net webhooks do it to continue your SalesForce analogy https://github.com/aspnet/AspNetWebHooks/blob/master/samples/SalesforceReceiver/WebHooks/SalesforceWebHookHandler.cs

Further to this how would the incoming hook end up with a logged in manager to work with, as the only way I am assuming you could do it is with an api key as part of the query string held by the sender as username and password are definitely not going to work?

SBarnes wrote:How would you handle the need to send an acknowledgement back?

We don't. The response should contain any ack info needed - a request back to the instigator of the webhook isn't something I'm aware of as a standard practice.

SBarnes wrote:Further to this how would the incoming hook end up with a logged in manager to work with, as the only way I am assuming you could do it is with an api key as part of the query string held by the sender as username and password are definitely not going to work?

Web hooks are an outbound only concept - so in the context of Jiwa, our webhooks are ways to communicate things out of a customers Jiwa environment to a 3rd party API.

All our routes can accept API Keys as a URL parameter, or as a HTTP bearer token which is simply a header in the request - so our routes can be receivers for webhooks from a 3rd party API, if they provide an API key in the request.