There is an API available for reading OMR & ICR. You pass input of sheet image and some parameters in API, and it returns text string of read data or it returns error code if sheet input is invalid.
Upon API call, the Addmen OMR software will evoke automatically at backend, it is not required to start the Addmen software separately.
It is not required to share the OMR interface with client. The Addmen OMR interface will be used only by your software admin to make the settings and preferences according to sheet layout to be used. Access to Addmen OMR software can be kept password locked.
You need to buy Addmen OMR API addon only once for one client ID and integrate it in your software product. Then you can distribute as many instances of your software. There is no need to pay the API cost for every instance of your software.
To serve the API call you will need Addmen OMR setup with requisite modules installed on the computer where the backend OMR engine will be used. Every instance of the backend OMR engine will need one license of Addmen software with requisite modules.
In any integration using API, we expect to pass an input as an image and get the output string in return.
What about the sheets that are not a perfect input?
If some inappropriate sheets are read using an API (that does not provide an in-between interface), the only option for the API is to return a "Negative" output like faliure code. So some sheets will remain unread, because there is no provision to make minor "in-process" changes and make the sheet readable.
But the Addmen OMR software has quite some smart logic, that can still make this unreadable sheet and then show you the amended image and its read data on-screen for manual glance and approval and proceed further.....in this way most of the problematic sheet inputs are still read.
Just an API will not provide the opportunity to make provisional corrections or judgements in between the process. Then the OMR Software will simply return a faliure code, which minimizes the potential of the OMR software.
Total OMR Reading process is more than just Input and Output.
Further, it is important to understand, when you use an API to fetch the data, the API merely acts as a command and the backend OMR engine responds with the output string of OMR data.
In one instance of a API command, only one file handle is passed as an input and one corresponding output string is received. You have to pass each file individually and receive the data of each file in the string. If there are multiple files, same process is done in a loop.
So when you use API, it becomes the task of your front end software to develop logics and interfaces for file and folder selection and sorting or renaming of read, unread and failed files. While in the Addmen OMR's interface, all these necessary file handling logics and interface are available readymade.
Because of these reasons use of interface has its advantages, unless your developer team is ready and equipped to develop a substantial part of file handling themselves.
The best and most optimal approach is to use the software interface to read sheets and fetch your required data from the SQL database for your further processing. In this way, versatile potential of the software can be fully utilized.