The integration burden belongs on our side, not on a body shop's or a hospital's. Three of the four routes need no code at all from the sender. The fourth is one HTTP call. This page is the shape of it - the full specification goes to your development team.
Different senders have different limits. A carrier's IT team will call an API; a repair shop will send an email and nothing else. Both are supported, and the case does not care which route each document took.
A folder per matter on a local path or an Azure File Share. No login, no code, no library to install.
Attachments to a monitored inbox. Nothing at all to build on the sender's side.
Your system posts a document or a structured payload. One HTTP call.
The web console, for the files that will always arrive by hand.
Drop the documents, write the manifest last. The manifest is what tells us the set is complete - which is why it goes in last.
inbox/
CLM-2026-4472/
POLICY_declarations.pdf
CLAIM_loss-notice.pdf
INVOICE_repair.pdf
manifest.json ← you write this last
report.html ← we write these
report.pdf
findings.csv
Describe the set explicitly in the manifest, or let filename prefixes resolve the roles, or let the documents identify themselves from their own fields.
archive/yyyy/MM/ on success, exceptions/ on failure - with a reason, not a silent move.
Nothing needs to reach into your systems. You put files where we can read them, and we put results back beside them.
For systems rather than people. Submit a document or a structured payload against a case reference; the case assembles itself and validates when it is complete.
# illustrative - your tenant's base URL and credentials
# are issued during onboarding
POST /v1/cases/CLM-2026-4472/documents
Authorization: Bearer <token>
Content-Type: application/json
{
"role": "POLICY_COPY",
"template": "carrier-policy-v3",
"payload": {
"policyNumber": "PMC-88213",
"inForceFrom": "2025-04-01",
"inForceTo": "2026-03-31",
"insuredName": "A. Kapoor",
"deductible": 500.00
}
}
The response tells you what the case now has, and what it is still waiting for.
202 Accepted
{
"caseRef": "CLM-2026-4472",
"status": "AwaitingDocuments",
"received": ["POLICY_COPY", "CLAIM_FORM"],
"outstanding": ["SURVEY_REPORT", "GARAGE_INVOICE"]
}
You do not poll. When a case finishes validating, we post the outcome and where to fetch the reports.
POST https://your-system.example.com/valinexis-hook
{
"caseRef": "CLM-2026-4472",
"outcome": "Failed",
"severity": { "blocker": 1, "major": 2, "minor": 4 },
"moneyAtStake": 1810.00,
"reports": {
"html": "…/report.html",
"pdf": "…/report.pdf",
"csv": "…/findings.csv"
}
}
| Outcome | What it means | Who it needs |
|---|---|---|
| Passed | Every rule in the pack ran and nothing blocking was raised | Nobody - it moves on |
| Failed | The case is complete and something does not hold up | A reviewer or adjuster |
| Incomplete | The case never got everything it needed before its window expired | Whoever chases the paperwork |
The same three artefacts on every route, written back beside the documents and available in the console.
The readable report - findings ranked worst-first, passed checks with their reasoning, and every rule stated in plain words.
The same report as a file you can attach to a claim record or send to a supplier.
One row per finding - rule, severity, the two documents, values found and expected, and the money at stake.
Mailbox sources accept only addresses you have listed, so an inbox reachable by the whole internet is not an open door.
A source names a secret held in a vault. The secret itself is never stored in the database.
A delivery that failed is queryable with its reason - not something you discover by opening a folder on a server.
A delivery is never processed with one document quietly skipped. A partial result that reads as clean is worse than no result.
A re-run supersedes the previous run rather than replacing it. The earlier findings stay resolvable.
Storage, sources and audit history are scoped per tenant, end to end.
Everything on this page is the shape of the integration, not the specification.
The full Integration Guide - endpoints, authentication, manifest schema, template onboarding and error handling - goes to your development team on request.Intake routes are part of the platform licence. API and webhook access is included from the Business plan upward.
One tenant, one agent, a single intake route.
Every intake route, API, webhooks and data contract templates.
Deployed in your Azure subscription, integrated by your team.
Indicative plans shown for illustration. Final pricing is confirmed after a scoping call.
Endpoints, authentication, the manifest schema, template onboarding and error handling - written for the team that will actually do the work.
+91 7702820516