Group connections
Create a group connection request to manage groups through the Noyo platform. In thegroup_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”.
Sandbox testing
You may use the following special Unum policy ID as thecarrier_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.
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 amaster_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 optionaldivision_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 setsopen_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).