Does this verify identity?

No. It reads what is legible on a page. There is no face match, no liveness check, and no authenticity signal, and a read should never be treated as evidence that a document is genuine.

Does using this make us compliant with the PDPA?

No. The Personal Data Protection Act places obligations on you as the party collecting the data, including your lawful basis and your handling of sensitive categories. Using an API to read a page changes none of that.

What if the photograph is blurred or cropped?

The read returns what is legible and does not invent the rest. That is the behaviour you want here: a missing field an operator can see is safer than a confident guess nobody checks.

Can it read handwriting on a form?

Printed forms with handwritten answers are the common case, and the read attempts both. We publish no accuracy figures, so test it with the forms your own applicants actually submit before you rely on it.

All use cases

Thai OCR for identity documents and forms

Read photographed identity documents and completed forms into text, so an onboarding flow stops asking people to type what they already submitted.

Try it in the playground Read the docs

What comes back

A completed application formoutput: structured

heading   แบบคำขอเปิดบัญชี
paragraph ชื่อ-นามสกุล นายสมชาย ใจดี
paragraph วันเกิด ๑๒ มีนาคม ๒๕๓๘
paragraph ที่อยู่ตามทะเบียนบ้าน ๔๕/๗ ถนนสุขุมวิท
list      3 items
figure    signature

Typed blocks separate the answers from the printed labels, so a form's own layout does not have to be re-encoded in your parser.

A photographed documentoutput: markdown · 1 page

ชื่อ นายสมชาย
ชื่อสกุล ใจดี
เกิดวันที่ ๑๒ มี.ค. ๒๕๓๘
ที่อยู่ ๔๕/๗ ถนนสุขุมวิท แขวงคลองเตย
เขตคลองเตย กรุงเทพมหานคร

An image is one page, whatever the camera. The read returns what is legible on it and invents nothing that is not.

A supporting letteroutput: markdown

# หนังสือรับรองการทำงาน

บริษัทขอรับรองว่า นายสมชาย ใจดี เป็นพนักงาน
ตำแหน่ง วิศวกรอาวุโส ตั้งแต่วันที่ ๑ เมษายน ๒๕๖๕

![company seal](figure)

Seals return as figures rather than as guessed text, which is the honest answer when a stamp is not legible.

The reads above are illustrations of shape, not captured responses. The OCR page carries the model's own witnessed read of a real specimen, with its capture date.

How it fits an onboarding flow

Onboarding in Thailand usually ends with a photograph. An applicant holds a document up to a phone camera, fills in a form, and photographs that too, and then a person on the other side reads both and types them into a system. The reading is the part a model can do. Everything after it, including what your obligations are under the Personal Data Protection Act and whether an applicant may be approved, stays with you.

Sources:PDPA (B.E. 2562)(opens in a new tab)

Take the photograph you already takeSend the image as base64. PNG, JPEG, and WebP are each one page, and a multi-page PDF is read page by page up to 50.
Prefill, then let a person confirmUse the read to fill the fields the applicant would otherwise type, and show them the result. A person confirming a prefilled form is faster and more accurate than a person typing an empty one.
Keep the decision where it belongsApproval, verification, and retention stay in your system under your policy. The API contributes text and nothing else.

An onboarding queue, priced

Workload	Pages	Credits
One applicant (a document and a form)	2	13
300 applicants a day	600	3,900
A 22-day month at that rate		85,800 credits

Every image is one page at 6.5 credits, so the cost of a queue is the number of photographs in it.

What an applicant actually sends

one submission

photo_1.jpg   a document, held at an angle, 1 page
photo_2.jpg   a completed form, folded once, 1 page

what makes it hard:
  the marks that stack above a Thai letter
  are the axis a tilted photograph compresses

  the name and the address after it arrive
  as one run of characters, with no space
  between any two words

Both pages are ordinary submissions and both are the case a Thai reader has to handle first, rather than the clean scan a reader is usually demonstrated on.

What this does, and what stays yours

The model reads: It returns the text that is legible on the page, in Markdown or as typed blocks.
You decide: Whether a document is genuine, whether an applicant is approved, and what your lawful basis is under the PDPA.
We do not verify: There is no face match, no liveness check, and no authenticity signal. This is a reader, not a verifier.

The Personal Data Protection Act governs how personal data is collected, used, and disclosed in Thailand, and applies stricter conditions to sensitive categories. Meeting those obligations is the reader's responsibility, not the API's.

Sources:PDPA (B.E. 2562)(opens in a new tab)

For developers

Structured output is the right shape here: a form's answers arrive as typed blocks rather than a paragraph you have to re-split.

# Encode without line wrapping: wrapped base64 breaks the JSON string.
DOC=$(base64 < invoice.pdf | tr -d '\n')
# --max-time covers a multi-page document; curl defaults to no limit.
curl -X POST https://api.paxalabs.com/v1/ocr \
  --max-time 300 \
  -H "Authorization: Bearer $PAXA_API_KEY" \
  -H "Content-Type: application/json" \
  -d "{\"document\": \"$DOC\", \"model\": \"paxa-ocr-lite-v1\"}"

DOC=$(base64 < invoice.pdf | tr -d '\n')
curl -X POST https://api.paxalabs.com/v1/ocr \
  --max-time 300 \
  -H "Authorization: Bearer $PAXA_API_KEY" \
  -H "Content-Type: application/json" \
  -d "{\"document\": \"$DOC\", \"model\": \"paxa-ocr-lite-v1\", \"output\": \"structured\"}"

import base64
import os

import requests

with open("invoice.pdf", "rb") as file:
    document = base64.b64encode(file.read()).decode()

response = requests.post(
    "https://api.paxalabs.com/v1/ocr",
    headers={"Authorization": f"Bearer {os.environ['PAXA_API_KEY']}"},
    json={"document": document, "model": "paxa-ocr-lite-v1"},
    # A multi-page document can run for minutes; give it room.
    timeout=300,
)
response.raise_for_status()
body = response.json()
print(body["pages"][0]["markdown"], body["usage"]["credits"], "credits")

Full API reference

A photograph of Thai text is a harder page than a scan

Thai stacks up to four marks vertically over a single base letter, and a phone photograph taken at an angle compresses exactly that axis. It also writes without spaces between words, so a name and the address after it arrive as one run of characters. Both are why a document photographed by an applicant, rather than scanned by an office, is the case a Thai reader has to be built for rather than adapted to.

Common questions

Does this verify identity?: No. It reads what is legible on a page. There is no face match, no liveness check, and no authenticity signal, and a read should never be treated as evidence that a document is genuine.
Does using this make us compliant with the PDPA?: No. The Personal Data Protection Act places obligations on you as the party collecting the data, including your lawful basis and your handling of sensitive categories. Using an API to read a page changes none of that.
What if the photograph is blurred or cropped?: The read returns what is legible and does not invent the rest. That is the behaviour you want here: a missing field an operator can see is safer than a confident guess nobody checks.
Can it read handwriting on a form?: Printed forms with handwritten answers are the common case, and the read attempts both. We publish no accuracy figures, so test it with the forms your own applicants actually submit before you rely on it.

Start with free credits

Start free

More use cases