For the people who have to integrate it

Your underwriters will judge SnapLine on the screen. You will judge it on whether it creates another system of record, whether the data coming out of it is auditable, and what happens to it when the vendor relationship ends.

SnapLine sits at intake

It reads what arrives, produces a structured record, and passes that record downstream. Your policy administration system, your rating engine and your data warehouse stay where they are. We are not asking you to migrate anything in order to evaluate this.

What arrives

Broker email

API

Upload

SnapLine · intake

Reads what arrivesThe whole bundle, as the broker sent it

Produces a structured recordFields with status, provenance per field, and conflicts carried rather than collapsed

Your estate · unchanged

Underwriting workbench

Policy administration

Rating

Exposure management

SnapLine owns the intake step only. Everything below the dashed line is a system you already run, and nothing is migrated into SnapLine in order to evaluate it. No endpoints, methods or limits are shown here because none are published yet.

The shape of a submission object

The structure below is illustrative. It is not the published contract, the field names are indicative only, and nothing here should be used to size an integration. It is here so that an architect can see what provenance does to a payload before booking a call.

submission
  submission_id
  received_at
  source                      // inbox, API, upload
  documents[]
    document_id
    media_type
    page_count
  record
    fields[]
      name
      value
      status                  // extracted, validated, corrected, absent
      provenance[]
        document_id
        page
        region
      conflicts[]             // other values found, with their own provenance

The part worth looking at is conflicts[]. A field that appears in the slip and again in the schedule with a different value does not get collapsed into one answer before it reaches you. Both are carried, both keep their provenance, and an underwriter’s decision is recorded as a status change rather than as a silent overwrite.

Provenance in the payload

Provenance is not a link to a document. It is a reference to a region of a page of a specific document in a specific submission, and it survives into whatever you export. If your audit requirement is to show a regulator where a bound figure originated, that chain is the point of the product rather than a feature of it.

Endpoints, authentication and limits

These are deliberately blank until engineering confirms them. We would rather publish nothing than publish something an integration gets built against and we then change.

Put an engineer on the call

The demo is built for underwriters. If you are evaluating this as a platform question rather than a workflow question, say so when you book and the call will be scoped accordingly, with someone who can answer at the level you are asking.

Book a technical call