The Plextera Public API exposes four endpoint groups.
Upload and manage files. A file can be submitted to Document Insights for extraction or referenced in a workflow.
Constraints:
Extract structured fields from documents and monitor asynchronous processing.
Document input - use an existing fileId, a public HTTPS url, or direct multipart upload.
Tags - optional string key-value pairs returned with the extraction. docType is reserved for configured Document Insights routing.
Tag limits:
docType counts as one tag and follows the same limitsFor setup steps, examples, and docType guidance, see Document Extraction.
Extraction lifecycle:
Output - available on GET /document-insights/extractions/{extractionId} once outputAvailable is true. Extractions return a typed fields array with confidence scores and page placement coordinates when available.
List extractions - use GET /document-insights/extractions to review recent extractions and check their status. Use GET /document-insights/extractions/{extractionId} when you need the full output.
List sorting - GET /document-insights/extractions supports sortBy=createdAt|updatedAt|completedAt and sort=asc|desc. Defaults are createdAt and desc.
Timestamps - all timestamps are UTC ISO 8601 strings. createdAt is when Plextera accepted the extraction, updatedAt is the last known state change, and completedAt is present after the extraction reaches COMPLETED, FAILED, or REJECTED.
Feedback — after reviewing an extraction result, submit corrections per field using POST /document-insights/extractions/{extractionId}/feedback. Include fieldId to target a specific field, or omit it for a general comment. type defaults to ERROR; use INFO for notes that should not mark the extraction as incorrect. Feedback is surfaced to the Document Insights team for extraction quality improvement.
Feedback messages are required and limited to 1024 characters.
Trigger and monitor workflow runs. Workflows are configured in Plextera Studio and can include Document Insights steps, data transformation, and custom processing logic.
Trigger payload — the request body is passed to the workflow as its trigger input. Any valid JSON is accepted; the expected structure depends on the workflow’s trigger configuration. Omit the body entirely if the workflow requires no input.
Multipart trigger input — POST /workflows/{workflowId}/runs also accepts multipart/form-data for workflows configured to consume form-data, similar to a Studio webhook trigger.
Part names are preserved. If a workflow is configured to read body.document, send a file part named document. If it reads body.attachments, send one or more file parts named attachments. The API reference shows common fields for Try It, but clients can send workflow-specific part names as needed.
Run lifecycle:
CLOSED is returned for workflow runs that were closed in Plextera Studio.
Step output — GET /workflow-runs/{runId} returns step-level status and output for each step. Steps that start nested sub-workflows expose those runs in nestedRuns. Use GET /workflow-runs/{runId} with a nested run’s id to load full nested run details.
Duration fields:
durationMs — wall-clock time from startedAt to completedAtcomputedDurationMs — active processing time, excluding wait states and parallel idle timeConfigure webhook endpoints to receive push notifications when document extractions or workflow runs reach terminal states.
Filters — optionally restrict workflow events to a specific workflowId. Document Insights events are filtered by the selected event types and do not require a filter object.
Pausing — set status: paused via PATCH to suspend deliveries without deleting the subscription. Set back to active to resume.
See Event Subscriptions for delivery headers, signature verification, and retry behavior.
All list endpoints (GET /files, GET /document-insights/extractions, GET /workflow-runs, GET /event-subscriptions) use cursor-free, zero-based page parameters:
Every list response includes a pageInfo object:
All error responses use a common envelope:
Every response includes an X-Request-Id header with a unique identifier for the request. This ID is also echoed in the requestId field of error responses.
When reporting issues, always include the X-Request-Id — it allows Plextera to locate the exact request in server logs regardless of timing.