The LeapOCR PHP SDK Is Live

If you build in PHP, you should not have to drop down to raw HTTP just to add document processing.

The official LeapOCR PHP SDK is now available, with first-class support for:

• local file uploads
• remote URL processing
• polling helpers for async jobs
• structured JSON extraction
• markdown OCR output
• typed exceptions
• webhook signature verification

Install it from Packagist:

composer require leapocr/leapocr-php

FIG 1.0 - Quick-start flow from PHP code to processed result.

Why ship a PHP SDK now

A lot of OCR tooling is Node-first, Python-first, or “just call the REST API.” That works, but it leaves PHP teams rebuilding the same boring integration layer:

• authentication wrappers
• upload orchestration
• polling loops
• response mapping
• error handling

The PHP SDK removes that glue code so Laravel, Symfony, and custom PHP backends can use the same LeapOCR workflow the other official SDKs already support.

Quick start

Here is the shortest path from “I have a PDF” to “I have structured data”:

<?php

require 'vendor/autoload.php';

use LeapOCR\Enums\Format;
use LeapOCR\Enums\Model;
use LeapOCR\LeapOCR;
use LeapOCR\Models\ProcessOptions;

$client = new LeapOCR((string) getenv('LEAPOCR_API_KEY'));

$job = $client->ocr()->processUrl(
    'https://example.com/invoice.pdf',
    new ProcessOptions(
        format: Format::STRUCTURED,
        model: Model::STANDARD_V2,
        schema: [
            'type' => 'object',
            'properties' => [
                'invoice_number' => ['type' => 'string'],
                'invoice_date' => ['type' => 'string'],
                'total_amount' => ['type' => 'number'],
            ],
            'required' => ['invoice_number', 'total_amount'],
        ],
    ),
);

$result = $client->ocr()->waitUntilDone($job->jobId);

var_dump($result->pages[0]->result);

That gives you a native PHP flow instead of a custom curl layer sitting in the middle of your app.

Processing local files without custom upload plumbing

The most annoying part of document APIs is often the upload path, not the OCR call itself.

The SDK handles direct upload flow for you:

<?php

use LeapOCR\Enums\Format;
use LeapOCR\Enums\Model;
use LeapOCR\Models\ProcessOptions;

$job = $client->ocr()->processFile(
    __DIR__ . '/documents/bill-of-lading.pdf',
    new ProcessOptions(
        format: Format::STRUCTURED,
        model: Model::PRO_V2,
        instructions: 'Extract carrier, consignee, container number, and total weight',
        schema: [
            'type' => 'object',
            'properties' => [
                'carrier' => ['type' => 'string'],
                'consignee' => ['type' => 'string'],
                'container_number' => ['type' => 'string'],
                'total_weight' => ['type' => 'number'],
            ],
            'required' => ['carrier', 'container_number'],
        ],
    ),
);

$result = $client->ocr()->waitUntilDone($job->jobId);

You keep the code at the business-logic level while the SDK handles the lower-level upload steps.

FIG 2.0 - Production integration surface covering uploads, polling, schema control, and errors.

Better fit for production PHP apps

The point of the SDK is not just fewer lines of code. It is a cleaner production integration surface.

What you get:

• Typed exceptions so your app can treat validation, auth, rate limit, and job failures differently
• Value objects and enums for a more predictable public API
• Polling helpers so background workers and admin actions do not need custom status loops
• Template and schema support so the same integration can handle both flexible OCR and strict extraction

For example:

<?php

use LeapOCR\Exceptions\AuthenticationException;
use LeapOCR\Exceptions\JobFailedException;
use LeapOCR\Exceptions\ValidationException;

try {
    $result = $client->ocr()->waitUntilDone($job->jobId);
} catch (AuthenticationException $exception) {
    // Invalid API key or missing auth
} catch (ValidationException $exception) {
    // Invalid format/model/schema/template combination
} catch (JobFailedException $exception) {
    // OCR job reached a failed terminal state
}

That matters when the SDK is running inside queue workers, internal tools, or customer-facing upload flows.

Who this is for

The PHP SDK is a good fit if you are:

• adding OCR to a Laravel or Symfony app
• processing invoices, bills of lading, customs documents, claims, forms, or medical paperwork
• extracting JSON into a database or ERP workflow
• replacing brittle PDF parsing code with schema-based extraction

If your team is already using LeapOCR in JavaScript, Python, or Go, the PHP SDK also makes it easier to keep the same workflow shape across services.

Request another SDK

PHP is now part of the official SDK lineup. If your stack needs another language runtime, tell us.

We are especially interested in hearing from teams that want:

• Ruby
• .NET
• Java
• Elixir
• Rust

If you want us to prioritize a new SDK, contact us and tell us:

• which language you need
• what kind of documents you process
• whether you need uploads, polling, templates, webhooks, or all of the above

That feedback is how we decide what to ship next.

Start with the docs, then test it on your own documents

• Read the docs: docs.leapocr.com
• Install the package: composer require leapocr/leapocr-php
• Try it in your app: Create an account
• Need a different SDK or a deeper integration discussion: Contact us

The goal is simple: if your backend is written in PHP, you should be able to integrate LeapOCR without building a custom client first.