Glossary

The API uses two vocabularies: insurance domain terms (from the industry) and API-specific terms (envelope shapes, wire tokens, scoping rules that matter only during integration).

Both are defined here. If a term elsewhere in the docs isn't clear, it belongs here — if it doesn't, that's a docs bug; tell us.

Domain terms

Carrier

The insurance company that underwrites and pays the policy — for example, Aetna Accendo, Royal Neighbors, or Mutual of Omaha. The carrier owns the plan tiers, rate cards, and underwriting rules; we surface those decisions verbatim.

Product

A named offering by a carrier — for example, "Aetna Accendo Final Expense" or "Royal Neighbors Whole Life." A product groups one or more rate classes under a single carrier brand.

In a prequalify or quote response, you see it as data.plans[].product with id (prod_<uuid>), name, and class fields.

To filter a prequalify or quote to specific products, pass their product IDs in the request's products[] array. Use the typed catalog constants (like Products.Fex.AetnaAccendo) instead of hardcoding raw IDs. An empty products[] evaluates every product on your roster. See reference catalog for the full product list.

Plan (insurance)

The colloquial name for one product's offer in a prequalify or quote response — the entry you iterate in data.plans[]. Each entry carries the carrier, product, death benefit, and a pricing[] table with one row per rate class. The word "plan" is the response array name; the underwriting tiers within it (immediate, graded, rop) are eligibility categories, surfaced on each pricing row's eligibility.category.

Disambiguation. "Plan" in the prequalify/quote response means an insurance offer (an entry in data.plans[]). "Plan" on the billing surface (/reference/listPlans, /reference/createPlan) means a subscription billing plan — what your account pays us. Same word, completely different meaning. Each operation page tells you which one it means; this glossary entry covers the insurance one.

Plan (billing subscription)

A pricing tier on the API account itself — what the customer is paying us for. Found on the Plans resource of the platform API. Has nothing to do with insurance plans.

Offer

One product's qualifying result for the applicant — an entry in data.plans[] on a prequalify or quote response. A single entry carries the carrier, product, death benefit, and a pricing[] table; each pricing row is one rate class with its own price and eligibility. The best qualifying row is flagged primary: true; alternate and ineligible rate classes are sibling rows in the same pricing[] array. There is no separate other_offers[] array on v3 — every rate class for a product lives in that one table.

Rank

Server-assigned ordering for agent display, attached to each pricing row (pricing[].rank). Lower is better (rank 1 is the carrier's most preferred combination for this applicant). Ineligible rows carry rank: null. Multiple rows can tie. Use rank for default sort order, not for filtering.

Rate class

The carrier's pricing-tier label, surfaced verbatim as pricing[].rate_class — e.g. IMMEDIATE, super-preferred, standard-tobacco. The value set is carrier-specific; treat it as an opaque display string. It is distinct from the eligibility category: the rate class is the carrier's own label, while the category is our normalized underwriting bucket on the same row's eligibility.category.

Modal factor

A multiplier the carrier applies to convert annual premium into other billing frequencies (monthly, quarterly, semi-annual). The factor is carrier-specific.

We resolve it for you: each pricing row's premium.modes is a map keyed by the carrier's mode token (for example ANNUAL, MONTHLY, SEMI-ANNUAL). Each value is the already-computed {cents, display} for that frequency. The premium.amount field repeats the entry named by premium.default_mode.

You read the resolved values; you never compute the factor yourself.

Eligibility category

Our normalized underwriting bucket for a pricing row — the axis the min_rank request filter operates on. Surfaced as pricing[].eligibility.category. The canonical values are:

Category	Meaning
`immediate`	Full benefit from day one.
`graded`	Reduced benefit during the first 1–3 policy years.
`rop`	Return of premium — guaranteed-issue with limited death benefit until the policy matures.
`other`	A qualifying row that maps to none of the more specific buckets above.

For the first three, earlier in the list means a better underwriting outcome (cheaper, fewer restrictions). The category is our bucket, not the carrier's label — for the carrier's own label see rate class.

FEX

Final Expense. A product class for small whole-life policies (typically under $50,000 face value), commonly sold to seniors to cover funeral and burial costs. Wire token: fex.

ROP

Return of Premium. An eligibility category and product variant where the death benefit is limited until the policy matures, but premiums paid are returned (with or without interest) to the beneficiary if the insured dies before maturity.

medsup

Medicare Supplement insurance — coverage that pays for costs not covered by traditional Medicare (Plan G, Plan N, etc.). Wire token: medsup. Medsup quotes require a zip on the request.

term

Term life insurance. Fixed-term coverage (10-year, 20-year, 30-year, etc.) at a level premium. Wire token: term.

preneed

Pre-need (funeral) insurance. Whole-life insurance assigned to a funeral home for prepaid funeral arrangements. Wire token: preneed.

MGA / IMO / Agency

Distribution channels for insurance products.

MGA: Managing General Agency — manages contracts with carriers and supports downstream agents.
IMO: Insurance Marketing Organization — similar role to MGA; the labels overlap regionally.
Agency: generic umbrella term.

Most integrators wire up software that supports agents working under one of these structures.

API-specific terms

`product.class`

The canonical product family string — fex, term, medsup, preneed, annuity. Surfaced as data.plans[].product.class. Use it for display and grouping (e.g. "all FEX offers"), never for narrowing a request. To carry a product selection into a follow-up call, use product.id (the stable prod_<uuid>) — product names can change but the id is stable across renames.

`request_id`

The server-minted ULID (req_<26-char-ulid>) that identifies one request in our logs. Returned on every response (success or error). Persist it alongside your business records — when escalating to support, quote the request_id and we can find the entry directly.

`idempotency_key`

The client-supplied UUID v4 that scopes the server's response cache. The server's deduplication composite is (account_id, Idempotency-Key, request_body_hash). See the Idempotency guide.

`livemode`

Boolean on every response envelope. true if the request was authenticated with a live key (isa_live_*); false for a test key (isa_test_*). Reflects which environment processed the request, not which environment you targeted.

Envelope

The standard five-field response shape:

{
  "object":          "<resource_type>",
  "request_id":      "req_...",
  "idempotency_key": "...",
  "livemode":        false,
  "data":            { ... }
}

Every 2xx response uses this shape. The payload lives under data; the four siblings are provenance.

`plan_offer`

The object discriminator carried on each entry in data.plans[] on a prequalify or quote response. The string plan never appears as an object value — only plan_offer.

`prequalify_result` / `quote_result`

The object discriminator on the top-level envelope of a prequalify or quote response. Lets a single response router dispatch correctly even though the surrounding envelope shape is identical.