Reorder PDF Pages

Endpoint #

POST https://pixlab.davix.dev/v1/pdf

Action #

action=reorder

Description #

The Reorder PDF Pages action changes the order of pages in a PDF document using the H2I engine (PixLab).

This action is part of the public /v1/pdf API surface. It accepts a source PDF and reorders the document pages according to a required custom page sequence. The processed document is returned as a generated PDF output through a signed URL under the public PDF output path.

This action is suitable for workflows such as:

  • reorganizing reports or documents
  • preparing files for printing
  • adjusting page sequences in automated workflows

Request Format #

Requests to /v1/pdf must use:

  • Content-Type: multipart/form-data
  • API key authentication in request headers
  • source PDF upload through the files field

For non-merge PDF actions, the first uploaded PDF file is used as the primary input. This applies to action=reorder.

Parameters #

action #

Type: string
Required: Yes
Accepted value: reorder

Specifies that the request should reorder pages in the PDF document.

files #

Type: file upload (multipart/form-data)
Required: Yes

The source PDF document.

  • uploaded through the files field
  • must be a valid PDF upload
  • for this action, the first uploaded PDF file is used as the source input

order #

Type: JSON string array
Required: Yes

Defines the new page order.

Accepted form:

  • JSON array string such as [3,1,2]

Constraints:

  • must be a full 1-based permutation of all pages
  • page numbering starts from 1
  • each page must appear exactly once
  • the full document page set must be represented in the new order

Example:

  • [3,1,2]

Meaning:

  • original page 3 becomes page 1
  • original page 1 becomes page 2
  • original page 2 becomes page 3

Supported Parameters #

The Reorder PDF Pages action supports the following public parameters:

ParameterDescription
actionMust be reorder
filesSource PDF upload
orderNew page order as a full 1-based permutation

These are the documented public parameters for /v1/pdf action=reorder.

Full cURL Example #

curl -sS -X POST "https://pixlab.davix.dev/v1/pdf" \
-H "X-Api-Key: <YOUR_API_KEY>" \
-H "Idempotency-Key: pdf-reorder-001" \
-F "action=reorder" \
-F "files=@/path/to/document.pdf" \
-F 'order=[3,1,2]'

This example includes the full documented public parameter surface for the Reorder PDF Pages action:

  • action=reorder
  • source PDF upload in files
  • required order
  • optional idempotency header

Success Response #

Successful /v1/pdf requests return either a single output object or a results array, depending on the action. For public documentation, action=reorder is safest documented as a single generated PDF output returned through a signed URL. PDF output URLs are served under /pdf/<file>.

{
"url": "https://pixlab.davix.dev/pdf/reordered-document.pdf",
"request_id": "req_abc123"
}

Response Fields #

url #

Signed output URL for the generated reordered PDF. PDF outputs are served under the public /pdf/<file> path.

request_id #

Request identifier returned by the API when available.

Errors #

The public /v1/pdf endpoint documents the following PDF-route errors:

  • missing_field
  • invalid_parameter
  • unsupported_media_type
  • pdf_page_limit_exceeded
  • rate_limit_exceeded
  • rate_limit_store_unavailable
  • monthly_quota_exceeded
  • server_busy
  • timeout
  • pdf_tool_failed

The shared upload/error layer can also return:

  • invalid_upload
  • file_too_large
  • too_many_files
  • total_upload_exceeded

HTTP Status Codes #

  • 400 → invalid request fields or parameters
  • 413 → upload size/count limits exceeded or other request-size-related PDF limits
  • 415 → unsupported media type
  • 429 → rate limit or monthly quota exceeded
  • 503 → timeout, rate-limit store unavailable, or server busy
  • 500 → PDF processing failure

Usage Notes #

Idempotency-Key is optional and supported for retry-safe request handling. Both Idempotency-Key and X-Idempotency-Key are accepted.

order must be a full 1-based permutation of all pages in the document.

Missing, duplicate, or invalid page indexes cause the request to fail validation. This follows the documented requirement that order must parse as valid indexes and represent a full permutation.

Page numbering starts from 1.

Output files are returned through signed URLs. Applications that need long-term storage should store generated files externally rather than treating output URLs as permanent hosting.

Was it helpful ?
Scroll to Top