Developer tutorial · PDF to JSON API

Extract a small JSON record from one authorized document.

This tutorial shows the DocuStruct contract for a bounded document-automation task: send one permitted PDF or image, request a compact JSON shape, inspect the result, then let your operating team decide what happens next.

Use case

Start with a field contract, not an automation promise.

A developer integrating invoices, delivery notes or technical documents usually needs a few reviewable fields rather than a broad document summary. The request schema makes that boundary explicit and keeps unknown values visible.

Choose a permitted source

Use an owned, public or otherwise authorized file. Do not place credentials, restricted records or unnecessary personal data in a tutorial request.

Request the smallest useful shape

For example, ask for vendor and total. A narrow schema makes missing or ambiguous fields easier to review.

Keep a human checkpoint

Completed JSON is structured output, not approval to update a system of record or trigger an operational action.

Step 1 · send one idempotent request

Call the PDF to JSON API through RapidAPI.

Replace the placeholders with your RapidAPI host, key and a base64-encoded authorized fixture. Keep the same Idempotency-Key when retrying the same document request.

POST /api/v1/docustruct/extract
curl --request POST \
  --url https://YOUR_RAPIDAPI_HOST/api/v1/docustruct/extract \
  --header 'x-rapidapi-key: YOUR_KEY' \
  --header 'x-rapidapi-host: YOUR_RAPIDAPI_HOST' \
  --header 'Idempotency-Key: tutorial-example-001' \
  --header 'Content-Type: application/json' \
  --data '{
    "filename":"example-invoice.png",
    "mimeType":"image/png",
    "base64":"BASE64_ENCODED_AUTHORIZED_FILE",
    "schema":"{\"vendor\":\"string\",\"total\":\"number\"}"
  }'
Step 2 · inspect before routing

Treat the JSON as a reviewable record.

The response below is an illustrative shape, not a customer document or accuracy claim. Your workflow should preserve missing values, validation issues and source context for the person responsible for the next decision.

Illustrative response

{
  "id": "ds_example",
  "status": "completed",
  "pageCount": 1,
  "result": {
    "vendor": "Example Vendor",
    "total": 149.5
  }
}

Before you route

Confirm that required fields are present, the document was authorized, values make sense for your process and exceptions remain visible. Then decide whether to approve, correct or hold the record.

Integration checklist

Four controls that keep the implementation bounded.

01

Validate source authorization

Confirm the requestor may process the document and minimize the uploaded data before sending it.

02

Set an idempotency key

Reuse the key for the same logical request so a retry does not create a second job.

03

Check the completed record

Inspect status, page count, requested fields and missing values before downstream routing.

04

Escalate exceptions

Keep a manual path for unreadable sources, unexpected values and business approvals.

Known limits

Use the API to structure permitted data, not to bypass document controls.

File constraints apply

Unsupported MIME types, files over 10 MB and PDFs over 25 pages should be handled by the calling workflow before the request.

Schema governs the result

Ask only for fields you can review. The API returns a structured extraction rather than a business approval or downstream write.

Privacy remains your boundary

Do not use the public tutorial fixture or demo to upload confidential, regulated or unrelated personal documents.