Your product sends submissions or claims into a carrier's Guidewire PolicyCenter or ClaimCenter, and it works. Then the carrier changes from a self-managed install to Guidewire Cloud, or a new customer arrives already on Cloud, and the same integration meets a different protocol, a different login, and a different release schedule.
Your engineers find out which calls break when the first request fails. By then the carrier's date is close.
This article names the four points that change for an outside integration, shows how each differs between the two deployments, and gives a four-step check you run before that date arrives.
What Is the Difference Between Guidewire On-Premises and Cloud APIs?
On Guidewire Cloud, outside systems call a standard set of REST endpoints that Guidewire publishes. On a self-managed install, the carrier builds, hosts, and versions the interfaces itself.
Protocol and Contract
Guidewire Cloud follows the API-first pattern. The Cloud API is a set of RESTful system APIs, built on the Guidewire REST API framework with the Swagger 2.0 specification, that callers use to read data from or start actions in PolicyCenter, ClaimCenter, BillingCenter, and ContactManager.
The consumer guide for release 2026.03 also documents composite requests, batch requests, asynchronous calls, and graph endpoints that create accounts and submissions in fewer calls. A sender built around one call per record has new options to check.
On a self-managed install, the contract is whatever the carrier's team built. Guidewire's documentation cannot describe those additions for you.
Where Integration Logic Runs
On self-managed installs, integration logic is commonly written in Gosu inside InsuranceSuite. On Guidewire Cloud, Guidewire's own tooling moves that logic outside the core applications: Cloud API for inbound calls, App Events for outbound business events, and a cloud-managed service built on Apache Camel.
If your product listens for carrier events, find out which delivery route the carrier uses. App Events publishes by webhook or through that managed service.
Each sender that builds its own route into a carrier's core also adds another point-to-point connection for someone to maintain.
How Does Authentication Change for an Outside Sender?
On Guidewire Cloud, Guidewire Hub issues a signed token under OAuth 2.0, and every call from a caller application carries authentication information.
Identity Moves to Guidewire Hub
Guidewire documents Hub as the trusted authorization server for all Guidewire cloud applications, using OAuth 2.0 and SAML. Every insurer supplies an identity provider, and Hub builds the JSON Web Tokens that carry each caller's authorization.
A service that sends data, as opposed to a person who logs in, authenticates to Hub directly. The insurer's identity provider plays no role in that exchange.
Tokens also limit each call to the endpoints, operations, fields, and resources the caller is authorized to use. A call can therefore fail on authorization even when authentication succeeds.
Brokers and MGAs need one more check. Guidewire notes that some producers hold hundreds of producer codes, too many to carry inside a token, so the carrier retrieves them from another application after the token arrives.
What Stops Working
Basic authentication passes a username and password in the request header. Guidewire states that it is not supported in production environments.
If your self-managed integration logs in with a stored username and password, plan a new credential flow with the carrier's team. That flow includes a registered caller application, an API role, and token handling inside your sender.
How Do Guidewire Cloud Releases Affect an Outside Integration?
Guidewire Cloud ships named releases on a fixed rhythm, and each release updates the Cloud API your sender calls.
Release Cadence
The Qusar release notes list Olos in December 2025, Palisades in April 2026, and Qusar in August 2026, which makes three releases a year. Guidewire's release blog points to Revelstoke this winter.
A self-managed carrier, by contrast, upgrades on its own schedule. The Qusar notes list Cloud API for PolicyCenter at version 1.16.0, so a sender pins to a version and retests when it changes.
Build the retest into your release process instead of a project plan. A scheduled test run in a non-production environment after each release catches a changed field before a live submission does.
Line-of-Business Endpoints and Payload Fit
PolicyCenter generates line-of-business endpoints from each carrier's installed products, and the developer guide covers regenerating them when products change. Two carriers on Guidewire Cloud expose different fields when their products differ.
Your payload mapping absorbs that difference. It needs a fresh review for each carrier and after each product change.
The consumer guide includes a section on handling a call with unknown elements. Read it before your payload carries a field the carrier's configuration does not define.
How Do You Check an Existing Integration Against Guidewire Cloud?
Run a four-point check on protocol and contract, identity, release cadence, and payload fit, and assign each point a carrier owner and a test.
The Four Change Points
Change point | Self-managed deployment | Guidewire Cloud | Sender's check |
|---|---|---|---|
Protocol and contract | Interfaces the carrier builds and hosts | Cloud API with published API definitions | Request the API definition |
Identity | Set by the carrier | Guidewire Hub token on every call | Register the caller and receive an API role |
Release cadence | Carrier-run upgrade projects | Named releases, three updates a year | Pin the API version and retest each release |
Payload fit | Fields follow the carrier's configuration | Endpoints generated from installed products | Re-review the mapping for each carrier and line |
Name an owner for each row. The carrier owns the identity setup and the release dates, and your team owns the contract tests and the mapping.
Running the Check
Ask the carrier which deployment each environment runs and which Guidewire release it carries.
Request the interface list for a self-managed install or the Cloud API definitions for Guidewire Cloud.
Test authentication in a non-production environment with the credential flow the carrier will use in production.
Send one payload per line of business and compare the response against the fields the carrier expects.
Rerun step 4 after every Guidewire release.
How InsOps Helps
InsOps builds an insurance-trained AI that assists with moving submission and claims data into Guidewire. LiLa, our insurance-trained LLM, drafts the field mapping from your payload to the carrier's Guidewire structure, and a person on your team confirms every mapping before data moves.
InsOps is a Guidewire technology partner. The InsOps Integration Gateway supports on-premises and cloud Guidewire APIs, handles authentication, validation and request logging, and runs inside your own environment, so PII and PHI stay in controlled infrastructure.
If you are evaluating how to exchange data with a carrier's Guidewire deployment without building your own connector, contact us to talk through what this looks like for your operation.
Frequently Asked Questions
What is the Guidewire Cloud API?
It is Guidewire's published REST interface to PolicyCenter, ClaimCenter, BillingCenter, and ContactManager. Outside systems send and retrieve records through it instead of through interfaces the carrier built.
Why does a change from self-managed to Guidewire Cloud matter to an outside sender?
Protocol, identity, release schedule, and payload fields change together. A sender that tested clean against the old deployment needs a new test pass.
How do you authenticate to the Guidewire Cloud API?
Register the caller application with Guidewire Hub, request a token for it, and send that token with each call. Basic authentication stays limited to development.
Does a self-managed Guidewire install expose the same endpoints?
Confirm it with the carrier. A self-managed install exposes the interfaces its own team built, so two carriers on the same Guidewire version can differ.
What should you track to know the integration holds up?
Track the rejected-request rate for each line of business, the count of authentication failures, and the time from each Guidewire release to a passing test run.
How long does the rework take?
The timeline follows the number of lines of business you send and what the carrier exposes. Plan the first pass on identity and payload mapping, then add a retest to every Guidewire release.
How does the InsOps Integration Gateway help?
The InsOps Integration Gateway gives senders a prebuilt route into Guidewire on-premises and cloud APIs, with a dashboard that records every request, response and error. LiLa drafts the payload mapping, and a person at the sender reviews and confirms it before data moves.