A carrier on Guidewire takes data from partners that have little in common. A software vendor with its own engineers, a small agency with a spreadsheet, a TPA with a nightly claims file, and an MGA with its own policy system all want to send business in.
Give all of them the same route and it fails for most. A custom connector is wasted on the agency, a portal cannot carry the TPA’s volume, and a flat file leaves the MGA’s coverage data unchecked until an underwriter opens it.
This article sets out the four intake routes, what each is good at, and which partner types fit which route. It ends with a four-question test your team can run for each partner.
What are the four intake routes, and what is each good at?
Every partner reaches the carrier by one of four routes. Each route decides who builds the integration, who maps the data, and who fixes it when something breaks.
Custom connector
A custom connector is a direct build between one sender and the carrier’s Guidewire instance. It fits a small number of strategic partners with engineering teams and steady volume, because the data shape is tuned to that one relationship.
The burden is upkeep. Each connector needs its own build and its own fix after a Guidewire release. That is why point-to-point connectors break as carriers add vendors.
Portal
A self-service portal gives a partner a web screen to key in or upload one submission or claim at a time. It fits small agencies and low-volume senders that have no systems of their own to connect.
A portal moves the work to the person at the keyboard. Every record is entered by hand, so volume and re-keying set its limit.
A portal works best as one channel among several. The pattern is covered in how carriers onboard agencies and vendors through self-service.
Flat file
A flat file is a spreadsheet, a CSV or an SFTP drop with rows of data. It fits scheduled batches of simple records and partners whose systems export files and nothing else.
A file carries values, not meaning. Guidewire structures are layered, with a policy holding lines, risks and coverages, and those layers do not fit a flat row cleanly. This is why broker and MGA submissions arrive incomplete when files are the only route.
Gateway
A carrier-side data exchange gateway receives structured payloads from a partner’s own system. The sender maps its payload once, the gateway translates it to the carrier’s Guidewire format, and a person reviews the mapping before it is used.
It fits many senders that have software of their own and send repeatedly. It rejects incomplete data at the door and gives senders a sandbox to test before real data moves.
Across vendor ecosystems, standardized API gateways are replacing point-to-point links for the same reason. One shared route replaces a build per partner.
Which route fits which partner type?
Match the route to what the partner already has: engineers, a system, a file, or nothing. The same logic applies across PolicyCenter, ClaimCenter and BillingCenter, so the work is cross-platform Guidewire integration from the first partner.
The partner-type table
The table gives a starting point. Each row names a partner type, what it brings, and the route that fits.
Partner type | What the partner has | Best-fit route | Why |
|---|---|---|---|
Software vendor (workbench, rating) | Engineering team, structured payloads | Gateway | Maps once, sends repeatedly, no build per carrier |
MGA or MGU with its own policy system | Policy data in its own structures | Gateway | Coverage layers are mapped and reviewed once |
Retail broker or small agency | Spreadsheets and email, no IT team | Portal | No system to connect; a person keys or uploads |
TPA sending claims | High claim volume, files or payloads | Gateway | Large payloads go by file location |
Newly acquired agency | Several source systems at once | Gateway | Many sources reach one Guidewire target |
Partner with a simple export only | A CSV and nothing else | Flat file | Accept the limits for a simple batch |
One strategic partner with a large engineering team | Own developers, steady volume | Custom connector | Tuned to one relationship |
MGAs, vendors and brokers on the policy side
Policy-side partners send the data underwriters work from. For submission intake, the question is whether the data arrives complete and in the structure Guidewire expects.
MGAs and vendors with their own systems send structured payloads, so a gateway fits. Brokers and small agencies often have no system to connect, so a portal fits.
Whichever route is used, the carrier still needs a clearance step. Checking producer codes before data reaches an underwriter belongs in every route.
Claims-side partners
TPAs send first notice of loss records and claim updates into Guidewire ClaimCenter. Their volume rules out a portal, and a flat file leaves claim structures unchecked.
For claims intake, a gateway handles both the payload and the large batch, with large payloads sent by file location instead of an API body.
Acquired agencies
Agency acquisitions bring several source systems to the carrier at once. Each system sends in its own format.
A gateway gives all of them one place to map, test and send. A connector per source system repeats the build several times over.
How do you choose when partners overlap?
Partners do not fit neatly into one row. An MGA can send policy payloads through a gateway and still key a correction into a portal.
The Route-Fit Test
Four questions place a partner in a route. Ask them for one partner at a time.
What does the partner have? Engineers and a system point to a gateway or a connector. No system points to a portal.
How much, and how often? Occasional single records suit a portal. Repeated or large sends suit a gateway or a file.
Who owns the mapping? In a connector, your developers own it. In a gateway, the sender maps and your team reviews.
What happens to incomplete data? Decide whether it stops at the door or an underwriter finds it later.
Score each partner on its own answers. Two partners of the same type can land on different routes.
Running more than one route
A carrier does not need one route. It needs a rule for each partner type, written down, so that a new partner is placed in minutes of discussion, not a new project.
Keep the routes in separate lanes. The portal serves small senders, the gateway serves senders with systems, and the connector stays reserved for the exception.
What goes wrong when the route and the partner do not match?
A mismatch rarely fails on day one. It shows up later as rework, rejected records and a growing list of things your team maintains.
A connector built for a partner that sends a few records
The build happens once, but the upkeep never ends. Every Guidewire release adds a check on that connector, and a low-volume partner never returns the effort.
A flat file used where coverage structure matters
A row cannot say which risk a coverage belongs to. The data arrives, the structure is guessed, and the gap surfaces when an underwriter opens the submission.
A portal used where volume is high
Every record is keyed by hand, so errors and queues grow with volume. A partner that outgrows the portal needs a route with a system behind it.
How InsOps Helps
Yazh (Yaal), the InsOps Integration Gateway, is a data exchange platform for carriers on Guidewire. A sender maps its payload once, and Yazh translates it to each carrier’s Guidewire format. LiLa, our insurance-trained model, assists the mapping, and a person reviews every mapping before it is used.
Yazh brings inbound data into Guidewire PolicyCenter, ClaimCenter and BillingCenter. It rejects incomplete data, handles changes to a payload or a Guidewire release, supports tenant-specific mapping, and accepts large payloads by file location.
Senders get a self-service portal and a test harness with a sandbox, so the portal route and the gateway route live in one place. Guidewire’s own Integration Gateway is a developer framework. Yazh adds a route beside it for outside senders, without a separate build for each partner.
If you are deciding which intake route fits each partner type without adding another connector to maintain, contact us to talk through what this could look like for your operation.
Frequently Asked Questions
What is an intake route?
An intake route is the path a partner’s data takes into the carrier’s Guidewire instance. The four common routes are a custom connector, a portal, a flat file and a gateway.
Which intake route is best for small agencies?
A self-service portal. A small agency has no system to connect, so a person keys in or uploads each submission, and the carrier avoids a build for a low-volume sender.
When is a custom connector the right choice?
A connector fits one strategic partner with its own engineers and steady volume. The carrier accepts a dedicated build and a fix after each Guidewire release in return for a route tuned to that partner.
Why do flat file submissions arrive incomplete?
A flat row carries values without the structure behind them. Fields go missing, formats drift between sends, and the layers of a Guidewire policy do not fit a single row.
How does a gateway differ from a portal?
A portal takes one record entered or uploaded by a person. A gateway takes structured payloads from the partner’s own system, translates each to the carrier’s Guidewire format, and rejects incomplete data.
What should a carrier measure for each route?
Count the partners on each route and the share of sends rejected for missing fields. Track the fixes needed after each Guidewire release and the number of mappings awaiting review.
How does AI assist intake?
LiLa, the InsOps insurance-trained model, assists the mapping step by suggesting how a sender’s fields line up with the carrier’s Guidewire structures. A person reviews every mapping before it is used.
How should a carrier choose a route for a new partner?
Run the Route-Fit Test: what the partner has, how much and how often it sends, who owns the mapping, and what happens to incomplete data. Record the answer so the next partner of that type follows the same rule.