Two products share the name integration gateway, and carrier architecture reviews stall when nobody says which one is meant. One is Guidewire’s developer framework for building integrations. The other is a front door that outside senders use to deliver data to your Guidewire systems.
Scope one as the other and the plan breaks. Your engineers end up writing sender mappings the framework never promised to provide, or the team buys a front door and expects it to replace the framework.
This article defines each gateway, compares them on the questions an architect asks, and shows how they sit side by side in one carrier environment.
What Is Guidewire’s Integration Gateway?
Guidewire’s Integration Gateway is a cloud-native integration service that connects InsuranceSuite to internal and third-party systems. Your developers build integration apps on it using Apache Camel routes.
Who Uses It and for What
The framework serves developers, and its output is code.
A Guidewire developer writes an integration app that mediates between InsuranceSuite and an outside system. The app holds the integration logic, so the core product does not.
The pattern starts with PolicyCenter and carries over to the other Guidewire applications.
The same framework serves ClaimCenter integrations, and each one is its own app that your team writes.
What It Leaves to Your Team
A framework supplies tools, and your team supplies the integration itself.
Your developers write and test each route, and they decide the format every sender must follow. The first draft of every sender mapping stays with your engineers.
Your team also keeps each app current. Guidewire supports these apps on the current release and the two before it, as its September 2025 release post states.
The apps and InsuranceSuite upgrade on separate schedules, so the apps carry their own release calendar.
What Is a Carrier-Side Data Exchange Gateway?
A carrier-side data exchange gateway is a front door for outside senders. MGAs, brokers, TPAs, and software vendors register, map their payloads, test, and send, and the gateway delivers the data to your Guidewire systems.
The Front Door for Outside Senders
This gateway faces the senders, where Guidewire’s framework faces your developers.
A carrier invites a sender by email. The sender registers in a self-service portal, uploads a sample payload, and maps it to Guidewire fields, with a person confirming each mapping.
Senders keep their own data format, so the carrier adds distribution partners without a new build for each one.
That is the job behind submission intake, along with claim and billing updates.
What Happens to a Payload on Arrival
Each payload passes the same steps, whichever sender it comes from.
The gateway validates the payload and returns incomplete data to the sender instead of your queue. It translates source values into the codes Guidewire expects, and large payloads arrive as a file location.
Senders test in a sandbox before real data moves. A dashboard records each request, response, and error.
How Do the Two Gateways Differ?
They differ in audience, output, and who writes the first mapping. Guidewire’s gateway is built for your developers, and a carrier-side gateway is built for your senders.
Side-by-Side Comparison
The table puts both gateways against the same six questions.
Question | Guidewire Integration Gateway | Carrier-side data exchange gateway |
|---|---|---|
Who uses it | Your Guidewire developers | Outside senders, invited by the carrier |
What it produces | Integration apps, which are code | A mapped, tested route for each sender |
Who writes the first mapping | Your engineers | The sender, drafted with assistance and confirmed by a person |
Where gaps are caught | In logic your developers write | At receipt, with incomplete payloads returned to the sender |
How a sender is onboarded | Through a developer build | Through a self-service portal and sandbox |
What a Guidewire release changes | Apps must stay within supported releases | The mapping is updated in one place |
Why the Name Collision Causes Scoping Errors
A shared name hides two different jobs.
An architect hears integration gateway on a vendor call and again in a Guidewire roadmap session in the same week. One means a framework to build on, and the other means a service that onboards senders.
One question separates them: who writes the first draft of the mapping? If the answer is your engineers, the framework is in play.
Teams also ask how an integration gateway differs from an API or an ETL job, which is a third distinction worth settling early.
How Do the Two Gateways Work Together?
They split the work at the carrier’s boundary. The carrier-side gateway handles data arriving from outside senders, and Guidewire’s framework handles the integrations your own developers own.
A Division of Labor
Neither gateway replaces the other, because they serve different owners.
Use Guidewire’s framework for integrations your developers control, such as a feed between InsuranceSuite and an internal system. Use a carrier-side gateway for the many outside senders whose formats you do not control.
Sender count, not technology, drives that split, which is the case for standardized API gateways over point-to-point connections.
The shift toward composable, API-first systems adds integration points at your boundary, so the split matters more each year.
Change on Both Sides
Both sides face change. Guidewire ships releases, and senders change their payloads.
Keeping integrations running when Guidewire or your own payload changes takes a named owner on each side.
On the framework side, your developers update the apps. On the sender side, a mapping update in one place covers the change.
Where Each Gateway Runs
Deployment decides what your infrastructure team provisions.
A carrier-side gateway runs inside your own environment, so your team decides where payloads, mappings, and logs live.
Which Guidewire APIs an outside integration reaches depends on the deployment, and on-premises and cloud APIs behave differently for an outside sender.
How Do You Decide What Your Carrier Needs?
Decide by counting senders and naming owners. The count shows which gateway carries the load, and the owner list shows who runs each one.
Questions for the Architect
Four questions settle most scoping debates.
How many outside senders do you onboard in a year? Which integrations do your own developers own? Who writes the first mapping for each sender?
Does your intake route work across the Guidewire suite, or does each product need its own?
A Sequence That Works
Run the work in this order, and each step feeds the next.
List every outside sender and the format it sends.
Mark the integrations your developers own and keep those on Guidewire’s framework.
Assign one owner to each gateway, with a named contact for releases.
Pilot one sender through a sandbox before adding the rest.
How InsOps Helps
InsOps builds an insurance-trained AI that assists with moving sender data into Guidewire. Yazh (Yaal), our Integration Gateway, is a carrier-side data exchange gateway: a sender maps 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. Incomplete payloads return to the sender, and each tenant keeps its own mapping.
Yazh sits beside Guidewire’s own Integration Gateway and adds the sender portal, mapping assistance, and test harness that the developer framework leaves to your engineers. When a payload or a Guidewire release changes, the mapping is updated in one place.
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
What is Guidewire’s Integration Gateway?
It is Guidewire’s cloud-native integration service for connecting InsuranceSuite to internal and third-party systems. Developers build integration apps on it using Apache Camel routes.
What is a carrier-side data exchange gateway?
It is a front door that outside senders use to deliver data to a carrier’s Guidewire systems. Senders register, map their payloads, test, and send, and the gateway validates and delivers the data.
Why do the two gateways get confused?
They share the name integration gateway. One is a developer framework and the other is a service for onboarding senders, so the name alone does not tell you who uses it.
Does a carrier need both?
A carrier needs whichever matches the work. Integrations your developers own fit Guidewire’s framework, and the many outside senders you do not control fit a carrier-side gateway. Many carriers have both kinds of work.
Who writes the mapping in each case?
With Guidewire’s framework, your engineers write the integration logic and the first mapping draft. With a carrier-side gateway, the sender maps its own payload, with assistance and a person’s confirmation.
What should a carrier measure to know the setup works?
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 how many senders each integration owner supports.
How does InsOps assist with this?
LiLa drafts each field mapping from a sender’s payload to your Guidewire structure, and a person at the sender confirms every mapping before data moves. Yazh handles delivery after that review.
What does a realistic rollout look like?
List your senders, assign an owner to each gateway, and pilot one sender through the sandbox. Add senders as each mapping is confirmed, and common pitfalls are skipping the owner list and onboarding every sender at once.