v1.0.0 launch

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.

By · Founder, YonoSIMLinkedIn ↗·Published August 10, 2026·8 min read

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

FieldDuck CreekGuidewire PolicyCenterMajesco Policy
Policy numberpolicyNumberpolicyRefPolicyKey
Destination countrytrip.destinationCountrypolicy.trip.destCountryPolicyDetails.TripDestination
Trip durationtrip.durationDayspolicy.trip.daysPolicyDetails.TripDurationDays
Policyholder emailpolicyholder.emailinsured.contact.emailPolicyholder.EmailAddress
Policy issued eventpolicy.issuedPolicyBoundPolicyIssuedEvent
Policy cancelled eventpolicy.cancelledPolicyCancelledPolicyCancellationEvent
Signature headerX-DuckCreek-SignatureGuidewire-SignatureX-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.