A new sender gets access to your Guidewire intake, and its first real payload is also its first test. Missing fields, wrong values, and unmapped data land in your instance. Your integration team finds out when someone has to chase a failed record.
A sandbox and a test harness move that first test out of production. The sender sends test data, sees what was accepted or rejected and why, and fixes the payload before any real submission arrives.
This article is for Guidewire integration architects and developers at carriers. It covers what a sender-facing sandbox and test harness are, what a sender should prove before go-live, how to set one up for a new sender, and how to keep testing after go-live.
Why does the first real payload make a poor test?
Every new sender arrives with its own field names, its own value lists, and its own idea of a complete record. The first real send is where those differences meet your Guidewire instance for the first time, whether that is submission intake or a first notice of loss.
Where first-send errors come from
First-send errors come from three places: structure, completeness, and values. The payload is shaped differently than the carrier expects, a mandatory field is empty, or a field holds a value outside the carrier’s valid list.
The same three sources appear in claims intake, where a TPA’s FNOL payload carries its own field names and value lists.
Why your team absorbs the cleanup
When no test path exists, the integration team becomes the test path. Developers read failed records, email the sender, and wait for a corrected file.
That cycle repeats with every new sender, which is why how MGAs, TPAs, and brokers send submission data into Guidewire PolicyCenter is a question about testing as much as transport.
What is the difference between a sandbox and a test harness?
The two terms get used interchangeably, but they do different jobs. A sandbox is where a sender sends test data. A test harness is what shows the sender the result.
The sandbox: a place to send test data
A sandbox is a separate target for test sends. The sender uses the same payload format and the same route it will use live, so nothing about the real send is a surprise.
Test sends stay apart from real submissions. An incomplete test record never reaches an underwriter or an adjuster.
The test harness: a way to read the result
A test harness runs each test send against the carrier’s rules and reports the outcome. It says whether the send was accepted or rejected, and for every rejection, which field failed and why.
The sender reads the reason, corrects its own payload, and sends again.
Why a carrier needs both
A sandbox without a harness gives the sender a place to fail silently. A harness without a sandbox forces the sender to test against live intake.
Together they let a sender correct its own payload without a ticket to your team. This matters most for underwriting workbench vendors that sell to several carriers, because each carrier has its own rules.
What should a sender prove before going live?
A sandbox is only useful if the sender leaves it having proved specific things. Five proofs cover the path from first send to go-live.
The five-proof test path
Name the proofs up front so the sender and your team agree on what “done” means.
Proof | What the sender does | What the sender sees |
|---|---|---|
1. Structure | Sends a payload in the agreed format | Whether it matches the payload specification |
2. Completeness | Leaves out a mandatory field on purpose | A rejection naming the missing field |
3. Values | Sends a value outside the valid list | A rejection naming the field and the accepted values |
4. Mapping | Sends a complete, valid payload | The mapped result in the carrier’s Guidewire format |
5. Large payload | Sends a large payload by file location | Confirmation that the file-location route is accepted |
Completeness and values
Proofs 2 and 3 matter most to the carrier, because they decide whether incomplete data stops at the door. A sender that has seen its own record rejected fixes the source before go-live.
A sender that has never seen a rejection finds out in production.
Mapping and large payloads
Proof 4 rests on payload mapping. The sender’s fields are mapped to the carrier’s Guidewire structures, and a person reviews that mapping before it is used. The sandbox lets the sender see the mapped result before any of it counts.
Proof 5 covers large batches. These arrive by file location rather than in a request body, so the sandbox should exercise that route too.
How does a carrier set up a sandbox for a new sender?
Setup is a short list of decisions made before the sender sends its first test. Each one removes a reason for the sender to come back with a question.
Hand over the payload specification first
The sender needs the structure, the mandatory fields, and the valid values before its first test send. Without them, the sandbox only reports failures the sender would have avoided.
Decide who maps and who reviews
Mapping happens on the vendor side or on the gateway side, and the choice changes what the sender tests. Read vendor-side mapping versus gateway-side mapping before fixing the split.
Whichever side maps, a person reviews every mapping before it is used.
Agree on exit criteria
Exit criteria turn the five proofs into a go-live gate. The sender moves to real submissions when all five proofs pass in the sandbox and your team signs off on the reviewed mapping.
Carrier-specific fields belong in the tenant’s mapping, so each sender tests against your rules and no one else’s.
Does testing stop at go-live?
It does not. The sandbox keeps its value after go-live, because payloads and Guidewire both change.
Re-test after a Guidewire release
Each Guidewire release can change what your instance accepts. Run the five proofs again in the sandbox before senders rely on the changed behavior.
This is the recurring work behind maintaining a Guidewire connector, and it repeats for every sender that has its own connector.
Re-test after a payload change
When a sender adds a field or changes a value list, the sandbox is where it proves the change before real submissions carry it.
Your team reviews the changed mapping the same way it reviewed the first one.
How InsOps Helps
InsOps builds Yazh (Yaal), a data exchange gateway where 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. See how dynamic data exchange for insurance works across senders.
Yazh includes a self-service portal where senders get a sandbox and a test harness to test before sending real data. Gap rejection stops incomplete data, and tenant-specific mapping keeps your carrier-specific fields in your tenant.
Yazh connects to Guidewire PolicyCenter, ClaimCenter, and BillingCenter through the InsOps Integration Gateway. Guidewire has its own product also called Integration Gateway, which is a developer framework. Yazh adds a sender-facing layer beside it: the mapping editor, the portal, and the test harness.
If you are evaluating how to let senders test before real data arrives without building a test path for each one, contact us to see the test harness live and talk through what this looks like for your operation.
Frequently Asked Questions
What is a sandbox in insurance data exchange?
A sandbox is a separate target where a sender sends test data in the same format and by the same route it will use live. Test records never reach underwriters, adjusters, or real submission queues.
What is a test harness?
A test harness runs each test send against the carrier’s rules and reports the result. For every rejection it names the field that failed and the reason.
Why does a carrier need a sandbox for senders?
Without one, the first real payload is the first test, and your integration team handles every failure by hand. A sandbox lets senders find and fix their own errors before real submissions arrive.
How does a carrier set up a sandbox for a new sender?
Hand over the payload specification, decide who maps and who reviews, and agree on exit criteria. The five proofs (structure, completeness, values, mapping, and large payload) make a clear go-live gate.
What is the most common challenge with sender testing?
Senders test only clean payloads and never see a rejection. Ask each sender to send an incomplete record and an invalid value on purpose, so it sees what failure looks like before go-live.
What should a carrier track to know sandbox testing is working?
Track which of the five proofs each sender has passed, which rejection reasons repeat across senders, and how many incomplete records reach intake after go-live. Repeating reasons point to gaps in the payload specification.
How do Yazh and a person work together during testing?
LiLa assists with mapping the sender’s fields to your Guidewire format, and a person reviews every mapping before it is used. The sender then runs test sends through the sandbox and reads the results in the test harness.