Skip to main content
This page documents the data structures and conventions used across all V1 API endpoints.

Common Conventions

IDs

All entity identifiers are UUIDs (RFC 4122):
"550e8400-e29b-41d4-a716-446655440000"

Timestamps

Timestamp conventions differ between the unified entity endpoints and the policy / task / file endpoints:
  • Unified entity endpoints (exposure, event, quote, submission, person, organization) return createdAt / updatedAt as epoch-second integers inside the entity envelope:
    1736937000
    
  • Policy versions/transactions, tasks, files, and reporting return timestamps such as transactionTimestamp, createdAt, and deadline as ISO 8601 strings in UTC:
    "2026-04-14T10:30:45.123Z"
    
Each entity’s overview page documents its exact response shape.

Dates

Date-only fields (startDate, endDate, effectiveDate, policyStartDate, policyEndDate) use ISO 8601 date format:
"2026-01-15"

Nullable Fields

Fields that may be absent are typed as T | null. For example, policyId: string | null means the field is always present in the response but may be null.

Pagination

Pagination differs between the unified entity list endpoints and the notes / tasks / files list endpoints.

Unified entity list endpoints

The entity list endpoints (exposure, event, quote, submission, person, organization) return:
{
  "items": [],
  "hasMore": false,
  "totalCount": 0
}
FieldTypeDescription
itemsarrayEntity envelopes for the current page
hasMorebooleanWhether more pages exist after this one
totalCountintegerTotal matching records across all pages
Query parameters:
ParameterTypeDefaultDescription
filterTextstringFree-text search (entity-specific fields)
sortBystringcreatedAtField to sort by (any configured field)
sortDirectionasc | descdescSort direction
pageNumberinteger0Zero-based page index
pageSizeinteger51Items per page

Notes, tasks, and files

The notes, tasks, and company-files list endpoints use 1-based page / pageSize query parameters (page=1 is the first page). See each endpoint’s reference for its exact response shape.

fieldModelV1Data

Most V1 entities store their custom field data in a fieldModelV1Data object. The shape of this object is defined by your company’s field configuration — call the entity’s /configuration endpoint to discover available fields, types, and validation rules. Keys in fieldModelV1Data are field reference IDs (the stable identifiers you define when configuring fields).

Field Value Types

Field TypeJSON TypeExample
Textstring"Acme Corp"
Numbernumber42
Booleanbooleantrue
Dateobject{ "day": 15, "month": 1, "year": 2026, "timezone": "America/New_York" }
Single-select option setstring"commercial"
Multi-select option setarray of string["general_liability", "property"]

Date Fields

Date fields in fieldModelV1Data are represented as objects with individual components:
{
  "policyEffectiveDate": {
    "day": 15,
    "month": 1,
    "year": 2026,
    "timezone": "America/New_York"
  }
}
PropertyTypeDescription
daynumberDay of the month (1-31)
monthnumberMonth (1-12)
yearnumberFour-digit year
timezonestringIANA timezone identifier
API parameters that accept dates directly (such as policyStartDate, effectiveDate, and other endpoint-level fields) use ISO 8601 date strings ("2026-01-15"), not the component object format. The component format is specific to custom field data inside fieldModelV1Data.

Option Set Fields

Option set values are stored as string keys (not labels). Use the /configuration endpoint to map keys to human-readable labels. Single-select:
{
  "exposureType": "commercial_property"
}
Multi-select:
{
  "coverageLines": ["general_liability", "property", "auto"]
}
The configuration schema uses oneOf to enumerate valid options:
{
  "exposureType": {
    "type": "string",
    "title": "exposureType",
    "oneOf": [
      { "const": "commercial_property", "title": "Commercial Property" },
      { "const": "residential", "title": "Residential" }
    ]
  }
}

Configuration Schema

All entity types have a /configuration endpoint that returns a JSON Schema (Draft 2020-12) describing valid field data, wrapped under a top-level fields key:
{
  "fields": {
    "$schema": "https://json-schema.org/draft/2020-12/schema",
    "type": "object",
    "properties": {
      "fieldReferenceId": {
        "type": "string",
        "title": "fieldReferenceId",
        "format": "date"
      }
    },
    "required": ["fieldReferenceId"]
  }
}
For entities that embed exposures (Quote), the embedded exposure schema is nested under the corresponding join field (e.g. exposures) within the same fields schema, not returned as a separate top-level key. Calculated values, server-populated fields, and lifecycle fields are excluded.

Schema Format Values

The format property indicates the semantic type of a field:
FormatJSON TypeDescriptionExample Value
datestringISO 8601 date"2026-01-15"
emailstringEmail address"user@example.com"
phonestringPhone number"+1-555-123-4567"
currencynumberMonetary amount15000
percentstringPercentage"15.5"
addressstringPhysical address"123 Main St, ..."
entity:exposurestringReference to an exposure type"commercial_property"

Entities

Entity envelope

The unified entity endpoints (exposure, event, quote, submission, person, organization) all return the same generic envelope. All entity-specific field values live inside fieldModelV1Data, keyed by field referenceId — there is no top-level companyId, policyId, or submissionId.
FieldTypeDescription
idstring (UUID)Entity identifier
fieldModelV1DataobjectField values keyed by referenceId, including calculated/auto-set values (e.g. submissionNumber, quoteStatus) and join field IDs
createdAtinteger (epoch seconds)Creation time
createdBystring | nullUser ID of the creator, or null
updatedAtinteger (epoch seconds)Last update time (equals createdAt if never updated)
updatedBystring | nullUser ID of the last updater, or null
createdByNamestring | nullDisplay name resolved from createdBy
updatedByNamestring | nullDisplay name resolved from updatedBy
See each entity’s overview page (Exposures, Events, Quotes, Submissions, Persons, Organizations) for its framework-required fields and example payloads.
Cross-entity links are expressed as Join fields inside fieldModelV1Data (for example quoteSubmission on a quote, or eventPolicy on an event), not as separate top-level keys. Calculated and lifecycle fields (e.g. quoteStatus, quoteNumber, submissionNumber) are resolver-populated and cannot be set via the API.
The /configuration response shape is documented under Configuration Schema above.

Directory entities (Persons & Organizations) and custom objects

Persons and Organizations are built-in Directory entities backed by the custom-object model; both use the entity envelope above and the company.fmv1_custom_object:* permission family. Configurable relationships between objects use these cardinality values: Relationship cardinality values: one_to_one, one_to_many, many_to_one, many_to_many

Policy Model

Policies use a transaction-based, temporally-versioned data model. Rather than directly editing policy fields, you submit transactions (new business, endorsement, cancellation, etc.) that produce immutable versions. For a deep dive, see Policy Concepts.

Policy Version

Each transaction produces a new policy version containing one or more segments — date ranges where the policy state is identical.
FieldTypeDescription
policyIdstring (UUID)Policy identifier
policyVersionintegerVersion number (incrementing)
transactionIdstring (UUID)Transaction that produced this version
startDatestring (date)Policy term start
endDatestring (date)Policy term end
createdAtstring (ISO 8601)Version creation timestamp
fullTermPolicyInfoobject | nullEndorsable full-term policy info (term dates, renewal pointer, primary insured) — hoisted read-once
fullTermPolicyBillingInfoobject | nullDerived full-term billing aggregates — hoisted read-once
fullTermPolicyRatingResultobject | nullDerived canonical policy-level rating result — hoisted read-once
segmentsPolicySegment[]Array of policy segments

Policy Segment

A segment is a date range within the policy term where the policy state is constant. Segments are derived from final state — they are not one-per-transaction.
FieldTypeDescription
startDatestring (date)Segment start date
endDatestring (date)Segment end date
fieldModelV1DataobjectPolicy field data for this date range

Policy Transaction

Transactions are the immutable record of changes to a policy.
FieldTypeDescription
idstring (UUID)Transaction identifier
policyIdstring (UUID)Policy identifier
policyVersionintegerVersion this transaction produced
actionstringTransaction type (see below)
effectiveDatestring (date)When this change takes effect
transactionTimestampstring (ISO 8601)When this transaction was recorded
createdAtstring (ISO 8601)Creation timestamp
createdBystring | nullUser ID of creator
deltasTransactionDelta[]Field-level changes (optional)
Transaction action values: NEW_BUSINESS, ENDORSE, CANCEL, REINSTATE, RENEW

Transaction Delta

Deltas describe the field-level changes a transaction made within a date range.
FieldTypeDescription
idstring (UUID)Delta identifier
transactionIdstring (UUID)Parent transaction
startDatestring (date)Date range start
endDatestring (date)Date range end
pathstringJSON pointer to the changed field
actionstringAdd, Remove, or Overwrite
valuestring, number, or objectNew value (for Add and Overwrite)

Policy List Item

List endpoints return a summary with optional segment detail:
{
  "summary": {
    "id": "...",
    "policyId": "...",
    "companyId": "...",
    "createdAt": "2026-01-15T10:30:00.000Z",
    "policyVersion": 3,
    "versionCreatedAt": "2026-03-01T14:00:00.000Z",
    "fullTermPolicyInfo": { ... },
    "fullTermPolicyBillingInfo": null,
    "matchedSegments": [
      { "startDate": "2026-01-15", "endDate": "2026-07-15" }
    ]
  },
  "segments": []
}

Earned Premium

Per-policy earned premium calculations, available at different detail levels.
FieldTypeDescription
policyIdstring (UUID)Policy identifier
policyNumberstringHuman-readable policy number
earnedPremiumTotalnumberTotal earned premium for the period
transactionTotalsarrayPer-transaction contribution breakdown
daysarray | undefinedPer-day breakdown (when requested)
Detail levels (set via detail query parameter):
ValueDescription
transactionsPer-transaction totals only (default)
daysAdds daily earned premium totals
daysAndTransactionsAdds daily totals with per-transaction contributions

Bordereau Row

Bordereau export provides a flat row per policy transaction for reporting.
FieldTypeDescription
policyNumberstring | nullPolicy number
primaryInsuredNamestring | nullPrimary insured
transactionActionstringTransaction type
policyVersionintegerVersion number
effectiveDatestring (date)Transaction effective date
transactionTimestampstring (ISO 8601)When recorded
policyStartDatestring (date)Term start
policyEndDatestring (date)Term end
createdAtstring (ISO 8601)Creation timestamp
createdBystring | nullCreator
policyPremiumnumber | nullTotal premium at this version
policyPremiumChangenumber | nullPremium change from prior version
additionalColumnsobjectCompany-configured additional columns

Entity Relationships

Submission ──has many──> Quotes
Quote ──seeds──> Policy (created via transaction)
Policy ──has many──> Transactions ──produces──> Versions ──contains──> Segments
Exposure ──standalone entity──
Quote / Policy ──embeds──> Exposure data (snapshot, can diverge)
Event ──optionally linked──> Policy (via policyId)
Custom Object ──relationships──> Custom Object (configurable cardinality)
RelationshipDescription
Quote → PolicyA quote’s data can seed a policy created via a new-business transaction; policyId links the two
Policy → TransactionsTransactions are the write path; each produces a new version
Policy → Versions → SegmentsVersions contain segments representing the policy state over time
Quote / Policy → ExposureQuotes and policies embed exposure data. They store a reference back to the standalone exposure object, but the embedded exposure data can evolve independently — e.g., an endorsement may change exposure fields on the policy without modifying the standalone exposure record
Event → PolicyEvents may reference a policy via policyId
Custom Object → Custom ObjectConfigurable relationships with defined cardinality