Webhook Guide
The webhook feature allows companies to receive RFQ’s electronically via an endpoint of their choice. This allows you to easily receive and import RFQ’s into your sales management system, which can save time and speed up processing of enquiries.
Several of our customers have developed systems that process the incoming emails or the XML email facility we offer to automatically import the RFQ’s into their sales order processing system. This webhook facility makes an easy data exchange without the reliability issues of email systems.
If activated, then every time someone makes a RFQ for you, it will be transmitted to an endpoint you define. This endpoint receives the data about the RFQ (part, brand, qty, and who is asking etc) and then your endpoint can process this accordingly.
Technical Information:
The endpoint takes the form of a straightforward POST handler which provides wide compatibility across several systems. With two methods of sending, (A Forms Post, and Json Post) there’s a variety of use cases:
- You could program a web-based endpoint as part of your website and enquiries are directed there.
- You could use a system such as Azure Functions to receive the RFQ’s and process them as you see fit.
- You can use Microsoft Power Automate, to make a code free interface into a variety of connectors including Outlook, Teams, Excel, Microsoft Dynamics.
Unlike a typical API, the webhook sends the data when there is something to send, so it is more efficient than a API where you need to poll regularly to see if there is something to pick up.
We provide examples for:
MVC C#
PHP
Azure Functions
Microsoft Power Automate (formerly known as Microsoft Flow)
There is already a system that allows RFQ’s to be sent as an XML format in an email. This new service avoids the disadvantages of using Email as a transfer medium, i.e., speed, and possibility of messages being quarantined or spammed.
Getting Started
- 1. Create your endpoint to receive the data, and arrange for the onward processing of this data in your own systems.
- 2. Configure the settings in BearingNet
- 3. Use the Test tool to fire some example data at your endpoint and check it works
- 4. Choose your fail over method
- 5. Turn it on.
Settings:
Failover:
– this defines what happens if we cannot communicate with your endpoint.
There are two options – Email and Retry.
Email:
The system will immediately fall back to sending the RFQ by email.
This is the recommended setting. Emails will be sent as if the system is off, though once your endpoint is accessible again, RFQ’s will be delivered via the webhook again. Any missed will have been emailed and will not be resent.
Retry:
The system will try again every minute. This is designed to cover transient problems like a temporary network issue or your endpoint restarting. Note that if too many RFQ’s are backed up (i.e., the problem seems bit more permanent) then our system will change this setting automatically to EMAIL, and the backlogged RFQ’s will be emailed to you.
Enabled:
Use this to turn on and off the function. If you turn it off, the RFQ’s will arrive via email in the normal manner. When on, emails will cease and the RFQ’s will be delivered via the webhook.
Method:
Two choices FORM and JSON
FORM:
This posts through the data as form variables, rather like a standard web form post facility. This provides a lot of compatibility with a lot of systems. You will receive the field data you require using the usual form field functions of the endpoint system you use. For example in C#
string part = Request.Form["part"];
If you use this method, the content type is “application/x-www-form-urlencoded” and sent as a POST
JSON:
This posts through a json string containing the fields. You can then deserialize the json to an object which you can use. It is also compatible with Microsoft Power Automate, so you can use that to define what you do next.
If you use this method, the content type is “application/json” and sent as a POST. The json data is in the data stream.
API Key:
This is a unique code which you can use to verify the messages sent from us. See the security section.
Endpoint URL:
This is the web URL to which we should connect. This address should service the post call which we will make to it.
Security:
By nature, the webhook system offers a degree of security as we call the address you specify. In the unlikely event of someone discovering your end point they would be able only to fire in RFQ requests. If you desire additional security, you can also take additional steps as follows:
SSL:
We recommend you force your webhook to use https.
SSL:
We support request signing, which allows you to verify the call. We pass through 3 fields, a signature, token and timestamp. Validation of any messages received can be achieved by taking the timestamp field, concatenating with the token fields, and hashing it using HMAC SHA256 – (see example). The results should equal the signature, and if not, reject the request. The API key is used in this process, which is secret and not transmitted, just known to both ends.
An C# example of such a function is below:
private static bool Verify(string apikey, string token, string timestamp, string signature)
{
var hmac = new HMACSHA256(Encoding.ASCII.GetBytes(apikey));
var sigBytes = hmac.ComputeHash(Encoding.ASCII.GetBytes(timestamp + token));
string sigString = BitConverter.ToString(sigBytes).Replace("-", "");
return signature.Equals(sigString, StringComparison.OrdinalIgnoreCase);
}
Obscurification:
It does not need to be hosted on your main website domain – you can host it on a separate domain or use a complicated path which is not obvious
IP Filtering:
Depending on where you host your endpoint you may be able to limit the IP address that calls it. Our IP address may change without warning, but we would expect it to be in this range:
104.46.38.91,104.46.38.110,104.46.35.12,23.97.218.73,40.118.94.18,13.69.28.9,13.69.30.222,13.69.27.121,137.117.144.51,104.46.44.78,13.69.68.73
Things to Consider:
If your application has an error, then your data may be lost. To this end we provide a test screen to make it easier for you to test your webhook integration.
If you receive a lot of RFQ’s, then you will receive a lot of webhook calls. Make sure this will not trigger any DDOS protection your endpoint has.
Fields:
If you receive a lot of RFQ’s, then you will receive a lot of webhook calls. Make sure this will not trigger any DDOS protection your endpoint has.
Example Code
You can view our example code below ...
Here is a simplified example for c# MVC ASP.net
public ActionResult BNWebHook(FormCollection oColl)
{
string part = Request.Form["part"];
string brand = Request.Form["brand"];
string qty = Request.Form["qty"];
string token = Request.Form["token"];
string timestamp = Request.Form["timestamp"];
string signature = Request.Form["signature"];
//Validate signature
//Process data
}
Microsoft Power Automate
Microsoft Power Automate (previously Microsoft Flow) can receive the webhook call allowing you to handle the data and pass it on to any system supported by Power Automate. For example, you could pass the data onto a Microsoft Teams Channel, write it into an Excel document, or a google Sheets document, send an SMS, or several things together. There are connections to Microsoft Dynamics – which may be of interest to our customers.
Here’s a small range of the components you can talk to.
Here is an example where by on receipt of a RFQ Webhook call from BearingNet, the system will post the data in an email.
To create a flow, you will need access to the premium version of Microsoft power automate.
1) Create a new flow
2) Use the connector “When a HTTP request is received”
Add the following code the Json Body Schema:
{
"type": "object",
"properties": {
"Part": {
"type": "string"
},
"Brand": {
"type": "string"
},
"Qty": {
"type": "string"
},
"CompanyRef": {},
"CompanyCode": {
"type": "integer"
},
"CompanyName": {
"type": "string"
},
"Country": {
"type": "string"
},
"CompanyEmail": {
"type": "string"
},
"ContactName": {
"type": "string"
},
"CompanyPhone": {
"type": "string"
},
"RequiredText": {
"type": "string"
},
"RequiredValue": {
"type": "string"
},
"Notes": {
"type": "string"
},
"Custom1": {
"type": "string"
},
"Custom2": {
"type": "string"
},
"Custom3": {
"type": "string"
},
"TimeStamp": {
"type": "string"
},
"Token": {
"type": "string"
},
"Signature": {
"type": "string"
}
}
}
3) Copy the HTTP Post URL. Paste this URL into the Endpoint box in the webhook configuration setting in BearingNet
4) Set the method to JSON
5) Set the failover mode to your choice of mode.
6) Back in the flow, add the next step of your choice
7) Configure that step according to its requirements. Where you need to put in information from the RFQ, the data picker will appear and you will see the RFQ fields available to add to your connector
8)For example – the notification connector:
Or for a email:
10) You can use the test facility to test the webhook. On the webhook page in BearingNet enter some information and press send. Check that your endpoint processes it satisfactorily.
11) Once you are happy, turn on the webhook in BearingNet
12) If you have any issues, simply turn it off and RFQ’s will be sent by email again