A carrier on Guidewire receives policy, claims, and billing data from MGAs, brokers, TPAs, and software vendors, and every sender formats that data differently. Each route into the core platform solves part of the problem and leaves the rest with your team.
The route you pick decides who maps the fields, who catches missing values, and what breaks when Guidewire ships a release. It also sets how many distribution partners your integration team can take on at once.
This article compares five routes: email and spreadsheets, scheduled file drops, custom point-to-point connectors, carrier-built portals, and an integration gateway. You leave with a four-question check you can run against your own intake today.
What Are the Five Ways Carriers Receive Data From Senders?
Carriers receive sender data through five routes, and most run two or three at once. The routes differ in who maps the data and where errors surface.
Who Sends Data and in What Shape
Four groups send data into Guidewire, and each brings its own format.
MGAs send program and bordereaux data. Brokers send submissions. TPAs send claim and billing updates, and software vendors send whatever their product exports.
Submissions and policy changes land in PolicyCenter.
Claim updates land in ClaimCenter, and billing data lands in BillingCenter.
A carrier that receives all three wants one intake route that works across the Guidewire suite, not one route per product.
The Five Routes at a Glance
Each route moves the same data and hands the work to a different party.
The five routes are email and spreadsheet attachments, scheduled file drops, custom point-to-point connectors, carrier-built portals, and an integration gateway. Routes one and two lean on people and parsers. Routes three and four lean on your engineers.
Route five moves the first draft of each mapping to software that assists, with a person confirming it.
Every route serves the same job: submission intake, plus claim and billing updates, arriving in a form Guidewire accepts.
How Do Email, Spreadsheets, and File Drops Work?
Email attachments and file drops are long-standing routes, and they stay in use because senders already know how to use them.
Route 1: Email and Spreadsheet Attachments
A sender attaches a spreadsheet or PDF and emails it to an inbox your team watches.
A person on your side opens the attachment, reads it, and rekeys values into Guidewire. Missing fields surface when that person notices them, which is after the sender has moved on.
Adding a sender costs nothing up front. Each added sender adds reading and rekeying hours to your intake team.
Route 2: Scheduled File Drops
A file drop replaces the inbox with a shared location, usually SFTP, and a schedule.
The sender exports a flat file on a fixed cadence. A load job on your side parses the file and writes it to Guidewire.
Each sender’s layout needs its own parsing rules, so the rules pile up with every sender. Row-level errors surface after the batch runs, and a corrected file waits for the next cycle.
Teams often ask how an integration gateway differs from an API or an ETL job. The short answer is that a load job parses one sender’s file, while a gateway accepts many senders through one front door.
How Do Custom Connectors and Carrier Portals Compare?
Connectors and portals both put structure in front of the data, and they differ in who builds and maintains that structure.
Route 3: Custom Point-to-Point Connectors
A connector is a build. Your engineers, or the sender’s, write code against a Guidewire API for one specific sender.
Data arrives structured and validated, which is the strength of this route. The weakness is the count: each new sender is a new build, and each Guidewire release means retesting every connector.
Senders repeat that build once for every carrier they serve.
Point-to-point integrations break as carriers add vendors, and the breakage shows up in release testing first.
The case for standardized API gateways over point-to-point connections rests on the same count problem.
Route 4: Carrier-Built Portals
A portal gives senders a screen. They type in or upload data, and your team owns the screen.
Portals fit low-volume senders, because entry is guided and fields are validated as the sender types. High-volume senders resist rekeying, so they ask for a file or API route beside the portal.
Your team builds and maintains the portal and its mapping to Guidewire, so the engineering load stays with the carrier.
The portal is one channel among several, and carriers that onboard agencies and vendors through self-service still need a mapped route behind it.
What Is the Gateway Route, and Where Does Guidewire’s Own Gateway Fit?
An integration gateway replaces many sender-specific builds with one front door. It also raises a naming question, because Guidewire ships a product called Integration Gateway.
Route 5: Map Once, Translate to Guidewire’s Format
The sender registers, maps its own payload once, tests it in a sandbox, and sends.
The gateway validates the payload, returns incomplete data to the sender, and delivers the rest in the format Guidewire expects. Large payloads arrive as a file location instead of an inline body.
A carrier runs this gateway inside its own environment, so the carrier decides where payloads, mappings, and logs live.
Your team provisions the infrastructure, and the infrastructure checklist lists the five layers and the owner of each.
Guidewire’s Integration Gateway and a Prebuilt Gateway Route
Guidewire’s Integration Gateway and a prebuilt gateway route solve different problems, so keep the two names apart.
Guidewire’s gateway is a developer framework. Your engineers write integration apps on it, so the first draft of every sender mapping stays with your team.
A prebuilt gateway route adds what the framework leaves to you: a sender portal, mapping assistance, and a test environment.
How Do You Choose Between the Five Routes?
Run each route through four questions: who maps the data, who catches gaps, what a Guidewire release does, and what adding the next sender takes. We call this the Five-Route Intake Check.
The Five-Route Intake Check
The table puts all five routes against the same four questions.
Route | Who maps the data | Who catches gaps | What a Guidewire release does | Adding the next sender |
|---|---|---|---|---|
Email and spreadsheets | Your intake staff, by hand | Your intake staff, on reading | Staff adjust their rekeying by hand | Adds reading and rekeying load |
Scheduled file drops | Your engineers, one parser per sender | The batch job, after the run | Each parser is retested | A new layout needs a new parser |
Custom connectors | Your engineers or the sender’s, per build | The connector, if its author wrote the checks | Every connector is retested | A new build |
Carrier-built portal | Your engineers, once per screen | The screen, at entry | Your team reworks screens and mapping | New fields need screen changes |
Integration gateway | The sender, drafted with assistance and confirmed by a person | The gateway, at receipt | The mapping is updated in one place | The sender registers, maps, and tests |
Which Route Fits Which Sender
Match the route to the sender, not to the carrier as a whole.
Email fits a one-off sender with a handful of files. A portal fits a small agency that sends a few records a week.
A custom connector fits one high-value sender with its own engineers. A gateway fits a book where sender count keeps growing.
Questions to Ask Before You Pick a Route
Four questions turn the table into a decision.
How many senders do you add in a year? Which senders send large files? Who owns the mapping the day a Guidewire release lands?
Which of your current routes retire once a gateway is live? The answers show where your team’s hours go today.
How InsOps Helps
InsOps builds an insurance-trained AI that assists with moving sender data into Guidewire. Yazh (Yaal), our Integration Gateway, lets a sender map its payload once, and Yazh translates it to your Guidewire format.
LiLa, our insurance-trained LLM, suggests each field mapping. A person at the sender reviews and confirms every mapping before data moves.
Yazh exchanges inbound data with PolicyCenter, ClaimCenter, and BillingCenter, and it runs inside your own environment. Senders register in a self-service portal, test in a sandbox, and send. Payloads with gaps return to the sender, and large payloads arrive by file location.
Yazh sits beside Guidewire’s own Integration Gateway and adds the sender portal, mapping assistance, and test harness. When a payload or a Guidewire release changes, the mapping is updated in one place, and each tenant keeps its own mapping.
If you are evaluating how to take on more MGAs, brokers, and TPAs without a new build for each one, contact us to talk through what this looks like for your operation.
Frequently Asked Questions
Q: What is insurance data exchange?
A: Insurance data exchange is the movement of policy, claims, and billing data between a carrier and the MGAs, brokers, TPAs, and vendors that send it. The route defines the format, the mapping, and the checks along the way.
Q: What are the main ways carriers receive data from MGAs, brokers and TPAs?
A: Carriers receive data through email and spreadsheets, scheduled file drops, custom point-to-point connectors, carrier-built portals, and an integration gateway. Most carriers run more than one.
Q: Why does email and spreadsheet intake stop scaling?
A: Every attachment needs a person to read it and rekey it into Guidewire. Intake load rises with each sender added, and gaps surface only when someone notices them.
Q: Why do custom connectors strain integration teams?
A: Each connector is a separate build for one sender. Every Guidewire release means retesting all of them, so the retesting load grows with sender count.
Q: How is an integration gateway different from Guidewire’s Integration Gateway?
A: Guidewire’s Integration Gateway is a developer framework where your engineers write the integration logic. A prebuilt gateway route adds a sender portal, mapping assistance, and a test environment on top of what your engineers would otherwise build.
Q: What should a carrier measure to compare routes?
A: Track the share of payloads accepted on first receipt, the count of incomplete payloads returned to senders, and the time from sender submission to arrival in Guidewire. Also track the number of senders live per integration engineer.
Q: How does InsOps assist with this?
A: LiLa drafts the field mapping from a sender’s payload to your Guidewire structure, and a person at the sender confirms every mapping before data moves. The mapping stays under human review at each step.
Q: What does a realistic rollout look like?
A: Start with the senders whose volume or rework is highest. Name owners and provision infrastructure first, onboard one sender through the sandbox, and add senders as each mapping is confirmed.