A carrier signs a smaller broker and expects submissions to arrive in Guidewire PolicyCenter. The broker has an office team, an agency system, and no developer who knows Guidewire. Months later the broker still sends submissions by email and spreadsheet, and underwriting staff re-key them.
That stall is predictable. Direct integration asks the sender to build and maintain a connector to the carrier’s Guidewire instance, and a small brokerage is not set up for that work.
This article explains why smaller brokers struggle with direct integration and what the stall costs the carrier. It then compares the four intake routes carriers use and shows how to match a route to each broker.
Why can’t a smaller broker integrate directly with Guidewire?
A smaller broker cannot integrate directly with Guidewire because direct integration is software development work. A brokerage spends its day placing and servicing business. The gap shows up in three places: the team, the build, and the number of carriers.
The team behind the broker
The Big “I” 2026 Agency Universe Study, reported by Insurance Journal on September 24, 2026, found that the average independent agency has 9.9 staff members across all positions. That average includes the largest agencies in the survey, so a smaller broker sits below it.
Those people write business, service accounts, and answer carriers. Guidewire development is a separate skill set that a brokerage has to hire or contract for.
What a direct connection asks of the sender
To send policy submissions into PolicyCenter and first notice of loss into ClaimCenter, a sender builds a payload that matches the carrier’s structure. The sender then supplies every mandatory field with a valid value and tests the connection against the carrier’s environment.
When the carrier’s requirements change, the sender fixes the connector again. Each of those steps needs a developer.
The multiplier: one broker, many carriers
The same study names dealing with multiple carrier interfaces as the biggest technology challenge for agencies, as in previous years. A broker who writes with several carriers faces a separate connection for each one.
Direct integration with one carrier solves a fraction of the broker’s problem. The broker has little reason to fund it.
What does a stalled direct integration cost the carrier?
The broker is not the only party carrying the load. Every direct integration also lands on the carrier’s Guidewire team, and every stalled one leaves the carrier with a manual intake queue.
One connector per sender
A connector built for one sender depends on Guidewire’s payload structures. When a release changes those structures, the carrier goes back into the connector.
Guidewire’s own Integration Gateway is a developer framework for building integration apps. Per Guidewire’s September 2025 release blog, it supports apps on the current release and the two before it. Integration apps built this way follow the release calendar.
The partner count stays small
Each connector takes a share of the same Guidewire team’s time. The number of distribution partners a carrier opens is then set by that team’s capacity rather than by broker demand.
A smaller broker’s volume rarely justifies a place in that queue. The broker waits, or keeps sending files.
Incomplete data reaches underwriting
Brokers who cannot connect fall back to email and spreadsheets. Those files arrive with missing fields, and an underwriter finds the gap after opening the file. The carrier’s submission intake absorbs the rework.
Some checks belong at the door. Verifying producer codes before data reaches an underwriter is one example.
What do carriers do when a smaller broker cannot build a connector?
Carriers use four intake routes. Each one assigns the build and the upkeep to a different party.
Route | Who builds | Who maintains | Fits best |
|---|---|---|---|
Direct API calls | The sender | The sender | Senders with Guidewire-skilled developers |
Files and email | No one | The carrier’s operations staff | Low volume and short-term arrangements |
Vendor connection | The sender’s software vendor | The vendor | Brokers on a system the vendor has already connected to the carrier |
Carrier-side gateway with self-service portal | The carrier sets up the gateway once; each sender maps its payload once | The carrier maintains the one gateway | Many senders with mixed technical capacity |
Route 1: direct API calls
The sender writes to the carrier’s APIs. This works for software vendors and larger MGAs that employ engineers.
The build and the upkeep both sit with the sender. For a smaller broker, this is the route that stalls.
Route 2: files and email
The carrier accepts flat files or emailed spreadsheets. Nothing needs building on either side.
Operations staff reformat and re-key the data, and completeness depends on how carefully each sender prepares the file. The route is quick to start and expensive to keep.
Route 3: the sender’s software vendor
The broker’s agency-system vendor builds the connection once and sends data for every broker on its software. The broker builds nothing.
The carrier then depends on the vendor’s roadmap, and a broker whose vendor has not connected to that carrier has no route.
Route 4: a carrier-side gateway with a self-service portal
The carrier runs one gateway. Each sender maps its payload once, tests it, and sends. The gateway translates the payload to the carrier’s Guidewire format.
This is how carriers onboard agencies and vendors through self-service without a build for each one. The sender needs no Guidewire knowledge, only knowledge of its own data.
How should a carrier match an intake route to each smaller broker?
Route follows capacity. Three checks settle the choice before any connection work starts.
Start with the sender’s capacity
Ask three questions in this order:
Does the sender employ or contract a developer who knows Guidewire?
How many carriers does the sender send to?
Does the sender’s software vendor already offer a connection to this carrier?
A “no” to the first and third questions rules out Routes 1 and 3.
Define complete before connecting
A payload specification lists the mandatory fields and valid values for each line of business. Every sender then knows what a complete submission looks like before the first send.
Underwriting operations owns this definition. The IT team enforces it.
Test before real submissions
A sandbox lets a sender send sample data and see rejections before any real submission reaches underwriting. The sender fixes gaps without touching the live queue.
Testing in a sandbox shifts the first round of errors away from underwriters and onto the sender, where the fix happens.
What happens to the carrier’s architecture as the partner count grows?
The first broker is a project. The twentieth is an architecture question.
Point-to-point connections multiply
Each new sender adds another connection to build, test, and maintain. Point-to-point integrations tie the carrier’s team to every sender’s payload, and a change on either side reopens that one connection.
A standard layer in front of Guidewire
Standardized API gateways give senders one entry point and one set of rules. The Guidewire team maintains one translation layer instead of one connector per sender.
Fit with composable architecture
An intake layer suits composable, API-first systems because it keeps sender-facing rules separate from the core system. The core stays focused on policy, claims, and billing.
How InsOps Helps
InsOps builds Yazh (Yaal), the InsOps Integration Gateway, a data exchange platform that lets a carrier take in policy, claims, and billing data from many senders without a custom connector for each one. A sender maps its payload once, and Yazh translates it to the carrier’s Guidewire format. LiLa, our insurance-trained LLM, assists with the mapping, and a person reviews every mapping before it is used.
Smaller brokers get a self-service portal, a test harness, and a sandbox for sending sample data before real submissions. Yazh rejects incomplete data at the door, and large payloads arrive by file location.
Yazh delivers inbound data into Guidewire PolicyCenter, ClaimCenter, and BillingCenter, with mapping specific to each carrier’s tenant. It handles changes to a payload or a Guidewire release. Guidewire’s own Integration Gateway is a developer framework for building integration apps. Yazh adds the sender-facing side, so a carrier’s Guidewire team does not build a connector for each broker.
If you are evaluating how to open your Guidewire instance to smaller brokers without building a connector for each one, contact us to talk through what this could look like for your operation.
Frequently Asked Questions
What is direct integration with Guidewire?
Direct integration means a sender writes its own connection to a carrier’s Guidewire APIs. The sender builds the payload, meets the carrier’s field requirements, tests the connection, and maintains it.
Do smaller brokers have the IT capacity to integrate directly with Guidewire?
Most do not. A brokerage team writes and services business, and Guidewire development is specialist work that sits outside that team’s day-to-day role. Carriers that expect direct integration from smaller brokers see stalled onboarding.
Why does each new sender need its own connector?
Each sender’s data is structured differently, and each carrier’s Guidewire instance has its own fields and valid values. A connector bridges one sender’s structure to one carrier’s structure, so a second sender needs a second bridge.
How should a carrier onboard a smaller broker?
Start with the broker’s capacity, then choose the route. Publish a payload specification, give the broker a sandbox to test in, and reject incomplete data at intake so underwriters see only complete submissions.
What are the common challenges when onboarding smaller brokers?
The common ones are no developer on the broker’s side, a different interface for each carrier, and incomplete submissions that reach underwriting. On the carrier’s side, each custom connector draws on a finite Guidewire team.
Which metrics show whether broker onboarding is working?
Track the number of live distribution partners and the share of submissions accepted on first send. Also track how many submissions are rejected for missing fields, and how long a new broker takes from first call to first live submission.
How does InsOps assist with broker onboarding?
Yazh gives each sender one place to map, test, and send data. LiLa assists with the mapping, and a person reviews every mapping before it is used, so the carrier keeps control of what enters Guidewire.