Fair use

On this page

• 1. The principle
• 2. What is fair
• 3. Technical limits
• 4. Files and result
• 5. Jobs and queries
• 6. S3 bucket
• 7. Free test
• 8. Retention
• 9. What is not fair
• 10. What we do
• 11. Needing more

This is a translation; the German version is binding. Read in German (Fair-Use-Regeln)

Version 2026-11-08

This page describes what we regard as fair use of the hosted service that we run (the API of ocr-software.com) and what we do when someone goes past the limits. It is part of the SaaS terms. It does not apply to the package on your own server; the EULA applies there. It is not a promise that the service is available (SaaS terms, section 2).

1. The principle

The service shares limited compute. Use is fair when it does not push other users aside, does not endanger the service and matches the purpose the service exists for: text recognition for documents that you have the rights to.

2. What is fair

• You read your own documents and test pages, even many of them, at a pace that the limits in section 3 carry.
• You respect the answer 429 and wait for the time that Retry-After names before you try again.
• You use one key for one company or project and do not pass it on.
• You build the API into your applications. Services for your own customers in which OCR is one part are fine.

3. Technical limits

These limits apply per order unless noted otherwise: the main key and sub-keys of an order count together, so that more keys do not mean more load. For free keys a limit per network (IPv4 /24, IPv6 /64) applies in addition, so that many free orders from one network do not add up to one load; paid orders are not limited by the network. When the service answers 429, the error object names the limit that was hit (under limit), its value and the current level; the text says whether it was "this key", "this order" or "this network".

For the name max_jobs_per_key (all jobs of the order are unfinished; uploads count too): first collect the result of a finished job or wait until one is finished, then send again; Retry-After only tells you when you can try again at the earliest. The status query is meant for monitoring, but not every second from many places behind the same address; poll at the pace the limit allows.

An upload is the call POST /v1/jobs that transfers your file: from the first byte until the service has checked the document (type, size, number of pages) and answers with the job ID. That period occupies an upload slot, because during it the file sits in the service's intake buffer, where room is scarce; this is why each order may run only 2 uploads at the same time, and the whole service at most 8. With the job ID the job begins; it no longer counts as an upload but waits in our queue until its turn. That is why 8 jobs can run at the same time even though only 2 files may be in transit at once. So do not send more files at the same time than the table allows, and collect the results by job ID.

A third upload at the same time gets 429 (too_many_uploads); when the whole service is busy it gets 503 (busy). Every 429 and every 503 busy carries Retry-After with the time in seconds; wait that time and then retry.

We may change these values, for example when load demands it. A contract with us may provide higher values.

4. Files and result

These limits protect the intake buffer and the memory of the service and keep every result checkable.

• Allowed types: PDF, PNG, JPEG and TIFF. No BigTIFF, no archives.
• Size: at most 100 MiB per file; for a PDF at most 10 MiB per page (file size divided by the number of pages); for an image or a TIFF page at most 10 MiB; at most 1,000 pages per document. You split a larger document yourself and send the parts as separate jobs.
• Transfer: an upload must reach at least 128 KiB/s on average, after a start-up time of 15 seconds, which also applies to the longest single stall. Slower uploads get 408 (upload_too_slow), so that a hanging upload does not hold one of the few slots.
• Checking: if the check of a document has to wait more than 20 seconds for a free slot, the upload gets 503 (busy) with Retry-After.
• Resolution (dpi) when a PDF is rendered: 150, 200 or 300 (default 150); any other value, 600 included, gets 400 (invalid_dpi).
• Time: a page may take at most 60 seconds to render, a whole document at most 30 minutes; the pixel limit per page is in section 3.
• Result: at most 20,000 lines per page, 2,000 words per line and 2,000 layout regions per page; words over 1,000 characters are cut. At most 50 tables per page are recognised; a table has at most 500 rows or columns, 250,000 rows times columns, 20,000 cells and 2,000 words per cell. If a page passes one of these limits, that one page is failed, never the whole document.

5. Jobs and queries

These limits make retries safe and keep polling light.

• Idempotency-Key: up to 255 characters, valid for 24 hours; client_ref: up to 200 characters.
• Long polling (wait): at most 60 seconds; a larger value is an error.
• Job list: 100 entries per page unless you say otherwise, at most 1,000.
• Order: up to 50 keys per order.

6. S3 bucket

A run reads one object after the other so that it does not push other users aside; the restriction to public addresses protects our network.

• Any S3-compatible bucket, over https only, public addresses only, no redirects.
• The source is read anonymously only if you set that explicitly. The destination always needs keys.
• Before the start the service lists the source folder up to the first object (15 seconds); wrong credentials or an unreachable bucket fail at once with 422, and no run starts. The request itself is at most 64 KiB large; the job ID has 1 to 64 characters.
• Source and destination folders must not overlap. Presigned URLs are not accepted.
• What is read: objects with the extension .pdf (upper or lower case). All other objects, such as images or TIFF, are skipped when listing: not read, not counted, not in the manifest. An object with the extension .pdf that is not a PDF is entered in the manifest as failed with unsupported_type; the other objects carry on. A mixed bucket is therefore possible, but only the PDF files are recognised.
• What lies in the destination folder: one file per object and chosen format, named <destination folder><path from the source folder><extension> with the extension .json, .txt, .md, .hocr or .pdf (a/b.pdf becomes a/b.pdf.json, so x.pdf and x.PDF never collide). An output key over 1,000 characters makes that object failed (output_key_too_long). In addition manifest.json: job, pipeline, formats, status (complete or incomplete), stop reason and, per object, key, ETag, size, status (done, partial, failed), page counts, error code and output files. It holds only names and numbers, never content, and is written every 20 objects and at a stop, an abort and the end.
• A second run on the same destination: with the same job ID the service resumes from the manifest. Objects that are done or failed for good and have the same ETag are not read again; objects with a temporary error (store_error, gone, timeout, internal_error) and pages that did not run are repeated; a changed ETag makes the object run again. Finished pages are not charged twice. If the destination folder holds the manifest of another job, another pipeline or other formats, the run fails with output_prefix_conflict and overwrites nothing. If the manifest is lost, everything runs again, but without double charging.
• Limit per run: at most 100,000 objects and 30 minutes per object. The .pdf objects are counted in listing order (S3 returns them by key), including those already done. At the first object over the limit the run stops hard: nothing more is read, everything before it is finished and charged, the manifest is incomplete with the stop reason max_objects, and the status query shows incomplete. For the rest you need a new run with a source folder that holds only the remaining objects (a subfolder, say); the same source folder ends at the limit again.

7. Free test

The free test on /try/ lets visitors without an account try one page without pushing paying users aside.

• One page per call, as PNG or JPEG, at most 32 MiB.
• At most 6 pages per minute and address. When the test is busy you get 503 (busy) with Retry-After.
• The page is deleted after it has been read.

8. Retention

We keep data no longer than we must or have promised.

• A finished result stays retrievable for 24 hours (section 3).
• Bookings (pages and amounts, never content) are kept for ten years from the end of the booking year, because commercial law requires it.
• Full client addresses are kept for 7 days; the per-network counters hold only the network range, not the address (window 30 days, section 10).
• The confirmation link in the order mail is valid for one hour; you receive it yourself. The portal link is a different one: our support issues it, and it is valid for 24 hours by default, seven days at most.
• A request without a contract is kept for 183 days (six months).

9. What is not fair

• Using several keys, accounts, addresses or networks to get around the limits.
• Reselling the service as your own OCR interface (access for a fee that consists in essence of our API).
• Constant load without agreement that noticeably slows other users down.
• Attempts to read out models or weights, to send malware or to overload the service.
• Any use that breaks the law, including sanctions and export law.

10. What we do

• Order: Pages of users who have not paid may wait behind pages of users who have. We aim for one hour at most; the time is not promised.
• Limit per network: For users who have not paid, a limit per network (IPv4 /24, IPv6 /64) applies in a window of 30 days. We do not state its height.
• Throttle and block: On heavy or unfair use we may throttle a key, limit the acceptance of further pages for a time, or block the key. No duty to pay arises from it. We say so when we throttle, as far as we have an address, and give the reason as far as that does not weaken the protection against abuse.
• No fixed page count: We do not state or promise a number of pages that may be read without payment.

11. Needing more

If you need more throughput or more reliability, we offer a contract: higher limits, a server of your own, or the package for productive use. What it says goes before this page.