Endpoints

Every endpoint below lives under https://api.mathpix.com and authenticates with the app_id and app_key headers from your API key. If you need your documents processed and stored in the EU, send the same requests to https://eu.api.mathpix.com — see Server locations.

v3/latex still works and is still supported, but it is legacy — new integrations should use v3/text.

You can use this endpoint to OCR individual images of handwritten and printed equations, handwritten and printed text, tables, and diagrams to get digital formats like LaTeX, Asciimath, and MathML. You can also request additional information about the data in the image like which alphabets were detected (we support most foreign languages), line data, word data, and confidence.

This is also the endpoint you want to process images of diagrams like geometry and chemistry. At this time we only support triangles for geometry, which are represented via vertices, edges, and labels.

Accepted image formats are listed in Supported Formats.

Use this endpoint to OCR documents and convert them to Mathpix Markdown, LaTeX, DOCX, HTML, PPTX, XLSX, or line-level JSON. Despite the name it accepts more than PDF — EPUB, DOCX, PPTX and several other document formats are supported, listed in Supported Formats. You can pass either a file upload or a URL.

This endpoint works asynchronously, since large documents can take several minutes to process. You submit the document, then either poll for status or register a callback_url and let Mathpix notify you when it finishes.

It can also return line-by-line data, useful for building novel experiences on top of original documents; stream pages as they complete; and process a subset of pages. A separate PDF results endpoint (v3/pdf-results) can be used to query information about a certain document, or all your documents.

Use this endpoint when you already have Mathpix Markdown — because you stored the output of an earlier v3/pdf run, or because you authored it — and you want it in another format. It converts MMD into DOCX, XLSX, LaTeX, HTML, PDF, and PPTX without re-running OCR.

Like v3/pdf, it is asynchronous: submit, poll for status, then download.

Use this endpoint to add stroke recognition (i.e. digital ink) to your app. This endpoint works for all math, and for Hindi and Latin alphabet language text. You can process the data for each individual stroke, or you can use a session_id for live drawing capabilities in your app (this is also the more cost-effective option).

Use this endpoint to process multiple images in a single POST request. The request will return a batch ID which can be queried with a GET request once an appropriate amount of time has passed for the images to process. You should only use the batch endpoint if your workflow is not latency sensitive — for example, you are digitizing a textbook and need to process all images of equations. Please note that batch requests are priced per image in the batch, not per request.

Each image is processed with v3/latex behavior by default, but batch is not limited to it: setting ocr_behavior to "text" gives you v3/text behavior instead, per batch or per image. See Use v3/text behavior.

If you are indexing continuously rather than submitting discrete batches, consider v3/text with the async flag and a tags field instead — it does not require you to pre-batch requests at all. See Running “batch” / indexing jobs. For bulk documents rather than images, use files/v1.

The Files API is the high-throughput path for bulk document processing — archives, back-catalogs, and training corpora rather than interactive requests. It accepts a single file, a source URI, or a job of up to 200,000 documents in one call.

It can also read from and write to your own AWS S3, Google Cloud Storage, or Azure Blob Storage through a keyless grant, so results never round-trip through your servers and you never hand Mathpix long-lived credentials.

Files API pages are billed at a lower per-page rate than v3/pdf, and the monthly page allotment is shared between the two. See /pricing/api for current rates.

Use this endpoint to mint short-lived tokens that client apps can use directly, so your API key never ships inside a mobile or browser app. Tokens expire in five minutes by default; the expires parameter changes that, within limits that differ for plain tokens and strokes sessions — see the expires reference for the exact ranges.

This is the recommended alternative to running your own regional proxy fleet — see Authorization for the two architectures side by side.

Use this endpoint to search your results from POST requests to v3/text, v3/strokes, and v3/latex with a GET request on /v3/ocr-results?search-parameters. Results are only queryable for requests made with improve_mathpix set to true — see Privacy.

The same data is browsable without writing a query in the Results tab on Console — see Usage and results.

Use this endpoint to search your results from POST requests to v3/pdf with a GET request on /v3/pdf-results?search-parameters. The search request must contain a valid app_key header to identify the group owning the results to search.

Use this endpoint to query your own usage hour by hour, broken down by API key and usage type. It is the programmatic equivalent of the Console Usage tab, and it is the right tool for feeding usage into your own dashboards or chargeback systems.

Rather than polling for status, you can register a callback_url on any v3/pdf, files/v1, files/v1/uri, or files/v1/jobs submission and have Mathpix call you when work finishes. Use callback_events to choose which of file.completed, file.error, and job.completed you want.

Notifications are signed, and you should verify the signature before trusting one. The webhooks guide has the verification recipe with working code.

This is our legacy endpoint for converting images to LaTeX, that was developed before we added support for regular text. The intent of the endpoint was to parse out the math in an image, while ignoring text, so this endpoint should only be used for images that only have individual equations and no text that needs to be processed. It remains supported for existing integrations; new work should use v3/text.