Skip to main content
The FileRouter REST API gives you direct HTTP access to document parsing and comparison jobs from any language or environment. All endpoints live under a single base URL, return JSON responses, and use application/problem+json for structured error details. If you’re working in TypeScript, the FileRouterClient from @file_router/sdk wraps this API automatically — but for any other environment, this reference covers everything you need.

​
Base URL

Every versioned endpoint is prefixed with /api/v1/. The current version is v1.

​
Authentication

All /api/v1/ endpoints require a Bearer token in the Authorization header:
See the Authentication page for full details and error shapes.

​
Content Types

  • Request bodies — send application/json for URL-based jobs, or a raw binary body with the document’s MIME type (e.g., application/pdf) for file uploads.
  • Responses — all success responses use application/json.
  • Error responses — all error responses use application/problem+json.

​
Response Headers

Every response from the API includes an X-Request-ID header containing a unique identifier for that request. Include this value when contacting support.

​
OpenAPI Specification

FileRouter publishes an OpenAPI 3.1 document you can use to generate client code or explore the API in tools like Swagger UI or Scalar.
This endpoint requires no authentication and returns the full OpenAPI 3.1 schema.

​
Endpoints

POST /api/v1/jobs

Create a document parse or compare job. Supports both URL-based and binary file upload inputs.

GET /api/v1/jobs/{jobId}

Poll job status and retrieve the parsed result when the job completes.

​
Health Check

You can verify the API is reachable and the database is responsive with the health endpoint. It requires no authentication.
Check API health
Health response
The health endpoint returns Cache-Control: no-store — each request actively checks the database connection rather than serving a cached response.

​
Error Format

All API errors return application/problem+json bodies. A 404 for an unknown route, for example, looks like this:
404 route not found
The request_id in the error body always matches the X-Request-ID response header, so you can correlate errors across logs and support tickets.