Unum
Technical documentation for integrating with Unum through Noyo
API: Requests COBRA: Not supported Geographies: All Group Size: All Lines: add, critical, dental, hospital, life, ltd, std, vision Name: Unum Network: Sync New Group Connection Time: 5–10 days Unsupported: -
Group connections
Create a group connection request to manage groups through the Noyo platform.
In the group_data
object for the create endpoint, use either the master agreement number or the Unum policy ID as the ****carrier_group_id
.
- For ****master agreement number, the format expected is an alphanumeric string of flexible length (often 19-21 characters).
- For policy ID, the format expected is a numerical string of 8 characters. If a policy ID is fewer than 8 characters, add leading zeroes. For example, “123456” becomes “00123456”.
Some groups may have multiple policy IDs under a single master agreement number. Any request for a single policy ID will result in a single group configuration, containing all policy IDs associated with that master agreement number.
Sandbox testing
You may use the following special Unum policy ID as the carrier_group_id
in order to simulate different group connection statuses. If you use a policy ID listed below, the group connection will asynchronously update with the corresponding status within 10 seconds of submission. Only the first three digits are evaluated to figure out the target status (e.g. 989 means noyo_review
). Since group connections should be unique by a carrier ID and carrier group ID combination, you may use the final characters to iterate and test this interaction further.
Test ID Pattern | Resulting Status |
---|---|
989*** | noyo_review |
767*** | waiting_on_carrier |
545*** | action_required |
323*** | unable_to_connect |
212*** | carrier_authorization |
Carrier configurations
Dynamic config is recommended for all new Noyo integrations and makes carrier-specific config values no longer required.
Group, plan, and member configurations are where Noyo shares and receives details that are unique to a carrier. Every other part of Noyo’s payloads are standardized, but the configurations hold the unique fields and classifications that change from connection to connection. As part of preparing to connect to a new carrier, you need to understand the contents of each configuration and be sure your system is able to send the required data for each member.
Get the group configuration from Noyo
The group carrier configuration endpoint returns information about how the group is labeled and categorized within the carrier’s system. You can also see this data in the Command Center on a group’s detail page by clicking one of their carrier connections.
Groups that have Unum coverage will be configured with a master_agreement_number
string, which is the primary group identifier with Unum, along with a list of one or more division_ids
, ****eligibility_classes
, and policy_id
s to categorize employees enrolling in coverage.
Get the plan configuration from Noyo
The details in the plan configuration should be used to map each Noyo plan to the corresponding plan in your own system. Importantly, each plan configuration has details about which populations are connected to an individual plan. Groups with multiple populations may link a plan with one or more of them.
Send the member configuration to Noyo
Each member request sent to Noyo can contain a configuration section. Depending on each carrier’s requirements, you may need to use this section to include carrier-specific identifiers like classes, subdivisions, or bill groups.
Member requests to enroll in Unum coverage may include optional division_id
, optional eligibility_class_code
, and optional policy_ids
matching the corresponding values in the group plan configuration, respectively. The policy_ids
object is a mapping from the Noyo plan IDs to the Unum policy IDs, grouped by the plan’s Line of Coverage.
If the caller omits any of these values, Noyo will attempt to resolve the correct values in cases where only one option is available for the member. Noyo will reject the request if the information provided isn’t enough to resolve to a single plan.
Carrier-specific validations
None.
Carrier-specific behaviors
Unum does not prevent open enrollment transactions from being sent at any time of the year, so Noyo sets open_enrollment_end_date
s to 9999-12-31. Depending on their internal logic, Unum may apply the transaction or not - Noyo will monitor each transaction.
Unum does not expose volume rules for any plans, and so Noyo will accept any volume amount submitted by the platform. Noyo will return the amount assigned to the member by Unum. If EOI is required, the member will be contacted directly.
Unum does not allow automatic changes to first_name
****or date_of_birth
for dependents. Noyo will resolve these changes manually, but a longer SLA will apply (up to 10 days in some cases).
EOI
Evidence of insurability (EOI) may be required for Voluntary Life coverages.
Was this page helpful?