The Quote response object now has a fifth key in the "value object" returned, inferredValue. When this property has a value, it means that the API has inferred a value different than the one submitted (or in the place of an omitted value) in order to estimate the price of the quote, because the submitted value is invalid for computing a price in some way.

Handling these "inferred values" can be delayed all the way until quote finalize, at which point all fields must be submitted in a valid state in order to proceed (no inference is allowed when finalizing the quote).

Affected Endpoints

🔍 What’s New

The inferredValue key will be at the bottom levels of a quote response body, alongside value, valid, message, and requirements). For example, if invoicePeriod were omitted in the request, the response would look like:

"quote": {
  "id": uuid,
  "options": {
    "invoicePeriod": {
      "value": null,
      "inferredValue": "monthly", // this key in the response is new
      "valid": false,
      "message": "invoice period is required",
      "requirements": [
        {
          "fulfilled": false,
          "kind": "missing",
          "message": "invoice period is required"
        },
        {
          "fulfilled": true,
          "kind": "inclusion",
          "message": null,
          "metadata": {
            "options": [
              "monthly",
              "full_term"
            ]
          }
        }
      ]
    }
  },
  ...
}

In the above case, an inferredValue of monthly and a value of null indicates that, while no value was given yet, Root is assuming the invoice period will be monthly prior to quote finalize. The valid: false, message, and requirements fields continue to identify that the omitted value must be supplied prior to finalizing the quote.

If, for example, invoicePeriod were given as an invalid value:

"quote": {
  "id": uuid,
  "options": {
    "invoicePeriod": {
      "value": "hourly",
      "inferredValue": "monthly", // this key in the response is new
      "valid": false,
      "message": "invoice period must be either 'monthly' or 'full_term'",
      "requirements": [
        {
          "fulfilled": true,
          "kind": "missing",
          "message": null
        },
        {
          "fulfilled": false,
          "kind": "inclusion",
          "message": "invoice period must be either 'monthly' or 'full_term'",
          "metadata": {
            "options": [
              "monthly",
              "full_term"
            ]
          }
        }
      ]
    }
  },
  ...
}

This response's valid: false, message, and requirements continue to correctly identify the value of "hourly" as invalid. We also maintain the invalid value in value: "hourly", indicating what value was previously supplied. And the inferredValue being monthly indicates that, despite the value being invalid, Root was able to infer a valid value to use instead (inference can be used prior to finalizing the quote, but not after).

📌 Important Things to Know

If your integration does not attempt to Finalize quote, likely no action is required from you (but you are free to use this field if you find it helpful).

If your integration does attempt to Finalize quote in order to move on to Bind policy, API functionality should feel largely the same (validations will continue to be returned in the same way given the same requests, and you will be unable to finalize quotes with invalid data). What you may notice, however, is that prices successfully return earlier and more often.

You also have the option to leverage the inferredValue to offer your user corrections to their current quote. For example, if a customer attempts to select coverage combinations that are not allowed due to state regulations, inferredValue may contain one way (of several) the customer could change their coverage selection to be valid.

ℹ️ Note: As of writing, no inference is taking place. Inference behavior to "soft match" coverage selections will be implemented in the following weeks, and will be progressively rolled out to integrations to ensure stable API behavior.

Documentation

Hosted

Fully Embedded

Additional Features

Testing

Frequently Asked Questions

Breaking Changes

MCP Server

Root Embedded API