Webhook trigger
Last updated
Last updated
Use webhook trigger to create an https endpoint (webhook), such as https://flintit.novacura.com/t37ed/CreateCustomerRecord, that can be called (using http methods Post or Get), optionally with query parameters and optionally with a body of any type, for integrations that should be to triggered to run on such an event with those parameters and body as input.
Example use cases:
event triggered data synchronizations as the inserts or updates of records in some data source
event triggered business transactions between companies, such as sending and receiving work orders, logistical messages etc
providing a query endpoint for some consumer, for example an item price query, or a stock at hand query
When setting up a webhook trigger for your integration you start with the following page:
Click the button Add authenticaiton, if you don't want a completely open webhook that anyone can call (normally you don't want that).
In the dropdown that appears, choose the type of authentication among the following:
ApiKeys
Click the button Add New Key.
In the popup window that appears
fill in a label for your api key in order to recognize and differentiate it from other api keys for the same integration (in case you have more than one consumer of the webhook).
Click the button to generate a new random key, or paste a key of your own.
Tip: by copy-pasting in the api key from another already existing webhook trigger, one that is used by the same consumer, you can enable the consumer use and manage only one key for several webhook triggers that you provide.
Click the button Add
You can repeat this procedure to add, change (the label) and delete as many api keys as you need.
Having more than api key is usually the case when you have more than one consumer of the webhook trigger.
Now select whether you want the webhook trigger to have so called Ordered Delivery or not. Ordered delivery means that messages coming to the webhook trigger will be handled and executed exactly in the order as they are received. This is can be useful for two reasons.
One reason being that there is some semantic relationship between messages and their order, that must be kept. Such as one message having information that builds on the previous and so on.
Another reason being that one or more of the systems that the integration (the machine workflow) connects to during execution are of a nature that they cannot handle the amount of connections or messages that would result if the messages are handled unrestricted. I.e. a sort of "throttling".
Now select whether you want the webhook trigger to be of so called Request-Response pattern or not. Request-Response means that a call to the webhook trigger will not return until there is a resulting response from a completed execution, or a maximum amount of time elapses and a time-out occurs.
Request-Response checked is useful if you have an integration that whose response is necessary or useful to the consumer. For example the resulting id of a created work order. It is also useful when providing a query endpoint for some consumer, for example an item price query, or a stock at hand query.
Request-Response unchecked is useful, when a direct response is not needed. It will speed up message dialogs considerably. In this case The result from
Now click the button Add query parameter if you want to enable query parameters in your webhook trigger for your consumers. If a configured query parameter is not sent a default value can be specified.
By doing this your webhook can take incoming data in form of
Note: Data coming through query parameters can and must be used in the data processing of the integration in order to be passed on to the machine workflow. More on that in the later chapter.
You webhook integration should now look something like below and you are ready to click the Save button to create it.
