Fulla at a laptop beside statement records and an open ledger

REST API integration

Connect intake to approved output.

The REST API follows the same upload, review, approve and export workflow as Fulla’s web app. Connect it from your server using a key bound to your workspace.

Connection plan

One lifecycle. An explicit review boundary.

  1. 01

    Intake

    POST /api/v1/statements

    Upload one to ten PDFs. Keep the returned statement IDs.

  2. 02

    Inspect

    GET /api/v1/statements/{id}/result

    Wait for processing, then inspect the latest saved review revision.

  3. 03

    Review

    PATCH /api/v1/statements/{id}/review

    Save corrections, then approve the exact reviewed revision.

  4. 04

    Export

    POST /api/v1/statements/convert

    Request JSON inline or retrieve CSV, XLSX and OFX files.

The full sequence includes status checks and POST /api/v1/statements/{id}/approve. Approval names the exact revision a person checked.

Use a credential with a clear workspace boundary.

Workspace API keys are sent as Bearer tokens and stay bound to the workspace where they were created. Keep the key on your server, and maintain the relationship between each source file, returned statement ID and authorized workspace.

The upload endpoint accepts one to ten PDF files using the files form field, with a maximum of 50 MiB per file and 100 MiB per request. A statement may contain up to 250 pages. Check the per-file outcomes: the API documents 202 for an accepted upload and 207 for mixed results.

Upload request · replace origin, key and file with your own values
curl -X POST "$FULLA_ORIGIN/api/v1/statements" \
  -H "Authorization: Bearer $FULLA_API_KEY" \
  -H "Idempotency-Key: upload-example-01" \
  -F "files=@statement.pdf;type=application/pdf"

Keep the Bearer token on your server. A workspace key stays bound to its workspace.

Authentication details →

For inspection

Current review result

GET /api/v1/statements/{id}/result

The latest saved review revision, available without an approval gate. This endpoint is not an approved conversion export.

After approval

Approved conversion

POST /api/v1/statements/convert

Conversion uses the approved persisted revision. JSON returns inline; CSV and XLSX produce export URLs.

Keep draft access separate from final conversion.

The status endpoint reports processing state and expiry. The result endpoint returns the latest saved review revision without requiring approval. Review supports field edits, insertion, deletion, splitting and merging; save operations against the current base revision.

Approval names the exact reviewed revision. A stale revision returns a conflict, which the integration should resolve by reading the latest state. Only approved persisted revisions feed conversion. JSON returns inline; CSV and XLSX return export status and download URLs.

Build for the operational edges.

60 requests
Per key, per minute
100 MiB
Maximum upload request
24 hours
From upload initiation to expiry

Handle expiry, rate limits and downstream mapping.

Keys are limited to 60 requests per minute. Respect Retry-After on rate-limit responses and check documented error codes for revision conflicts, expired documents and allowance limits. Statements are deleted 24 hours after the upload starts; approval and export do not extend that.

The conversion endpoint supports multiple approved statements with an active paid entitlement. Map the returned fields to your own application and validate the handoff. Fulla does not provide a native accounting-platform sync or decide how your external system posts transactions.

Files you can inspect

Build against a concrete fictional example.

Download a source PDF and expected approved rows, then follow the Node client through upload, status, review, explicit approval and conversion. The sample outputs are deterministic fixtures; an extraction run is a separate test.

Get the sample input and expected rows