Inventive tools and APIs from ByteScout organize safe files and image handling. Read an extensive information about RESTful API efficient functions and integration.
Zapier is an outstanding iPaaS provider of more than 750 stock connectors to Dropbox, Salesforce, Google Drive, etc. “Webhooks” represents a Zapier connector and has a perfect performance. This is a REST client functionality that improves connection to the system with no need to set up a stock connector. It deals with various HTTP commands within Zapier platform in XML, JSON and FORM.
The article provides exhaustive information about the assimilation between Zapier and ByteScout Cloud API by means of Webhooks connector. When a customer proceeds with document scan containing QR code or barcode, Zapier is able to properly monitor the Dropbox folder where the information is stored. When a new file is detected, ByteScout receives a command to create the barcode/QR Code and returns the read value. The original file is uploaded as a Salesforce attachment to the correct record using the scanned ID from the QR Code.
Reading a Barcode
This use case will assume that you have scanned a document into a Dropbox folder that Zapier can access and that the document has a printed barcode on it. This barcode may have been generated by the ByteScout API but does not have to be – as long as the barcode is in a supported format.
1) The first step, as in all Zaps, is to configure the trigger. In this case, our trigger is Dropbox – New File. We will tell Dropbox which folder to monitor, as shown below.
a) Multiple different file repositories can be used as a trigger, as shown in the Zapbook here.
Helpful security hint: ByteScout needs to have a publicly-accessible URL to access a file. In the case of Dropbox, a “Direct Media Link” is provided, which we will use in our Zapier steps. This Dropbox link expires after a few hours for security purposes, so it is important in your workflow that the document is posted to ByteScout quickly after creation. If you wish to use other services, they need to offer a way to provide a public URL. Depending on the sensitivity of the content, you may wish to ensure those links expire. Similarly, ByteScout links expire after one (1) hour for your security.
2) In our second step, we configure the HTTP request. We are basing this request off of the documentation in the ByteScout support guide found here for the method.
pdfConvertFromUrlPost. We can see that the green highlighted value is a variable, inserted from step #1. If your workflow is more complex, you can use variables from any step in the Zap that comes before the request to ByteScout. Note that the payload type is form; however, other payload types and configurations are supported, depending on the project requirements.
a) Finally, we configure the HTTP headers for the request. In this case, we only need our authorization key which can be found on your ByteScout dashboard here.
b) Now, we can follow the Zapier wizard and test our Zap! Upon successful response, Zapier will parse the entire response payload for friendly use. The response from ByteScout will include helpful information such as the file name and URL. Amongst other things, the confidence of the scan and the scanned value are returned. In our sample, the scan quality was low so the confidence is only ~67%. Due to built-in error checking on the barcode, it was still read and the 67% is representative of how many errors were corrected due to scan quality. That confidence can also be used in future steps, for example only taking specific actions on scans of a certain confidence level.