A sender’s developer opens your PolicyCenter API reference, receives a client ID, and starts posting submissions. It looks like the fastest route to a new distribution partner, and for the first sender it often is. The carrier has also just taken on a list of duties that nobody wrote down.
Those duties do not sit with the sender. Endpoint access, the payload contract, release testing, and the support queue for rejected data all stay with the carrier’s integration team, and they grow with every sender added.
This article lists what a carrier owns when senders call PolicyCenter APIs directly, layer by layer. It then shows where direct calls fit, where a carrier-side gateway fits, and which questions to answer before approving the next sender.
What does a carrier own when a sender calls PolicyCenter directly?
The answer is five layers. The sender writes the calling code, but the carrier owns everything the call touches on the PolicyCenter side.
The call is the sender’s work, the endpoint is the carrier’s
A direct call splits the work unevenly. The sender builds a client, and the carrier supplies the target.
Guidewire describes its Cloud API as a set of RESTful system APIs that client applications use to request data from, or start actions in, InsuranceSuite. Each of those calls lands on endpoints inside the carrier’s own instance, configured by the carrier’s own team.
Five layers of ownership
The table below names each layer and where its work shows up. Call it the five-layer ownership ledger.
Layer | What the carrier owns | Where the work shows up |
|---|---|---|
1. Endpoint surface | The PolicyCenter endpoints senders call, including those generated for the carrier’s own lines of business | Cloud API configuration, regenerated as products change |
2. Caller access | Registration of each sender’s application, API roles, and service account mapping | Guidewire Hub, API role files, Guidewire Home variables |
3. Payload contract | Which fields are required, which values are valid, and the specification senders work from | Written specification, sender questions |
4. Change handling | Retesting each sender after a Guidewire release or product change | Release calendar, regression cycles |
5. Sender support | Triage of rejected or partial submissions, one sender at a time | Integration team queue |
Each layer is a duty the carrier already carries for its own integrations. Direct calls repeat that duty for every external sender.
Who owns the endpoints and the access behind them?
Guidewire’s documentation puts access decisions on the carrier’s side of the call. A sender’s application needs an entry in the carrier’s configuration before its first request succeeds.
The endpoint set belongs to the carrier’s configuration
The Cloud API guide separates policy contents into two groups. Contents such as policy contacts and locations have endpoints in the base configuration, while contents such as coverables, coverages, and modifiers do not.
Those line-specific endpoints must be generated for each line, because insurers structure each product to suit the business. Code a sender writes against one carrier’s generated endpoints therefore targets that carrier’s configuration.
Every caller starts with no access
Guidewire’s guide states that API roles act as allowlists, and that a caller has no endpoint access by default. Each role lists the endpoints, operations, and fields a caller reaches.
The carrier’s team registers the sender’s application with Guidewire Hub, where the service presents a client ID and secret. It then associates the roles that match what that sender should reach.
Service accounts and variables are carrier-side configuration
For service callers, a client ID maps to a PolicyCenter service account, and that account needs the permissions appropriate for the service. Insurers manage these mappings through the Variables app in Guidewire Home.
Deploying a change to those variables requires a server restart. Onboarding sender number twelve is therefore a configuration task in the carrier’s own instance, scheduled by the carrier.
Who owns the payload contract?
The carrier decides what a complete submission looks like. Senders learn that definition by sending data and reading the rejections.
Line-specific structure is the carrier’s to document
Coverables, coverages, and modifiers vary by line of business, so the payload a PolicyCenter endpoint expects varies by carrier and by product. A generic specification does not describe it.
Someone on the carrier’s team writes down the mandatory fields and valid values for each line and answers sender questions about them. That document is part of the carrier’s ownership, whether or not anyone planned it.
Each sender maps to each carrier separately
A sender that works with several carriers maps its payload once per carrier, because endpoints and required fields differ. The carrier meanwhile receives as many formats as it has senders.
We cover the sender’s side of this in how MGAs, TPAs and brokers send submission data into Guidewire PolicyCenter without building a connector.
Rejections become the carrier’s support queue
When a payload fails, the sender asks the carrier’s integration team what the endpoint expected. Answering requires someone who reads both the configuration and the call logs.
Guidewire logs the caller’s subject, client ID, and mapped service account for each service call. The carrier can trace who sent what, and the tracing is still the carrier’s work.
What happens when something changes?
A direct call ties the sender’s code to the carrier’s release schedule. Both sides change, and neither controls the other’s calendar.
Guidewire releases and new products change the endpoints
When a carrier adds a product or line of business, endpoints for that line must be generated, and the Cloud API guide also documents regenerating them. Every Guidewire release adds a retest cycle across all senders.
That recurring effort is the core of the question in build vs buy: what maintaining a Guidewire connector involves, with one connector per sender.
Sender payload changes arrive on the sender’s schedule
A sender adds a field, renames a value, or changes a file layout. Without an agreed test route, the carrier learns about it when production submissions fail.
Each failure then moves through the same support queue described above. The more senders a carrier has, the more often that queue opens.
The same pattern repeats across applications
PolicyCenter is one target. Senders of claims and billing data meet the same five layers against ClaimCenter and BillingCenter.
Carriers that also run other platforms alongside Guidewire see the pattern again in cross-platform Guidewire environments, where each additional system adds its own sender list.
Direct calls or a carrier-side gateway: how to decide
Direct calls are the right answer in some cases. The decision depends on how many senders there are, how often their payloads change, and how much Guidewire expertise sits on the carrier’s team.
When direct calls fit
Direct calls fit a small, fixed set of senders that have their own Guidewire developers and stable payloads. A software vendor that already integrates with Guidewire is a common example.
A carrier with the integration capacity to maintain all five layers can choose this route with full knowledge of the cost. The ledger above is the checklist for that choice.
When a carrier-side gateway fits
A carrier-side data exchange gateway moves the sender-facing layers into one place. Senders map, test, and send there, and the carrier reviews each mapping once. Guidewire’s own Integration Gateway is a developer framework for building integration applications, so the carrier’s team builds on it.
A gateway fits when senders are many, when they lack Guidewire developers, or when payloads change often. Underwriting workbench vendors are a clear case, since they need to reach each carrier’s instance without a Guidewire build team.
Where a carrier runs a gateway in its own environment, it takes on the infrastructure a carrier needs to run a gateway in-house.
The reasons carriers run an integration gateway inside their own environment are covered separately.
Questions to answer before approving the next sender
Answer these five questions for each new sender, in this order:
Which endpoints, operations, and fields does this sender need, and which API roles list them?
Who registers the sender’s application and maintains its service account mapping?
Where is the payload contract written, and who answers sender questions about it?
Which test environment does the sender use before real data moves?
Who retests this sender after each Guidewire release or product change?
If any answer is “nobody yet,” that layer is unowned, and it falls to the integration team by default.
How InsOps Helps
InsOps assists carriers with inbound sender data through Yazh (Yaal), the InsOps Integration Gateway. A sender maps its payload once, and Yazh translates it to each carrier’s Guidewire format. LiLa, our insurance-trained model, assists with the mapping, and a person reviews every mapping before it is used.
This is insurance data exchange built for the sender-facing layers of the ledger. Senders use a self-service portal and a test harness with a sandbox, so they test before real data moves. Yazh rejects incomplete data, handles changes to a payload or a Guidewire release, and accepts large payloads by file location. Mappings are tenant-specific.
Yazh connects to Guidewire PolicyCenter, ClaimCenter, and BillingCenter, so submissions, claims, and billing data flow into the carrier’s instance without a custom connector per sender. It sits beside Guidewire’s own Integration Gateway and adds the place where senders map, test, and send.
If you are deciding how many senders to take on through direct PolicyCenter calls, and who owns each layer, contact us to talk through what this looks like for your operation.
Frequently Asked Questions
What does it mean for senders to call PolicyCenter APIs directly?
Each sender builds its own client against the carrier’s PolicyCenter Cloud API endpoints and sends data without an intermediary. The carrier supplies the endpoints, the access settings, and the payload contract.
Why does ownership matter if the sender writes the code?
The sender’s code is one half of the connection. The endpoints, access configuration, field requirements, and release testing all live in the carrier’s instance and are maintained by the carrier’s team.
How does a carrier give a sender access to PolicyCenter APIs?
The carrier registers the sender’s application with Guidewire Hub and associates API roles that list the endpoints, operations, and fields the sender reaches. For service callers, the client ID is also mapped to a PolicyCenter service account.
What are the common challenges with direct sender calls?
Each sender needs its own mapping to the carrier’s endpoints, rejected payloads route to the integration team, and every Guidewire release or product change needs a retest per sender. These challenges grow with the number of senders.
Which metrics show whether direct calls still work?
Track the number of senders per integration engineer, the rejection rate by sender and field, the elapsed time from registration to a first accepted payload, and the retest cycles each release requires. A rising trend in any of the four points to an overloaded layer.
How does Yazh assist with inbound sender data?
Yazh lets a sender map its payload once and translates it to the carrier’s Guidewire format. LiLa assists with the mapping, and a person reviews every mapping before it is used.
What is a realistic way to begin?
Start with the next sender instead of the existing ones. Route that sender through a test sandbox while current direct senders stay as they are, then compare the support load between the two routes before deciding on anything further.