From Navi to API: When Conversational AI Meets Programmatic Extraction

Most enterprise AI platforms force a choice. Either domain experts get a conversational interface they can use without engineering, or engineering teams get a programmable API they can integrate into production systems. Rarely both. And when both exist, they are often separate products with separate data models, separate logic, and separate maintenance burdens.

Parsewise takes a different approach. Navi (the conversational workspace) and the Parsewise API are two interfaces to the same underlying technology: the Parsewise Data Engine (PDE). An extraction agent created by a claims analyst in Navi is the same agent an engineering team calls through the API. The schemas, the logic, the source attribution, the outputs are identical.

This matters more than it might appear. It means an organization can start with exploration and move to automation without re-implementing anything.

Two Interfaces, One Engine

Navi is Parsewise’s conversational workspace. It is designed for domain experts who know their documents, their KPIs, and their decision criteria, but who do not write code.

The workflow is direct:

  1. Upload documents in any format: PDF, Word, Excel, PowerPoint, images, scans.
  2. Ask a question in plain English. Navi proposes, creates, and executes specialized extraction agents based on the question.
  3. Export structured, traceable results.

Behind each interaction, Navi translates the user’s intent into a structured set of tasks. These tasks are handled by independent workers that focus on specific dimensions of the problem: claim status, financial exposure, regulatory compliance, or whatever the question requires. The PDE processes every page, extracts entities in parallel across thousands of pages, and resolves results into structured, auditable data.

Consider three real workflows:

  • An insurance claims analyst uploads hundreds of claims documents and asks Navi to flag the three financially or legally riskiest open claims. Navi creates agents for claim status, reserve amounts, litigation status, and risk indicators, then synthesizes results into a structured table with source citations.
  • A private markets analyst uploads a data room and asks for an investment-ready company profile. Navi extracts financial performance metrics, market analysis, competitive landscape, and customer unit economics, flagging inconsistencies across documents.
  • A mortgage broker uploads application files and gets a structured financial summary of income, expenditures, and deposit sources in minutes.

In each case, the analyst gets structured outputs with citations linking directly to the original documents. No engineering involvement. No pipeline configuration.

The API: The Engineering Team’s Interface

The Parsewise API makes the same extraction capabilities programmable. It exposes RESTful endpoints for projects, documents, agents, extraction, and results, with structured JSON output, webhook notifications, and API key authentication.

The API is built for technical ops teams that need to automate document processing workflows: mortgage applications flowing in from a broker portal, claims documentation arriving from a TPA, dossier submissions feeding an underwriting queue. These are repeatable, high-volume processes where manual triggering is not practical.

Key capabilities:

  • Schema-based extraction with structured JSON output
  • Webhook notifications for extraction completion, failures, and inconsistencies
  • OpenAPI specification and interactive API reference for integration
  • Rate limiting and API key authentication for production workloads

The API is available on Enterprise plans.

Why a Shared Engine Matters

The critical design decision is that Navi and the API share the PDE. This is not a cosmetic detail. It has three practical consequences.

No re-implementation

When a domain expert builds an extraction agent in Navi, refines it over several iterations, and validates that it produces the right outputs, that agent can be called through the API without modification. The schema, the business rules, the validation logic, the inconsistency detection: all of it transfers. Engineering teams do not need to reverse-engineer what the domain expert configured. They call the same agent.

This eliminates a common failure mode in enterprise AI deployments. In many organizations, the gap between “the business team validated a prototype” and “engineering shipped it to production” is months of re-implementation, specification drift, and regression testing. When both sides operate on the same engine, that gap collapses.

Consistent outputs

An extraction run through Navi and the same extraction run through the API produce identical results. The same cross-document reasoning, the same entity linking, the same contradiction detection, the same source attribution down to the word-level bounding box. This consistency is non-negotiable for regulated industries where audit trails must demonstrate that the production system behaves the same way it did during validation.

Domain experts stay in the loop

The shared engine means domain experts can continue refining agents in Navi while engineering teams consume them through the API. A claims analyst who discovers a new edge case (a specific type of reserve discrepancy, an unusual coverage exclusion) can update the agent conversationally. The next API call picks up the change. No deployment cycle. No ticket to engineering. No specification document.

This is the model described in Parsewise’s Software 3.0 thesis: enabling business experts to modify structured data transformations directly, without going through IT.

The Typical Progression

Organizations rarely start with the API. The pattern is more organic than that.

Phase 1: Exploration with Navi

A domain expert, typically someone frustrated with manual document review, uploads a set of documents and asks a question. Maybe it is “Extract all coverage limits from these 200 policy documents” or “Flag inconsistencies in this data room’s financial statements.” Navi creates agents, runs the extraction, and returns structured results with citations.

This phase is about proving value on real documents. The expert refines the agents: adjusting dimensions, adding validation rules, handling edge cases specific to their document types. At the end of this phase, the organization has working extraction logic that produces validated outputs, built by the person who understands the domain best.

Phase 2: Repeatable workflows

The expert starts running the same agents on new document packages as they arrive. What began as a one-off exploration becomes a recurring workflow. Weekly loss run reconciliations. Monthly portfolio reviews. Ongoing submission intake. Navi handles these workflows well, but they are triggered manually.

Phase 3: Programmatic automation via API

When volume or frequency makes manual triggering impractical, engineering teams integrate the API into existing systems. Documents flow in automatically (from SharePoint, Google Drive, email, or custom ingestion pipelines), extraction runs are triggered programmatically, and results are pushed to downstream systems via webhooks or database connectors.

The key insight is that the extraction logic does not change between phases. The agents created and refined by domain experts in Navi are the same agents called by the API. The transition from exploration to automation is a change in how agents are triggered, not in what they do.

Phase 4: Continuous refinement

Even after API integration, domain experts continue using Navi to monitor results, handle edge cases, and refine agents as document types evolve. New document formats, new regulatory requirements, new business rules: these are addressed conversationally by the people who understand them, not through engineering change requests. The API automatically picks up the refined logic.

Use Cases by Interface

Workflow Navi API
Initial document exploration and agent design Primary interface Not applicable
Ad hoc analysis on a new document set Primary interface Possible, but Navi is faster for iteration
Recurring extraction (weekly, monthly) Works well at moderate volume Better for high-volume or system-triggered workflows
Automated ingestion from external systems Not applicable Primary interface (SharePoint, Google Drive, email connectors)
Production pipeline integration Not applicable Primary interface (webhooks, DB connectors, structured JSON)
Agent refinement and edge-case handling Primary interface Not applicable
Audit and result verification Primary interface (visual review with source links) Structured JSON with source attribution for programmatic validation

What Both Interfaces Share

Regardless of which interface triggers the work, the underlying capabilities are identical:

  • Exhaustive processing. Every page in the corpus is read. No retrieval gaps, no false negatives from Top-K selection. The PDE processes over 25,000 pages per run with autonomous runs exceeding 5 hours.
  • Cross-document reasoning. Entity linking, contradiction detection, and unified ontology construction across the full document package. See cross-document reasoning for how this works architecturally.
  • Source attribution. Every extracted value links back to its source document, page, and word-level bounding box.
  • Inconsistency detection. Conflicting data across documents is flagged with structured resolution workflows and supporting evidence from each source.
  • Multi-language support. Extraction and output across 70+ languages, including mixed-language document packages.
  • Security and compliance. SOC 2 Type II, GDPR, AES-256 encryption at rest, TLS 1.2+ in transit, no training on customer data. VPC and on-prem deployment options for enterprise customers.

The Organizational Benefit

The separation of interfaces along role boundaries, conversational for domain experts, programmatic for engineering, with a shared engine underneath, addresses a structural problem in enterprise AI adoption.

In most organizations, the people who understand the documents and the decisions are not the people who build the production systems. When these two groups use different tools with different data models, the handoff between “validated prototype” and “production deployment” becomes a source of delay, miscommunication, and regression.

Parsewise’s architecture makes the handoff trivial. The domain expert’s work in Navi is the production configuration. The engineering team’s API integration consumes it directly. Changes made by either side are immediately reflected in the shared engine.

This is why building document processing in-house is harder than it appears. The technical pipeline (ingestion, parsing, extraction) is only part of the challenge. The harder part is keeping business logic, domain expertise, and engineering systems in sync over time. A shared engine that both sides can operate on, each through their own interface, is how Parsewise addresses that challenge.

Ready to see Parsewise in action? Request a demo or contact sales to discuss your use case.

Sources