The Chain.io network functions by linking together adapters written by different companies to build flows that exchange information between software packages that are not directly compatible.
For example, you might be a developer for the world's greatest CO2 Emissions calculator. Your system can take shipment details from a shipper via your API, and as the shipment moves through its lifecycle, you can regularly update the shipper with the actual carbon usage across all of the various shipment legs based on the calculations you make within your software.
You've carefully crafted an API endpoint that allows your customers to post all of their shipment details, and you provide the option to subscribe to a webhook which provides updated emissions data at various points in the shipment's lifecycle.
You have a problem though. Many of your customers use LegacyCo's transportation management system (we'll call it LegacyTMS). LegacyTMS does not have the ability to connect to your API, and your customers don't have the internal resources to build a middleware solution to take data extracts from LegacyTMS and turn them into your API call.
Returning data is also difficult. LegacyTMS can't subscribe to your webhook. In fact, the only way to get emissions data into LegacyTMS is to put a CSV file on a unique SFTP site for each customer.
Instead of coaching each of your customers through building a custom integration or doing a ton of professional services work, you decide to let Chain.io do the heavy lifting. You'll write an adapter that listens for calls from Chain.io's Shipment Registration webhook and converts them into your API call, and you'll write a second adapter that takes your webhooks' output and makes a call to Chain.io's Emissions Update API.
Why is this better than just building connectivity to LegacyTMS directly?