0 credits and never processed an image, plus some suggestions. Answered

I am currently integrating this sdk with our product. I have received an error today that I have 0 credits and "license expired". I have never processed a page. Yesterday the images were queued for a long long time and never processed. I think this sdk has great potential. Some suggestions:

1.) health check method - you may have this already, please post a method to determine the status of the service. I would rather not process my customers documents or put them in the queue if the service is down.

2.) queue wait time - there appears to be some latency between submission and actual processing. If we had an estimated wait time, it might be better for my users to determine if they want to process or wait.

3.) account information - you may have this already, if my customers want information about how many "credits" are left in their account, this would be helpful.

Again, this looks like a promising sdk. Thanks.

Was this article helpful?

0 out of 0 found this helpful



  • Avatar
    Dmitry Mesheryakov

    FYI - "license expired" message was a temporary problem with the service internals. That problem has been addressed and the service is now fully operational.

  • Avatar

    Yes. It is working now. Thanks.

  • Avatar
    Andrey Isaev

    We encourage you to use UserVoice for feature request submission and voting for them. It will help us to prioritize feaure request better way (there is always long list of things you know you should do, but you have to prioritize anyway).

    Few suggestions according your requests

    1) We are struggling hard to make sure service has near to 100% uptime, but this is the cloud world, and outages happens even for long time established players like Google and SalesForce. Hoewever, it is easy to check if service is up - if it responds to requests then it is up. But what you are trying to solve is to check if queue is short enogh - that is different story. We are not going to provide public access to overal system queue length, since it is a security hole. We are taking different approach. What we are implementing is priorities management, so even if queue is filled by tasks from one customers, others are not affected. It is partially implemented, but not perfect yet. This is still high priority task for us, and you will be able to see improvements quite soon.

    2) There is special parameter in response format specifically for that purpose - estimatedProcessingTime. Currently it is more like a placeholder, but making it real it is not very far in our roadmap.

    3) I can imagne different scenarios.

    • All customers use same account on In this case it looks more like a security breach if customers are allowed to see how much pages is still on common account. In this case it is developer who should be responsible for checking account. Typically it will be enough to watch for service notifications to your e-mail.
    • Every customer creates his own account on In this case they will enter their own e-mails and will be able to check balance online and will receive service notifications if balance is running low.
    • You want to charge your customers yourself directly and let them have separate counters. We are developig special mode for that - using "serial numbers". You still have one account, but you can generate multiple serial numbers each with it's own page counter. Yes, in this case there will be special API to check amount of pages on the SN counter, since customers won't have access to your account directly. This functionality is in early beta, and if you are interested - please contact
  • Avatar

    Dear CloudZap,

    You were affected by the ABBYY Cloud OCR SDK service failure occurred yesterday.
    We apologize for potential impact to your business and thank you for your patience. The problem has been already resolved, please see the details below.

    Issue summary

    1. ABBYY Cloud OCR SDK service was not properly working from 0:00 to 14:50 of July, 1 (UTC). The failure occurred because of a bug that was not caught by our testing system. The service actually was not completely down, but returning an error while processing pages, that’s why the failure was not caught by service health monitoring system.
    2. Along with this bug, ABBYY Cloud OCR SDK scaling system had a glitch, that’s why some of you could see a delay in recognition tasks processing.

    Corrective and Preventive measures taken by ABBYY Cloud OCR SDK team

    1. The bug in the code was fixed on July, 1 (Sunday).
    2. Currently our development team is working on improvement of our Testing and Service Health Monitoring systems to catch such kind of service failures in the future.
    3. The auto-scaling system will be tested again to find and eliminate the reason that caused the problem. Along with that we are going to implement additional tasks’ priority control functionality in the nearest future to isolate particular user’s processing performance from peak loads generated by other users.

    Please be assured that system reliability is a top priority at ABBYY, and we are making continuous improvements to make our service the best on the web.

    Sincerely yours, Alsu. ABBYY, Marketing manager, SDK products.

    PS: This was the first serious failure since the service started its work on Feb, 2012 (Public Beta).


Please sign in to leave a comment.