ForHosting KIT · OCR & Data Extraction

Is this PDF scanned?

Before you run a document through an OCR pipeline, you need one honest fact: does it already contain a text layer, or is it just a picture of a page? This endpoint answers that in a single call, so you stop wasting OCR cycles on files that never needed them.

● StablePer request + per document$0.002

Run — $0.002 How it works & API

Use it from WebAPIEmailApp soonTelegram soon

Run it online

Run this on our servers with your account. Free tools run in your browser; this one bills your KIT balance per the price above.

Why this question matters more than it looks

Most document pipelines assume every incoming PDF is the same, but in practice a folder of 'contracts' or 'invoices' is a mix: some were exported straight from Word or an accounting system with a full text layer, others are flatbed scans, faxes, or photos of paper stapled into a PDF wrapper. Running OCR on the first group is pure waste — you pay for recognition work on text that was already machine-readable. Skipping OCR on the second group means silent failures downstream, where search, indexing or data extraction quietly return nothing because there was never any text to find.

What the endpoint actually checks

The task opens the PDF and inspects its internal structure page by page: it looks for an extractable text layer, measures how much of each page is covered by embedded fonts versus raster images, and flags pages that are effectively photographs with no underlying text. The result comes back as a clear verdict per document — native, scanned, or mixed for files where some pages have text and others do not — along with a simple page-level breakdown so you can route each page correctly instead of treating the whole file as one unit.

A short note on why this problem exists at all

PDF was designed in the early 1990s as a page-description format, not a text format, so it has always been possible to build a perfectly valid PDF that is nothing but an image, with no notion of characters, words, or reading order. Decades later this quirk still trips up pipelines: a scanner, a fax-to-PDF gateway, or an old archival system can all produce files that look identical to a human eye but are structurally opposite from what an automated system expects.

How it fits into a larger workflow

Call this endpoint as the first gate in any document pipeline, right after upload and before extraction, classification or search indexing. Route native results straight to text extraction, send scanned results to your OCR step, and split mixed results page by page so neither path does unnecessary work. Because the task is asynchronous, you can fan it out across an entire intake queue and let the webhook tell each downstream worker what to do next, without a human ever opening a file to check.

What you can do with it

Pre-filtering an OCR queue

A document intake system checks every incoming PDF first and only forwards the scanned ones to OCR, cutting OCR spend on files that were already digitally native.

Auditing a legacy archive

A legal or accounting team migrating a ten-year-old file share runs this check across the whole archive to know, before any project plan is written, how many files actually need OCR.

Smart routing in a SaaS upload flow

A document-management product uses the verdict to decide in real time whether to show a 'text extracted' preview instantly or queue the file for OCR processing.

Quality control on scanning vendors

An operations team spot-checks batches delivered by a third-party scanning vendor to confirm the PDFs actually carry a text layer as contracted, not just images.

FAQ

What exactly does the scanned-or-native check return?

A verdict of native, scanned, or mixed for the document, plus a per-page breakdown so you know which pages carry a real text layer and which don't.

Is this the same as running OCR?

No, it never performs text recognition. It only inspects the PDF's internal structure to tell you whether OCR is needed at all.

Is there a free tier for this API?

There's no free tier — free tiers get abused and slow everyone down. Access runs on a prepaid ForHosting KIT balance: top up from $10.00 (it never expires) and each request is charged at its published price, so a call with no balance returns HTTP 402. No subscription, no tokens, no invented credits, and a failed task is never charged.

How much does a scanned-vs-native check cost?

$0.002 per request, a small enough cost to run on every document before deciding whether OCR is worth paying for.

How do I get the result back?

The task runs asynchronously and returns a task_id immediately; the verdict is delivered via a signed webhook, which we recommend, or through a signed link valid for 24 hours.

What happens with password-protected or corrupted PDFs?

The task attempts the check up to three times automatically; if it still can't be completed, you get a clear error and, since it never charged you for a failed attempt, no cost either.

Can it handle mixed-content PDFs where only some pages are scanned?

Yes, that's exactly what the mixed verdict is for, and the page-level breakdown tells you precisely which pages need OCR and which don't.

Is my document data stored after the check?

Results and source files are deleted after the retention window and are never used for training, so you can run this on sensitive documents without a data-retention concern.

For developers — API access

Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.

API endpoint

POSThttps://api.kit.forhosting.com/ocr/scanned-or-native

Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, and soon from our app, email and Telegram.

Call it from your stack

curl -X POST https://api.kit.forhosting.com/ocr/scanned-or-native \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d &#39;{"input":"…"}'

const res = await fetch("https://api.kit.forhosting.com/ocr/scanned-or-native", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.KIT_KEY}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    "input": "…"
  })
});
const { task_id } = await res.json();

import os, requests

res = requests.post(
    "https://api.kit.forhosting.com/ocr/scanned-or-native",
    headers={"Authorization": f"Bearer {os.environ[&#39;KIT_KEY']}"},
    json={
    "input": "…"
},
)
task_id = res.json()["task_id"]

<?php
$res = file_get_contents("https://api.kit.forhosting.com/ocr/scanned-or-native", false, stream_context_create([
  "http" => [
    "method"  => "POST",
    "header"  => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
    "content" => &#39;{"input":"…"}',
  ],
]));
$task = json_decode($res, true);

body := bytes.NewBufferString(`{"input":"…"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/ocr/scanned-or-native", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)

Example request

{
  "input": "…"
}

Example response

{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "ocr.scanned_or_native",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.

Pricing

Per request$0.002

Published price — no tokens, no invented credits. A failed task is never charged.

Limits

`max_mb`	25
`max_pages`	10

Errors

HTTP	Code	Meaning
`401`	`unauthorized`	Missing or invalid API key.
`402`	`insufficient_balance`	Your balance doesn't cover the task price.
`404`	`unknown_type`	That task type doesn't exist.
`429`	`rate_limited`	Too many requests. Use the webhook instead of polling.
`413`	`input_too_large`	The file exceeds the size limit.

Read the full KIT documentation →