PAS Vendor eSIM Webhook Integration: Duck Creek, Guidewire & Majesco (2026)
The three biggest Policy Admin System (PAS) platforms all support outbound webhook triggers on policy issuance, modification, and cancellation. Adding an eSIM provisioning flow is field-mapping work — different names, same shape. This is the reference table + integration path for Duck Creek, Guidewire, and Majesco.
Summary
Duck Creek, Guidewire, and Majesco all support outbound webhooks natively. Adding YonoSIM eSIM provisioning is field-mapping work — different names, same shape. Insurer-side integration under the existing outbound-webhook framework is 2–3 engineer-weeks per PAS.
Field mapping across the three PAS platforms
| Field | Duck Creek | Guidewire PolicyCenter | Majesco Policy |
|---|---|---|---|
| Policy number | policyNumber | policyRef | PolicyKey |
| Destination country | trip.destinationCountry | policy.trip.destCountry | PolicyDetails.TripDestination |
| Trip duration | trip.durationDays | policy.trip.days | PolicyDetails.TripDurationDays |
| Policyholder email | policyholder.email | insured.contact.email | Policyholder.EmailAddress |
| Policy issued event | policy.issued | PolicyBound | PolicyIssuedEvent |
| Policy cancelled event | policy.cancelled | PolicyCancelled | PolicyCancellationEvent |
| Signature header | X-DuckCreek-Signature | Guidewire-Signature | X-Majesco-Sig |
Insurer-side middleware pattern
A thin translator layer normalizes each PAS's event into a common shape, then routes to the shared provisioning function. Same insurers already run this for TMC + analytics integrations.
// middleware/normalize.ts
interface NormalizedPolicyEvent {
policyNumber: string;
destinationCountry: string;
tripDurationDays: number;
policyholderEmail: string;
eventType: 'issued' | 'cancelled';
}
export function normalizeDuckCreek(payload: any): NormalizedPolicyEvent {
return {
policyNumber: payload.data.policyNumber,
destinationCountry: payload.data.trip.destinationCountry,
tripDurationDays: payload.data.trip.durationDays,
policyholderEmail: payload.data.policyholder.email,
eventType: payload.type === 'policy.issued' ? 'issued' : 'cancelled',
};
}
export function normalizeGuidewire(payload: any): NormalizedPolicyEvent {
return {
policyNumber: payload.policyRef,
destinationCountry: payload.policy.trip.destCountry,
tripDurationDays: payload.policy.trip.days,
policyholderEmail: payload.insured.contact.email,
eventType: payload.eventType === 'PolicyBound' ? 'issued' : 'cancelled',
};
}
export function normalizeMajesco(payload: any): NormalizedPolicyEvent {
return {
policyNumber: payload.PolicyKey,
destinationCountry: payload.PolicyDetails.TripDestination,
tripDurationDays: payload.PolicyDetails.TripDurationDays,
policyholderEmail: payload.Policyholder.EmailAddress,
eventType: payload.EventName === 'PolicyIssuedEvent' ? 'issued' : 'cancelled',
};
}Shared downstream provisioning function
// provisioning/esim.ts — same for all three PAS platforms
export async function provisionEsimForPolicy(evt: NormalizedPolicyEvent) {
if (evt.eventType === 'cancelled') {
const esimOrderId = await lookupEsimForPolicy(evt.policyNumber);
if (esimOrderId) {
await fetch(`https://api.yonosim.com/v1/orders/${esimOrderId}/refund`, {
method: 'POST',
headers: { Authorization: `Bearer ${process.env.YONOSIM_API_KEY}` },
});
}
return;
}
// eventType === 'issued'
const res = await fetch('https://api.yonosim.com/v1/orders', {
method: 'POST',
headers: {
'Authorization': `Bearer ${process.env.YONOSIM_API_KEY}`,
'Content-Type': 'application/json',
'Idempotency-Key': `policy-${evt.policyNumber}`,
},
body: JSON.stringify({
planId: pickPlanForDestination(evt.destinationCountry, evt.tripDurationDays),
customerEmail: evt.policyholderEmail,
metadata: { policyNumber: evt.policyNumber },
}),
});
const order = await res.json();
await storeEsimForPolicy(evt.policyNumber, order.id, order.activationUrl);
await triggerPolicyPdfRegen(evt.policyNumber, order);
}FAQ
QWhich PAS platforms support outbound webhooks natively?
AAll three biggest — Duck Creek Policy (via Integration Framework + Adapter), Guidewire PolicyCenter (via Integration Gateway + Cloud API), and Majesco Policy for L&AH (via Event Framework + Digital Distribution SDK). Each ships policy.issued, policy.modified, policy.cancelled events with signed payloads. The eSIM integration wires into the same outbound-webhook framework the PAS already uses for TMC integrations, notification services, and analytics feeds.
QWhat's the field-name mapping across the three?
ADifferent names, same shape. Destination country: Duck Creek exposes it as trip.destinationCountry, Guidewire as policy.trip.destCountry, Majesco as PolicyDetails.TripDestination. Policy number: Duck Creek policyNumber, Guidewire policyRef, Majesco PolicyKey. Full field-mapping table below. Once mapped in your middleware, the downstream POST /v1/orders call is identical across all three.
QHow does the middleware layer typically look?
AA thin webhook translator that normalizes each PAS's event shape into a common internal event, then routes to the eSIM provisioning function. Most insurers already run this layer for other integrations (TMC, analytics, reinsurance feeds). Under the pattern we most often see: express/Fastify service listening on /webhooks/duck-creek, /webhooks/guidewire, /webhooks/majesco endpoints, each with its own signature verification, all converging to a shared provisionEsimForPolicy() function.
QDoes each PAS have a preferred integration mechanism (e.g. SDK, marketplace app)?
ADuck Creek has a Marketplace where vendors can publish official Adapters — YonoSIM's Duck Creek Adapter (planned Q4 2026) would be listed there. Guidewire has the App Framework + Marketplace with similar dynamics. Majesco has the Digital Distribution SDK. For custom integrations without going through the vendor marketplace, all three support direct outbound webhooks via configuration — same integration shape, no marketplace listing required.
QWhat about legacy PAS platforms that don't support webhooks natively?
ATwo patterns. (1) Polling adapter — a scheduled job that queries the PAS's policy database for new/modified/cancelled policies since last poll, then triggers the same downstream flow. Higher latency, easier for legacy systems. (2) Middle-layer trigger via the insurer's data warehouse — most insurers already replicate PAS data into a warehouse (Snowflake, BigQuery); trigger the provisioning flow off new rows landing there. Pattern 2 is what most legacy migrations use.
QCan YonoSIM be integrated by the PAS vendor directly, or does it have to be the insurer's team?
AEither. Most Duck Creek/Guidewire/Majesco vendor integrations start with the insurer's team building against their existing outbound-webhook framework — because the insurer owns the destination/tripdays field-mapping logic anyway. Vendor-side integrations (where DC/GW/M ships the connector as a pre-built module) come later in market adoption, once volume justifies vendor-side engineering. As of 2026, all YonoSIM PAS integrations are insurer-side.
Bottom line
The three biggest PAS platforms — Duck Creek, Guidewire, Majesco — all support outbound webhooks natively. Adding eSIM provisioning is field-mapping work in a thin middleware layer, then a shared downstream function that calls the YonoSIM API. 2–3 engineer-weeks per PAS. The playground at api.yonosim.com/docs validates the YonoSIM side; the PAS side is your team's mapping work. Back to the Travel insurance hub.