For decades, benefits software platforms and brokers have settled for electronic data interchange (EDI), spreadsheets, and forms to submit data to the carrier. These systems can only “deliver the mail,” i.e. send data to the carrier with limited transparency about how and when it’s processed.

Today, connectivity can happen in near real-time thanks to the ability to share information over application programming interfaces (APIs). I would argue, however, that APIs only provide a framework to move data — so unless you have the right systems in place, APIs won’t deliver an experience that’s better than EDI, in fact you may end up moving bad data faster.

Here is a look at how we can do more with APIs as an industry.

Not just an EDI replacement

Replacing EDI with APIs is good, because APIs deliver information faster. But there’s more to it than just replacing EDI. A complete set of APIs allow for the ability to read in addition to the ability to write. The ability to read (i.e. query) unlocks many more possibilities to craft modern enrollment experiences for users.

Some examples of being able to read:

1. Querying plan and group structure rather than relying on emailed PDF docs and spreadsheets. Especially helpful during open enrollment!

2. Pulling a member and dependent roster for a particular group for auditing purposes whenever necessary.

3. Capturing the exact status of an enrollment and knowing if it was successful and displaying directly to the member.

When to push 

The ability to read and write is what separates an API (REST) from traditional EDI. But having that ability poses a question — when should you use push and when should you use pull? This can be a hotly debated topic, but my honest opinion is that push (POST/PUT) should be used when the expected outcome is to “write.” For querying, it only makes sense to pull (GET).

Here is why:

• With push updates, a benefits software knows exactly when information was passed to a carrier (hopefully close to real-time). Push updates natively receive an instant response from an endpoint as to whether the update was successful or contains some sort of error (HTTP responses).

• If you rely on a pull (sometimes in the form of a webhook), you would not receive an instant response or have control over when a carrier retrieves the information (e.g. “it’s not real-time”). There also needs to be some sort of feedback communication setup if bad data causes the retrieval to blow up. This adds steps and in some ways makes it more confusing than EDI.

When to pull

Pull should be considered when you want to query information when you need it. Pulls are great for gathering quotes, plan and group structure, and downloading a full member roster. They’re also perfect for displaying statuses for enrollment and evidence of insurability (EOI) statuses to the member.

Bringing it all together

When you bring together the possibilities of being able to read and write from a carrier’s system, you can craft an experience for customers that you control and define.

Imagine being able to show a new hire a status tracker for their coverage at the carrier. Also, imagine a broker having peace of mind knowing exactly when open enrollment elections for a group have been accepted and processed. These visions can become a reality with the use of APIs.

Working with Noyo

At the end of the day, a set of APIs is only a blank canvas of possibilities. When you work with Noyo, whether a benefits platform or carrier, we provide a complete API experience for your brokers and members. This includes push button group connection setup, member enrollment updates with detailed processing statuses, programmatic auditing (round-trip confirmation), and open enrollment automation. 

Our vision is to bring the modern enrollment experience to the industry through our network of benefits platforms and carriers. To learn more, reach out for a call — I’d be happy to answer your questions.