Integrations
REST API Integration
Submit documents, receive structured results and trigger workflows from the applications your own team builds and runs.
What moves
What flows between your application and PTAS AI
Documents and the context around them go in. A scored, checked record comes out, and a workflow starts if you ask for one. Your application stays in charge of what happens next.
Your application
Documents
Context you send
PTAS AI
Structured JSON, scored per field
Typed values with a confidence score on every field, so your code knows which values it can use as they are.
Validation results and review status
Which checks passed, which failed and why, and whether a person still has to look at a field.
A workflow started, where you ask for one
The same submission can start a FinSuite workflow: matching, approval and posting under your rules.
API access is set up on request. Endpoints, authentication and limits are documented for developers when access is granted; the examples on this page are illustrative and are not the published schema.
The DocPro API in detailIntegration methods
When the REST API is the right route
Four ways in. The API is the one to use when the system on the other side is software you build or control.
Native
Start with the system page
If the system you want to reach has its own page here, SAP, Oracle, Tally and the rest, the route for that system is described there. This API is for the application in between, or for a system with no page of its own.
API
This page
Your code calls PTAS AI over HTTPS: submit a document with its context, receive a reference, collect a scored record. Real time for a single upload, batch for a set, callback when the record is final. The route for most applications you build yourself.
File
When nothing can call an API
A watched folder or an SFTP location for documents in, and a results file out, for systems that can only exchange files. Slower, and often simpler to get approved.
Custom
When the API is one step of several
Your application submits, FinSuite matches and approves, and the ERP is written through its own route. Orchestration across those steps is scoped as a custom integration, with one queue and one trail.
Three calling patterns cover almost everything. Real time suits a single upload where a person is watching the screen. Batch suits a month of statements or a scanned backlog. Callback suits the rest, and it is the one we suggest for production: submit, take the reference, and let PTAS AI notify your endpoint when the record is final, including after a reviewer has cleared a held field. If your network does not accept inbound calls, ask for the status with your reference instead; the answer is the same, a little later.
Three calling patterns
Send one document and wait for the record. Right for an upload screen where a person is watching. Wrong for a forty-page statement, or for any document that may need a reviewer before it is final.
Submit a month of statements or a scanned backlog, keep the references, and collect the records when the set is done. Your system decides when to look.
Submit, get a reference at once, and let PTAS AI notify your endpoint when the record is final, including after a person has cleared a held field. The pattern we suggest for most production workflows.
A held field can take hours to clear. Build for that from the start and the review step never becomes a timeout.
What goes in
What a submission carries
Only the document is required. Everything else is context your system already holds, and sending it saves a step later.
Illustrative example · what a submission carries
Illustrative example. Field names and the request format are set out in the developer documentation issued with API access. What matters here is the shape: send what you already know, and your own reference comes back with every answer.
What comes out
What the record tells your system
Values, a score on each one, the checks that ran and where the record stands. Enough for your code to decide what to do without a person looking at the PDF.
Illustrative example · one record, as returned
Illustrative data, matching the sample on the DocPro page. Key names show the kind of record returned; the published schema is in the developer documentation.
Security of the connection
What protects the documents you send
Four controls that apply to every call. The exact authentication scheme is in the developer documentation; these are the commitments around it.
Credentials for servers, not browsers
API credentials are issued for your account when access is set up. Keep them on your server; a web page or a mobile app is the wrong place for them. They can be revoked and reissued without changing anything else.
Encrypted, and kept only as long as you say
Calls go over HTTPS. Documents and extracted data are encrypted in transit and in storage, held for the period your retention policy sets, and each deletion is recorded.
Role-based access to what comes back
Who can see a document, its fields and its review history is set by role. Masking is set per field and per destination, so an identity number need not reach every system that receives the record.
Every call on the record
Each submission, result and correction is kept in the audit trail with your reference attached, so a value in your system can be traced to the document and to the person who reviewed it.
FAQ
Questions developers ask
How do we get API access?
Ask through the contact page, with a line on what you want to connect, the document types and a rough monthly volume. Access is set up for your account together with the developer documentation: endpoints, authentication and the limits that apply. There is no self-service sign-up on this site.
Is this the same as the DocPro API?
The document side is. Submitting documents and receiving scored records is the DocPro API, which has its own page. This page also covers starting FinSuite workflows and reading their status, and how the API fits beside the other integrations.
Real time, batch or callback: which should we build?
Callback, for most production work. Real time is fine where a person waits on one document. Batch suits month-end runs and backlogs. Callback handles both and copes with review, because a held field can take hours to clear and your system should not hold a connection open for it.
What happens when a field fails validation?
It comes back marked, with the check that failed and why. Depending on your rules, the record is held for review or returned flagged. Nothing is corrected silently. When a reviewer resolves it, the final record arrives with a marker on each field a person changed.
What are the rate limits?
They depend on your plan and deployment, and are stated in the documentation that comes with API access. If your volume is lumpy, a month-end run of bank statements for example, say so when access is set up, so the batch route carries it instead of a burst of real-time calls.
Can the API run inside our own network?
Where supported, yes. Private cloud and on-premise deployments, including air-gapped setups for regulated workloads, are options, and callbacks then go to endpoints inside that network. The deployment model is agreed at assessment.
Keep reading
Related reading
Webhooks
Events pushed to your systems when a document is processed, a review completes or an approval changes.
Read more →DocPro API
Documents in, structured JSON with field-level confidence out, in more detail.
Read more →Custom Document Agents
For document types no standard agent covers: your schema, your rules.
Read more →All integrations
ERPs, accounting suites, the REST API and webhooks in one list.
Read more →Developers
Tell us what you want to connect
Name the application, the document types and the volume. API access is set up for your account with the documentation to build against, and you test it on your own documents.