A vendor, MGA or TPA needs to send submission or claims data to a carrier. The carrier points to its API. Another team proposes a nightly ETL job. A third suggests routing everything through a gateway.
Three names, one data problem, and each tool solves a different part of it. Pick the wrong one and the sender rebuilds a connector for every carrier, or the carrier finds bad data after it reaches an underwriter or adjuster.
This article defines an integration gateway, explains how it differs from an API and from an ETL job, and gives you a side-by-side comparison and a build-versus-buy framework to use before you commit to a route.
What Is an Integration Gateway?
An integration gateway is a single, secured entry point that lets outside systems send data into a carrier's core platform without building a separate connector for each sender. It sits between the sender and the platform and handles the work every sender would otherwise repeat.
What a Gateway Does With Each Request
A gateway receives a payload, authenticates the sender, checks that the payload is well formed, maps each field to the structure the core platform expects, and delivers it. Then it records what happened.
That last step matters. Every request, response, and error lands in a log that both the sender and the carrier can read, so a failed submission has a visible cause instead of a silent drop.
What a Gateway Does Not Do
A gateway is not a data warehouse pipeline, and it does not replace the core platform. It does not decide what a submission means or whether a claim is covered. It moves data to the right place in the right shape and reports back.
Who Sends and Who Receives
Senders include underwriting workbench vendors, rating and pricing vendors, MGAs, MGUs, TPAs, brokers, and agencies. Receivers are the underwriters and adjusters at the carrier, who need complete data in their queues.
The technology owner, usually the CIO, decides which route all of those senders use.
What Is an API, and Where Does It Stop?
An API is a published contract that defines how one system asks another for data or sends data to it. It specifies the endpoints, the formats, and the rules. It does not build the sender's side of the exchange.
An API Is the Door, Not the Route
Think of an API as the door to a building, with a posted list of what each entry requires. The door tells a visitor what to carry and where to knock. The visitor still has to find the right room.
What the Sender Still Builds
Behind a carrier's API, each sender writes code to authenticate, shape its own data to the carrier's fields, handle errors and retries, and keep pace with version changes. That work repeats for every carrier the sender serves.
Why One API Still Means One Connector Per Sender
A carrier can publish one API and still end up with many one-off integrations, because each sender's data looks different. The API standardizes the door. It does not standardize what each sender carries through it.
What Is an ETL Job, and Why Is It a Different Tool?
ETL stands for extract, transform, load. An ETL job pulls data from a source system on a schedule, reshapes it, and loads it into a target, typically a data warehouse or data lake.
Where ETL Fits
ETL suits reporting, analytics, and bulk loads where hours of delay are acceptable. A finance team that needs yesterday's premium totals in a dashboard is a good ETL case.
Where ETL Falls Short for Intake
An ETL job runs after the fact. If a sender's payload is missing a mandatory field, the job finds out during the next run, and the sender hears about it later or never.
Submission and claims intake needs the opposite. The sender needs an answer on the request itself, while the person who sent it is still looking at the screen.
Why Teams Confuse the Two
Both move data between systems, and both involve mapping fields. The difference is timing and audience. ETL serves analysts after the fact. A gateway serves senders and adjusters during the exchange.
Integration Gateway vs API vs ETL Job: Side by Side
The three are easiest to separate by asking what each one is built to do, when it responds, and who feels the result.
The Comparison Table
Dimension | API | ETL job | Integration gateway |
|---|---|---|---|
Primary purpose | Defines how systems request and send data | Moves bulk data to a warehouse or lake | Receives, validates, maps, and delivers data from outside senders |
Timing | Request and response | Scheduled batch | Request and response |
Who builds the sender's side | The sender | The data team | The sender configures its payload against a shared route |
Field mapping | Written in each sender's code | Written into each job | Defined once per sender in one place |
Feedback to the sender | Error codes the sender must interpret | After the run completes | Validation and flagged gaps on the request |
Who consumes the result | Developers | Analysts and reporting teams | Underwriters and adjusters in their workflow |
Visibility | Depends on each sender's logging | Job logs | One request, response, and error log shared by both sides |
How the Three Work Together
The three are layers, not rivals. A gateway often sits in front of the carrier's APIs and calls them on the sender's behalf. ETL jobs then move the stored data into a warehouse for reporting.
The Who-Is-Waiting Test
Ask who is waiting on the data. If an underwriter or adjuster waits on it to do work, use a route that responds on the request. If an analyst waits on a report, use ETL. If a developer needs a defined way to ask for data, use an API.
Build vs Buy: How to Choose a Route Into Your Core Platform
Fragmentation sets the stakes. Insurers manage an average of 17 data sources feeding their premium processes, according to AutoRek's 2026 Insurance Report, a March 2026 survey of 250 insurance and healthcare insurance managers in the UK and U.S.
Every added source is another sender, another payload shape, and another mapping to maintain.
Three Ways to Build the Route
Option | Setup effort | Upkeep | Who owns the mapping | Where the data runs |
|---|---|---|---|---|
Hand-built connector per sender | One full build for each sender and carrier pair | Reworked after each platform or carrier upgrade | The sender's developers | Set separately by each build |
In-house shared gateway | Large up-front build, then smaller per sender | The carrier's integration team | The carrier and sender together | Inside the carrier's environment |
Prebuilt gateway from a vendor | Small per sender, because the route exists on day one | The vendor tracks platform changes | The sender confirms, the vendor's tool drafts | Inside the carrier's environment when deployed there |
Five Questions to Ask Before You Choose
How many senders need a route today, and how many will need one within a year?
Does the data contain PII or PHI, and where is it allowed to run?
Who confirms a field mapping, and who is accountable when one is wrong?
What happens to the flow when the core platform adds a mandatory field?
Do the sender and the carrier see the same log when a request fails?
Warning Signs That Your Current Route Has Run Its Course
Onboarding a new sender restarts the project from zero. Support tickets about failed submissions outrun the team's ability to explain them.
A platform upgrade breaks a sender's connector, and nobody finds out until an underwriter asks where a submission went.
How InsOps Helps
InsOps builds an insurance-trained AI that assists with moving submission and claims data into your core platform. LiLa, our insurance-trained LLM, drafts the field mapping from a sender's payload to your platform's structure, and a person at the sender reviews and confirms every mapping before data moves.
The InsOps Integration Gateway gives MGAs, TPAs, brokers, and underwriting vendors a prebuilt route into your policy and claims systems. Senders register in a self-service portal, bring their payload, and configure it without building their own connector. The gateway flags incomplete data before it reaches an underwriter or adjuster.
The gateway runs inside your own environment, so PII and PHI stay in controlled infrastructure. InsOps is a Guidewire technology partner with prebuilt connectors to the core platforms carriers run.
If you are evaluating how to exchange submission and claims data with your core platform without a custom connector build for every sender, contact us to talk through what this looks like for your operation.
Frequently Asked Questions
What is an integration gateway?
An integration gateway is a single, secured entry point that receives data from outside systems, validates it, maps it to the structure a core platform expects, and delivers it. It also logs every request, response, and error.
Is an integration gateway the same as an API gateway?
No. An API gateway controls access to APIs through authentication, routing, and traffic limits. An integration gateway covers that entry point and also handles payload mapping, validation, and feedback on the data a sender submits.
When is an API enough on its own?
An API is enough when one sender connects to one platform and has the engineering capacity to build and maintain its own side. The case changes when many senders connect to the same carrier, because each one repeats the same authentication, mapping, and error handling.
Can an ETL job replace an integration gateway?
No. An ETL job runs on a schedule and reports problems after the run, which suits reporting and bulk loads. Intake needs a response on the request, so the sender can fix a missing field before the payload reaches a queue.
What should a team track to know the route works?
Track the share of payloads accepted on the first send, the share flagged as incomplete before they reach an underwriter or adjuster, and the time it takes to onboard a new sender. Also track how long a platform change takes to reach every sender's mapping.
How does the InsOps Integration Gateway help?
It gives senders a prebuilt route into a carrier's core platform, with LiLa drafting the field mapping from the sender's payload. A person at the sender reviews and confirms that mapping before any data moves.
What slows down a sender onboarding to a carrier's core platform?
Four things cause most of the delay: waiting on credentials, disagreements over field mapping, payloads missing mandatory fields, and platform upgrades that change what is required. A route that validates on the request and logs every error shortens each of those waits.