A new MGA asks to send submissions into your Guidewire PolicyCenter. Your integration team points out that Guidewire already exposes APIs, so access looks solved. Then the first payload arrives in the sender’s own format, and nobody owns the work between that format and your fields.
That gap is the difference between API integration and data exchange. An API gives a sender a way in. It does not map the sender’s fields, reject incomplete data, or retest after a Guidewire release.
This article shows what a carrier owns under each model, where the work moves when an exchange layer is added, and what to scope before the first sender goes live.
What Is the Difference Between Insurance Data Exchange and API Integration?
API integration connects two systems through a published interface. Data exchange adds the work around that interface: mapping each sender’s payload, validating it, testing it, and keeping it working as either side changes.
The two are not rivals. Data exchange sits on top of the API. The open question is who does the surrounding work, the carrier or each sender, and how an integration gateway differs from an API or an ETL job frames that choice.
What an API Gives a Sender
Guidewire Cloud exposes RESTful system APIs that create, read, update, and delete InsuranceSuite resources. PolicyCenter also generates extra endpoints for each carrier’s lines of business, according to BD Emerson’s September 2026 Guidewire guide.
Contracts therefore differ from carrier to carrier. A sender that mapped to one carrier’s fields reviews that mapping again for the next, and the on-premises and cloud APIs add their own differences for an outside integration.
What Data Exchange Adds
A data exchange layer takes on five jobs that an API leaves open: a field contract, a mapping step, a completeness check, a test route, and change handling. Each job exists under direct API access too. The difference is who performs it and how often.
Without the layer, the carrier answers each sender’s questions one at a time, and each sender repeats its own mapping and testing. For a carrier on Guidewire PolicyCenter, the field contract covers mandatory fields and valid values for each line of business.
Two Products Share One Name
Guidewire sells a developer framework also called Integration Gateway. Your engineers write the integration logic that runs on it.
A layer that receives data from outside senders is a separate piece. Keep the two names apart in scoping documents.
What Does a Carrier Own When Senders Call APIs Directly?
Direct API access moves the integration work to the edges, and the carrier keeps the center. Three duties land on the carrier even when senders write all the code.
The Field Contract
Every sender needs the carrier’s mandatory fields and valid values. The carrier answers each sender’s questions about them, one sender at a time.
Claims show the pattern clearly. A TPA sending first notice of loss needs a contract for claims intake, and your claims system’s own rules decide whether each submission becomes a claim.
Mapping Repeated Per Sender
Each sender builds and maintains its own mapping to your fields. Ten senders mean ten separate mappings, and the carrier reviews the result of each one. The estate grows into a set of point-to-point connections that nobody documents in one place.
Policy, claims, and billing data already live in separate systems at many carriers. Every sender-specific connection adds another place where data silos form.
Release Changes Reach Every Sender
Guidewire Cloud has shipped three named releases a year since 2023, and the latest, Qusar, arrived in August 2026, according to BD Emerson’s guide. Each release is a retest for every sender calling the API.
The carrier tells each sender what changed in ClaimCenter and PolicyCenter, then waits for each sender’s retest before trusting the next payload.
What Changes for a Carrier When an Exchange Layer Sits in Front of Guidewire?
An exchange layer moves repeated work from each sender’s build to one shared place. The carrier gains a new asset to run and a new set of decisions to make.
The Five Ownership Points, Side by Side
The table compares who does each job under direct API access and under an exchange layer.
Ownership point | Direct API integration | Data exchange layer |
|---|---|---|
Field contract | The carrier publishes mandatory fields and valid values, then answers each sender’s questions | The carrier defines the contract once, and senders see it in one portal |
Mapping | Each sender builds and maintains its own mapping | The sender maps once; an insurance-trained model drafts the mapping and a person reviews it |
Completeness | Incomplete data reaches Guidewire, where its rules stall it | Incomplete data is rejected at the door and returned to the sender |
Testing | The carrier arranges test access for each sender | Senders test in a sandbox with a test harness before real data moves |
Change | Each sender retests after a Guidewire release or a payload change | The layer handles changes to a payload or a Guidewire release |
Name an owner for every row before the first sender onboards.
What Moves to the Sender
In an exchange model, the sender maps its payload once, and the layer translates it to the carrier’s Guidewire format. An insurance-trained model drafts the mapping, and a person reviews every mapping before it is used.
The sender also gets a sandbox and a test harness. The first real payload is then not the first test.
What Stays With the Carrier
The carrier still defines the field contract, because only the carrier knows its mandatory fields and valid values. The layer enforces the contract. It does not write it.
The carrier also runs the layer. A gateway inside the carrier’s own environment needs servers, firewall rules, logs, and named owners, which the infrastructure a carrier provisions checklist lists layer by layer.
The reasons carriers run an integration gateway inside their own environment vary, but the decision needs an owner before launch.
Which Model Fits Which Sender?
Neither model wins everywhere. Sender count and sender type decide.
When Direct API Access Is Enough
A single large software vendor with its own Guidewire developers can call the API directly. The carrier supports one contract, one mapping, and one retest path.
When Sender Count Decides
MGAs, brokers, TPAs, and software vendors each arrive with a different format. At some point the carrier runs the same contract conversation, the same mapping review, and the same retest cycle for each one. That repetition is the signal to add a layer.
When Claims and Policy Senders Differ
Policy senders need a submission contract that reaches an underwriter. Claims senders need first notice of loss that satisfies the claims system’s rules, sometimes as a large file.
A single layer serves policy, claims, and billing senders across Guidewire, each with its own contract.
How Do You Scope the First Sender?
Scoping the first sender settles most of the architecture. The three steps below take you from a sender list to a tested payload.
Inventory Senders and Targets
List every sender, the Guidewire application it targets, and the line of business it sends. Group senders that target the same application, because they share a contract.
Name the Owners
Assign one owner to each of the five ownership points: contract, mapping, completeness, testing, and change. The carrier owns the contract and the release calendar. The sender owns its payload.
Run the First Payload in a Sandbox
Have the first sender run a sample payload in a sandbox before any real record moves. Compare the response with the fields you expect, and fix gaps in the contract before the second sender starts.
How InsOps Helps
InsOps builds an insurance-trained AI that assists with moving sender data into Guidewire. Yazh (Yaal), the InsOps Integration Gateway, is a data exchange platform: a sender maps its payload once, and Yazh translates it to your Guidewire format. LiLa, our insurance-trained LLM, drafts each mapping, and a person reviews every mapping before it is used.
Yazh gives senders a self-service portal, a test harness, and a sandbox to test in before real data moves. It rejects incomplete data, handles changes to a payload or a Guidewire release, sends large payloads by file location, and keeps mappings specific to your tenant.
Yazh exchanges data inbound into Guidewire PolicyCenter, ClaimCenter and BillingCenter, and it runs inside your own environment. It is not Guidewire’s Integration Gateway, which is a developer framework for your own integration logic. Yazh adds the sender-facing layer beside it.
If you are evaluating how to take data from many senders into Guidewire without a connector for each one, contact us to talk through what this looks like for your operation.
Frequently Asked Questions
What is the difference between an API and a data exchange layer?
An API is a published interface that lets a sender reach Guidewire. A data exchange layer sits in front of that interface and handles the field contract, mapping, completeness checks, testing, and change handling for each sender.
Why does the difference matter for a carrier on Guidewire?
PolicyCenter generates endpoints for each carrier’s lines of business, so contracts differ from carrier to carrier. Without a shared layer, each sender repeats the same mapping and testing work against your fields, and your team answers every one of them.
How do you introduce an exchange layer without rebuilding existing integrations?
Leave existing direct integrations as they are and route the next sender through the layer. Start with one sender and one line of business, then add senders that target the same Guidewire application.
What are the common challenges?
The common challenge is unclear ownership. When nobody is named to define mandatory fields and valid values, review mappings, or own the release calendar, each sender’s question waits for an answer.
What should a carrier track to know it is working?
Track the share of payloads rejected for gaps by sender, the count of senders live per Guidewire application, and the time from sender sign-up to first accepted payload.
How does InsOps assist with data exchange?
LiLa, the InsOps insurance-trained LLM, drafts each sender’s mapping, and a person reviews it before use. The sender tests in a sandbox, and incomplete payloads return to the sender instead of reaching Guidewire.
What does a realistic timeline look like?
The timeline follows the number of senders, the lines of business each one sends, and how complete your field contract is. Plan the first pass around one sender and one line of business, and schedule a retest after each Guidewire release.