@awell-health/awell-extensions 2.1.205 → 2.1.207

package/dist/extensions/bland/actions/index.d.ts

@@ -332,6 +332,13 @@ export declare const actions: {
             description: string;
             required: true;
         };
+        signingSecret: {
+            key: string;
+            label: string;
+            obfuscated: true;
+            description: string;
+            required: false;
+        };
     }, "call_id">;
     sendCall: import("@awell-health/extensions-core").Action<{
         phoneNumber: {
@@ -659,6 +666,13 @@ export declare const actions: {
             description: string;
             required: true;
         };
+        signingSecret: {
+            key: string;
+            label: string;
+            obfuscated: true;
+            description: string;
+            required: false;
+        };
     }, "call_id">;
     getCallDetails: import("@awell-health/extensions-core").Action<{
         callId: {
@@ -676,6 +690,13 @@ export declare const actions: {
             description: string;
             required: true;
         };
+        signingSecret: {
+            key: string;
+            label: string;
+            obfuscated: true;
+            description: string;
+            required: false;
+        };
     }, "metadata" | "status" | "completed" | "from" | "to" | "summary" | "analysis" | "transcripts" | "analysisSchema" | "callData" | "callLength" | "startedAt" | "endAt" | "concatenatedTranscript" | "answeredBy" | "errorMessage">;
     stopActiveCall: import("@awell-health/extensions-core").Action<{
         callId: {
@@ -693,6 +714,13 @@ export declare const actions: {
             description: string;
             required: true;
         };
+        signingSecret: {
+            key: string;
+            label: string;
+            obfuscated: true;
+            description: string;
+            required: false;
+        };
     }, "message" | "status">;
     sendSms: import("@awell-health/extensions-core").Action<{
         userNumber: {
@@ -796,6 +824,13 @@ export declare const actions: {
             description: string;
             required: true;
         };
+        signingSecret: {
+            key: string;
+            label: string;
+            obfuscated: true;
+            description: string;
+            required: false;
+        };
     }, "conversationId" | "smsResponse">;
     createSmsConversation: import("@awell-health/extensions-core").Action<{
         userNumber: {
@@ -883,5 +918,12 @@ export declare const actions: {
             description: string;
             required: true;
         };
+        signingSecret: {
+            key: string;
+            label: string;
+            obfuscated: true;
+            description: string;
+            required: false;
+        };
     }, "conversationId" | "createResponse">;
 };

package/dist/extensions/bland/settings.d.ts

@@ -7,7 +7,15 @@ export declare const settings: {
         description: string;
         required: true;
     };
+    signingSecret: {
+        key: string;
+        label: string;
+        obfuscated: true;
+        description: string;
+        required: false;
+    };
 };
 export declare const SettingsValidationSchema: z.ZodObject<{
     apiKey: z.ZodString;
+    signingSecret: z.ZodOptional<z.ZodString>;
 }, z.core.$strip>;

package/dist/extensions/bland/settings.js

@@ -10,8 +10,16 @@ exports.settings = {
         description: '',
         required: true,
     },
+    signingSecret: {
+        key: 'signingSecret',
+        label: 'Webhook signing secret',
+        obfuscated: true,
+        description: 'The webhook signing secret from the Bland dev portal (Account Settings, Keys tab, "Replace Secret"). Bland signs each webhook with an HMAC-SHA256 of the body using it, sent in the `X-Webhook-Signature` header. When set, webhooks that are not signed with it are rejected. When left empty, incoming webhooks are not verified.',
+        required: false,
+    },
 };
 exports.SettingsValidationSchema = zod_1.z.object({
     apiKey: zod_1.z.string().min(1),
+    signingSecret: zod_1.z.string().optional(),
 });
 //# sourceMappingURL=settings.js.map

package/dist/extensions/bland/settings.js.map

@@ -1 +1 @@
-{"version":3,"file":"settings.js","sourceRoot":"","sources":["../../../extensions/bland/settings.ts"],"names":[],"mappings":";;;AACA,6BAAqC;AAExB,QAAA,QAAQ,GAAG;IACtB,MAAM,EAAE;QACN,GAAG,EAAE,QAAQ;QACb,KAAK,EAAE,eAAe;QACtB,UAAU,EAAE,IAAI;QAChB,WAAW,EAAE,EAAE;QACf,QAAQ,EAAE,IAAI;KACf;CACgC,CAAA;AAEtB,QAAA,wBAAwB,GAAG,OAAC,CAAC,MAAM,CAAC;IAC/C,MAAM,EAAE,OAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC;CACuB,CAAC,CAAA"}
+{"version":3,"file":"settings.js","sourceRoot":"","sources":["../../../extensions/bland/settings.ts"],"names":[],"mappings":";;;AACA,6BAAqC;AAExB,QAAA,QAAQ,GAAG;IACtB,MAAM,EAAE;QACN,GAAG,EAAE,QAAQ;QACb,KAAK,EAAE,eAAe;QACtB,UAAU,EAAE,IAAI;QAChB,WAAW,EAAE,EAAE;QACf,QAAQ,EAAE,IAAI;KACf;IACD,aAAa,EAAE;QACb,GAAG,EAAE,eAAe;QACpB,KAAK,EAAE,wBAAwB;QAC/B,UAAU,EAAE,IAAI;QAChB,WAAW,EACT,qUAAqU;QACvU,QAAQ,EAAE,KAAK;KAChB;CACgC,CAAA;AAEtB,QAAA,wBAAwB,GAAG,OAAC,CAAC,MAAM,CAAC;IAC/C,MAAM,EAAE,OAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC;IACzB,aAAa,EAAE,OAAC,CAAC,MAAM,EAAE,CAAC,QAAQ,EAAE;CACY,CAAC,CAAA"}

package/dist/extensions/bland/webhooks/CallCompleted/callCompleted.js

@@ -2,6 +2,7 @@
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.callCompleted = void 0;
 const lodash_1 = require("lodash");
+const verifyWebhookSignature_1 = require("../verifyWebhookSignature");
 const dataPoints = {
     callId: {
         key: 'callId',
@@ -33,15 +34,30 @@ exports.callCompleted = {
     dataPoints,
     onEvent: async ({ payload: { payload, rawBody, headers, settings }, onSuccess, onError, }) => {
         var _a, _b, _c, _d, _e, _f, _g, _h, _j;
+        if (!(0, verifyWebhookSignature_1.isWebhookRequestAuthorized)({
+            signingSecret: settings.signingSecret,
+            rawBody,
+            payload,
+            headers,
+        })) {
+            await onError({
+                response: {
+                    statusCode: 401,
+                    message: 'Invalid or missing X-Webhook-Signature header',
+                },
+            });
+            return;
+        }
         const callId = payload === null || payload === void 0 ? void 0 : payload.call_id;
         const awellPatientId = (_c = (_b = (_a = payload === null || payload === void 0 ? void 0 : payload.variables) === null || _a === void 0 ? void 0 : _a.metadata) === null || _b === void 0 ? void 0 : _b.awell_patient_id) !== null && _c !== void 0 ? _c : (_d = payload === null || payload === void 0 ? void 0 : payload.metadata) === null || _d === void 0 ? void 0 : _d.awell_patient_id;
         if ((0, lodash_1.isNil)(callId)) {
-            return await onError({
+            await onError({
                 response: {
                     statusCode: 400,
                     message: 'Missing call_id in payload',
                 },
             });
+            return;
         }
         await onSuccess({
             data_points: {

package/dist/extensions/bland/webhooks/CallCompleted/callCompleted.js.map

@@ -1 +1 @@
-{"version":3,"file":"callCompleted.js","sourceRoot":"","sources":["../../../../../extensions/bland/webhooks/CallCompleted/callCompleted.ts"],"names":[],"mappings":";;;AAAA,mCAA8B;AAQ9B,MAAM,UAAU,GAAG;IACjB,MAAM,EAAE;QACN,GAAG,EAAE,QAAQ;QACb,SAAS,EAAE,QAAQ;KACpB;IACD,SAAS,EAAE;QACT,GAAG,EAAE,WAAW;QAChB,SAAS,EAAE,SAAS;KACrB;IACD,MAAM,EAAE;QACN,GAAG,EAAE,QAAQ;QACb,SAAS,EAAE,QAAQ;KACpB;IACD,UAAU,EAAE;QACV,GAAG,EAAE,YAAY;QACjB,SAAS,EAAE,QAAQ;KACpB;IACD,YAAY,EAAE;QACZ,GAAG,EAAE,cAAc;QACnB,SAAS,EAAE,QAAQ;KACpB;IACD,UAAU,EAAE;QACV,GAAG,EAAE,YAAY;QACjB,SAAS,EAAE,MAAM;KAClB;CAC4C,CAAA;AAElC,QAAA,aAAa,GAItB;IACF,GAAG,EAAE,eAAe;IACpB,UAAU;IACV,OAAO,EAAE,KAAK,EAAE,EACd,OAAO,EAAE,EAAE,OAAO,EAAE,OAAO,EAAE,OAAO,EAAE,QAAQ,EAAE,EAChD,SAAS,EACT,OAAO,GACR,EAAE,EAAE;;QACH,MAAM,MAAM,GAAG,OAAO,aAAP,OAAO,uBAAP,OAAO,CAAE,OAAO,CAAA;QAC/B,MAAM,cAAc,GAClB,MAAA,MAAA,MAAA,OAAO,aAAP,OAAO,uBAAP,OAAO,CAAE,SAAS,0CAAE,QAAQ,0CAAE,gBAAgB,mCAC9C,MAAA,OAAO,aAAP,OAAO,uBAAP,OAAO,CAAE,QAAQ,0CAAE,gBAAgB,CAAA;QAErC,IAAI,IAAA,cAAK,EAAC,MAAM,CAAC,EAAE,CAAC;YAClB,OAAO,MAAM,OAAO,CAAC;gBACnB,QAAQ,EAAE;oBACR,UAAU,EAAE,GAAG;oBACf,OAAO,EAAE,4BAA4B;iBACtC;aACF,CAAC,CAAA;QACJ,CAAC;QAED,MAAM,SAAS,CAAC;YACd,WAAW,EAAE;gBACX,MAAM;gBACN,UAAU,EAAE,IAAI,CAAC,SAAS,CAAC,OAAO,CAAC;gBACnC;;;mBAGG;gBACH,SAAS,EAAE,MAAA,MAAA,OAAO,aAAP,OAAO,uBAAP,OAAO,CAAE,SAAS,0CAAE,QAAQ,EAAE,mCAAI,EAAE;gBAC/C;;;;;;;;mBAQG;gBACH,MAAM,EAAE,MAAA,OAAO,aAAP,OAAO,uBAAP,OAAO,CAAE,MAAM,mCAAI,EAAE;gBAC7B;;;;;;mBAMG;gBACH,UAAU,EAAE,MAAA,OAAO,aAAP,OAAO,uBAAP,OAAO,CAAE,WAAW,mCAAI,EAAE;gBACtC;;mBAEG;gBACH,YAAY,EAAE,MAAA,OAAO,aAAP,OAAO,uBAAP,OAAO,CAAE,aAAa,mCAAI,EAAE;aAC3C;YACD,GAAG,CAAC,cAAc,KAAK,SAAS,IAAI,EAAE,UAAU,EAAE,cAAc,EAAE,CAAC;SACpE,CAAC,CAAA;IACJ,CAAC;CACF,CAAA"}
+{"version":3,"file":"callCompleted.js","sourceRoot":"","sources":["../../../../../extensions/bland/webhooks/CallCompleted/callCompleted.ts"],"names":[],"mappings":";;;AAAA,mCAA8B;AAM9B,sEAAsE;AAGtE,MAAM,UAAU,GAAG;IACjB,MAAM,EAAE;QACN,GAAG,EAAE,QAAQ;QACb,SAAS,EAAE,QAAQ;KACpB;IACD,SAAS,EAAE;QACT,GAAG,EAAE,WAAW;QAChB,SAAS,EAAE,SAAS;KACrB;IACD,MAAM,EAAE;QACN,GAAG,EAAE,QAAQ;QACb,SAAS,EAAE,QAAQ;KACpB;IACD,UAAU,EAAE;QACV,GAAG,EAAE,YAAY;QACjB,SAAS,EAAE,QAAQ;KACpB;IACD,YAAY,EAAE;QACZ,GAAG,EAAE,cAAc;QACnB,SAAS,EAAE,QAAQ;KACpB;IACD,UAAU,EAAE;QACV,GAAG,EAAE,YAAY;QACjB,SAAS,EAAE,MAAM;KAClB;CAC4C,CAAA;AAElC,QAAA,aAAa,GAItB;IACF,GAAG,EAAE,eAAe;IACpB,UAAU;IACV,OAAO,EAAE,KAAK,EAAE,EACd,OAAO,EAAE,EAAE,OAAO,EAAE,OAAO,EAAE,OAAO,EAAE,QAAQ,EAAE,EAChD,SAAS,EACT,OAAO,GACR,EAAE,EAAE;;QACH,IACE,CAAC,IAAA,mDAA0B,EAAC;YAC1B,aAAa,EAAE,QAAQ,CAAC,aAAa;YACrC,OAAO;YACP,OAAO;YACP,OAAO;SACR,CAAC,EACF,CAAC;YACD,MAAM,OAAO,CAAC;gBACZ,QAAQ,EAAE;oBACR,UAAU,EAAE,GAAG;oBACf,OAAO,EAAE,+CAA+C;iBACzD;aACF,CAAC,CAAA;YACF,OAAM;QACR,CAAC;QAED,MAAM,MAAM,GAAG,OAAO,aAAP,OAAO,uBAAP,OAAO,CAAE,OAAO,CAAA;QAC/B,MAAM,cAAc,GAClB,MAAA,MAAA,MAAA,OAAO,aAAP,OAAO,uBAAP,OAAO,CAAE,SAAS,0CAAE,QAAQ,0CAAE,gBAAgB,mCAC9C,MAAA,OAAO,aAAP,OAAO,uBAAP,OAAO,CAAE,QAAQ,0CAAE,gBAAgB,CAAA;QAErC,IAAI,IAAA,cAAK,EAAC,MAAM,CAAC,EAAE,CAAC;YAClB,MAAM,OAAO,CAAC;gBACZ,QAAQ,EAAE;oBACR,UAAU,EAAE,GAAG;oBACf,OAAO,EAAE,4BAA4B;iBACtC;aACF,CAAC,CAAA;YACF,OAAM;QACR,CAAC;QAED,MAAM,SAAS,CAAC;YACd,WAAW,EAAE;gBACX,MAAM;gBACN,UAAU,EAAE,IAAI,CAAC,SAAS,CAAC,OAAO,CAAC;gBACnC;;;mBAGG;gBACH,SAAS,EAAE,MAAA,MAAA,OAAO,aAAP,OAAO,uBAAP,OAAO,CAAE,SAAS,0CAAE,QAAQ,EAAE,mCAAI,EAAE;gBAC/C;;;;;;;;mBAQG;gBACH,MAAM,EAAE,MAAA,OAAO,aAAP,OAAO,uBAAP,OAAO,CAAE,MAAM,mCAAI,EAAE;gBAC7B;;;;;;mBAMG;gBACH,UAAU,EAAE,MAAA,OAAO,aAAP,OAAO,uBAAP,OAAO,CAAE,WAAW,mCAAI,EAAE;gBACtC;;mBAEG;gBACH,YAAY,EAAE,MAAA,OAAO,aAAP,OAAO,uBAAP,OAAO,CAAE,aAAa,mCAAI,EAAE;aAC3C;YACD,GAAG,CAAC,cAAc,KAAK,SAAS,IAAI,EAAE,UAAU,EAAE,cAAc,EAAE,CAAC;SACpE,CAAC,CAAA;IACJ,CAAC;CACF,CAAA"}

package/dist/extensions/bland/webhooks/CompletedBlandText/completedBlandText.js

@@ -2,6 +2,7 @@
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.completedBlandText = void 0;
 const lodash_1 = require("lodash");
+const verifyWebhookSignature_1 = require("../verifyWebhookSignature");
 const dataPoints = {
     conversationId: {
         key: 'conversationId',
@@ -48,8 +49,22 @@ exports.completedBlandText = {
     key: 'completedBlandText',
     description: 'Triggered when a Bland SMS conversation ends (status webhook with channel "sms").',
     dataPoints,
-    onEvent: async ({ payload: { payload }, onSuccess, onError }) => {
+    onEvent: async ({ payload: { payload, rawBody, headers, settings }, onSuccess, onError, }) => {
         var _a, _b, _c, _d, _e, _f, _g, _h, _j, _k, _l, _m;
+        if (!(0, verifyWebhookSignature_1.isWebhookRequestAuthorized)({
+            signingSecret: settings.signingSecret,
+            rawBody,
+            payload,
+            headers,
+        })) {
+            await onError({
+                response: {
+                    statusCode: 401,
+                    message: 'Invalid or missing X-Webhook-Signature header',
+                },
+            });
+            return;
+        }
         const conversationId = payload === null || payload === void 0 ? void 0 : payload.conversation_id;
         const awellPatientId = (_b = (_a = payload === null || payload === void 0 ? void 0 : payload.metadata) === null || _a === void 0 ? void 0 : _a.awell_patient_id) !== null && _b !== void 0 ? _b : (_d = (_c = payload === null || payload === void 0 ? void 0 : payload.variables) === null || _c === void 0 ? void 0 : _c.metadata) === null || _d === void 0 ? void 0 : _d.awell_patient_id;
         if ((0, lodash_1.isNil)(conversationId)) {

package/dist/extensions/bland/webhooks/CompletedBlandText/completedBlandText.js.map

@@ -1 +1 @@
-{"version":3,"file":"completedBlandText.js","sourceRoot":"","sources":["../../../../../extensions/bland/webhooks/CompletedBlandText/completedBlandText.ts"],"names":[],"mappings":";;;AAAA,mCAA8B;AAQ9B,MAAM,UAAU,GAAG;IACjB,cAAc,EAAE;QACd,GAAG,EAAE,gBAAgB;QACrB,SAAS,EAAE,QAAQ;KACpB;IACD,MAAM,EAAE;QACN,GAAG,EAAE,QAAQ;QACb,SAAS,EAAE,QAAQ;KACpB;IACD,MAAM,EAAE;QACN,GAAG,EAAE,QAAQ;QACb,SAAS,EAAE,QAAQ;KACpB;IACD,UAAU,EAAE;QACV,GAAG,EAAE,YAAY;QACjB,SAAS,EAAE,QAAQ;KACpB;IACD,WAAW,EAAE;QACX,GAAG,EAAE,aAAa;QAClB,SAAS,EAAE,QAAQ;KACpB;IACD,SAAS,EAAE;QACT,GAAG,EAAE,WAAW;QAChB,SAAS,EAAE,QAAQ;KACpB;IACD,YAAY,EAAE;QACZ,GAAG,EAAE,cAAc;QACnB,SAAS,EAAE,QAAQ;KACpB;IACD,UAAU,EAAE;QACV,GAAG,EAAE,YAAY;QACjB,SAAS,EAAE,QAAQ;KACpB;IACD,SAAS,EAAE;QACT,GAAG,EAAE,WAAW;QAChB,SAAS,EAAE,MAAM;KAClB;IACD,kBAAkB,EAAE;QAClB,GAAG,EAAE,oBAAoB;QACzB,SAAS,EAAE,MAAM;KAClB;CAC4C,CAAA;AAElC,QAAA,kBAAkB,GAI3B;IACF,GAAG,EAAE,oBAAoB;IACzB,WAAW,EACT,mFAAmF;IACrF,UAAU;IACV,OAAO,EAAE,KAAK,EAAE,EAAE,OAAO,EAAE,EAAE,OAAO,EAAE,EAAE,SAAS,EAAE,OAAO,EAAE,EAAE,EAAE;;QAC9D,MAAM,cAAc,GAAG,OAAO,aAAP,OAAO,uBAAP,OAAO,CAAE,eAAe,CAAA;QAC/C,MAAM,cAAc,GAClB,MAAA,MAAA,OAAO,aAAP,OAAO,uBAAP,OAAO,CAAE,QAAQ,0CAAE,gBAAgB,mCACnC,MAAC,MAAA,OAAO,aAAP,OAAO,uBAAP,OAAO,CAAE,SAAS,0CAAE,QAA+C,0CAChE,gBAAgB,CAAA;QAEtB,IAAI,IAAA,cAAK,EAAC,cAAc,CAAC,EAAE,CAAC;YAC1B,MAAM,OAAO,CAAC;gBACZ,QAAQ,EAAE;oBACR,UAAU,EAAE,GAAG;oBACf,OAAO,EAAE,oCAAoC;iBAC9C;aACF,CAAC,CAAC;YAAC,OAAO;QACb,CAAC;QAED,MAAM,SAAS,CAAC;YACd,WAAW,EAAE;gBACX,cAAc;gBACd;;mBAEG;gBACH,MAAM,EAAE,MAAA,OAAO,aAAP,OAAO,uBAAP,OAAO,CAAE,MAAM,mCAAI,EAAE;gBAC7B;;;mBAGG;gBACH,MAAM,EAAE,MAAA,OAAO,aAAP,OAAO,uBAAP,OAAO,CAAE,MAAM,mCAAI,EAAE;gBAC7B,UAAU,EAAE,MAAA,OAAO,aAAP,OAAO,uBAAP,OAAO,CAAE,YAAY,mCAAI,EAAE;gBACvC,WAAW,EAAE,MAAA,OAAO,aAAP,OAAO,uBAAP,OAAO,CAAE,YAAY,mCAAI,EAAE;gBACxC,SAAS,EAAE,MAAA,OAAO,aAAP,OAAO,uBAAP,OAAO,CAAE,UAAU,mCAAI,EAAE;gBACpC,YAAY,EAAE,MAAA,MAAA,OAAO,aAAP,OAAO,uBAAP,OAAO,CAAE,aAAa,0CAAE,QAAQ,EAAE,mCAAI,EAAE;gBACtD;;;mBAGG;gBACH,UAAU,EAAE,MAAA,OAAO,aAAP,OAAO,uBAAP,OAAO,CAAE,uBAAuB,mCAAI,EAAE;gBAClD;;;mBAGG;gBACH,SAAS,EAAE,IAAA,cAAK,EAAC,OAAO,aAAP,OAAO,uBAAP,OAAO,CAAE,SAAS,CAAC;oBAClC,CAAC,CAAC,EAAE;oBACJ,CAAC,CAAC,IAAI,CAAC,SAAS,CAAC,OAAO,CAAC,SAAS,CAAC;gBACrC,kBAAkB,EAAE,IAAI,CAAC,SAAS,CAAC,OAAO,CAAC;aAC5C;YACD,GAAG,CAAC,cAAc,KAAK,SAAS,IAAI,EAAE,UAAU,EAAE,cAAc,EAAE,CAAC;SACpE,CAAC,CAAA;IACJ,CAAC;CACF,CAAA"}
+{"version":3,"file":"completedBlandText.js","sourceRoot":"","sources":["../../../../../extensions/bland/webhooks/CompletedBlandText/completedBlandText.ts"],"names":[],"mappings":";;;AAAA,mCAA8B;AAM9B,sEAAsE;AAGtE,MAAM,UAAU,GAAG;IACjB,cAAc,EAAE;QACd,GAAG,EAAE,gBAAgB;QACrB,SAAS,EAAE,QAAQ;KACpB;IACD,MAAM,EAAE;QACN,GAAG,EAAE,QAAQ;QACb,SAAS,EAAE,QAAQ;KACpB;IACD,MAAM,EAAE;QACN,GAAG,EAAE,QAAQ;QACb,SAAS,EAAE,QAAQ;KACpB;IACD,UAAU,EAAE;QACV,GAAG,EAAE,YAAY;QACjB,SAAS,EAAE,QAAQ;KACpB;IACD,WAAW,EAAE;QACX,GAAG,EAAE,aAAa;QAClB,SAAS,EAAE,QAAQ;KACpB;IACD,SAAS,EAAE;QACT,GAAG,EAAE,WAAW;QAChB,SAAS,EAAE,QAAQ;KACpB;IACD,YAAY,EAAE;QACZ,GAAG,EAAE,cAAc;QACnB,SAAS,EAAE,QAAQ;KACpB;IACD,UAAU,EAAE;QACV,GAAG,EAAE,YAAY;QACjB,SAAS,EAAE,QAAQ;KACpB;IACD,SAAS,EAAE;QACT,GAAG,EAAE,WAAW;QAChB,SAAS,EAAE,MAAM;KAClB;IACD,kBAAkB,EAAE;QAClB,GAAG,EAAE,oBAAoB;QACzB,SAAS,EAAE,MAAM;KAClB;CAC4C,CAAA;AAElC,QAAA,kBAAkB,GAI3B;IACF,GAAG,EAAE,oBAAoB;IACzB,WAAW,EACT,mFAAmF;IACrF,UAAU;IACV,OAAO,EAAE,KAAK,EAAE,EACd,OAAO,EAAE,EAAE,OAAO,EAAE,OAAO,EAAE,OAAO,EAAE,QAAQ,EAAE,EAChD,SAAS,EACT,OAAO,GACR,EAAE,EAAE;;QACH,IACE,CAAC,IAAA,mDAA0B,EAAC;YAC1B,aAAa,EAAE,QAAQ,CAAC,aAAa;YACrC,OAAO;YACP,OAAO;YACP,OAAO;SACR,CAAC,EACF,CAAC;YACD,MAAM,OAAO,CAAC;gBACZ,QAAQ,EAAE;oBACR,UAAU,EAAE,GAAG;oBACf,OAAO,EAAE,+CAA+C;iBACzD;aACF,CAAC,CAAA;YACF,OAAM;QACR,CAAC;QAED,MAAM,cAAc,GAAG,OAAO,aAAP,OAAO,uBAAP,OAAO,CAAE,eAAe,CAAA;QAC/C,MAAM,cAAc,GAClB,MAAA,MAAA,OAAO,aAAP,OAAO,uBAAP,OAAO,CAAE,QAAQ,0CAAE,gBAAgB,mCACnC,MAAC,MAAA,OAAO,aAAP,OAAO,uBAAP,OAAO,CAAE,SAAS,0CAAE,QAA+C,0CAChE,gBAAgB,CAAA;QAEtB,IAAI,IAAA,cAAK,EAAC,cAAc,CAAC,EAAE,CAAC;YAC1B,MAAM,OAAO,CAAC;gBACZ,QAAQ,EAAE;oBACR,UAAU,EAAE,GAAG;oBACf,OAAO,EAAE,oCAAoC;iBAC9C;aACF,CAAC,CAAC;YAAC,OAAO;QACb,CAAC;QAED,MAAM,SAAS,CAAC;YACd,WAAW,EAAE;gBACX,cAAc;gBACd;;mBAEG;gBACH,MAAM,EAAE,MAAA,OAAO,aAAP,OAAO,uBAAP,OAAO,CAAE,MAAM,mCAAI,EAAE;gBAC7B;;;mBAGG;gBACH,MAAM,EAAE,MAAA,OAAO,aAAP,OAAO,uBAAP,OAAO,CAAE,MAAM,mCAAI,EAAE;gBAC7B,UAAU,EAAE,MAAA,OAAO,aAAP,OAAO,uBAAP,OAAO,CAAE,YAAY,mCAAI,EAAE;gBACvC,WAAW,EAAE,MAAA,OAAO,aAAP,OAAO,uBAAP,OAAO,CAAE,YAAY,mCAAI,EAAE;gBACxC,SAAS,EAAE,MAAA,OAAO,aAAP,OAAO,uBAAP,OAAO,CAAE,UAAU,mCAAI,EAAE;gBACpC,YAAY,EAAE,MAAA,MAAA,OAAO,aAAP,OAAO,uBAAP,OAAO,CAAE,aAAa,0CAAE,QAAQ,EAAE,mCAAI,EAAE;gBACtD;;;mBAGG;gBACH,UAAU,EAAE,MAAA,OAAO,aAAP,OAAO,uBAAP,OAAO,CAAE,uBAAuB,mCAAI,EAAE;gBAClD;;;mBAGG;gBACH,SAAS,EAAE,IAAA,cAAK,EAAC,OAAO,aAAP,OAAO,uBAAP,OAAO,CAAE,SAAS,CAAC;oBAClC,CAAC,CAAC,EAAE;oBACJ,CAAC,CAAC,IAAI,CAAC,SAAS,CAAC,OAAO,CAAC,SAAS,CAAC;gBACrC,kBAAkB,EAAE,IAAI,CAAC,SAAS,CAAC,OAAO,CAAC;aAC5C;YACD,GAAG,CAAC,cAAc,KAAK,SAAS,IAAI,EAAE,UAAU,EAAE,cAAc,EAAE,CAAC;SACpE,CAAC,CAAA;IACJ,CAAC;CACF,CAAA"}

package/dist/extensions/bland/webhooks/index.d.ts

@@ -6,6 +6,13 @@ export declare const webhooks: (import("@awell-health/extensions-core").Webhook<
         description: string;
         required: true;
     };
+    signingSecret: {
+        key: string;
+        label: string;
+        obfuscated: true;
+        description: string;
+        required: false;
+    };
 }> | import("@awell-health/extensions-core").Webhook<"status" | "reason" | "pathwayId" | "variables" | "userNumber" | "agentNumber" | "conversationId" | "messageCount" | "transcript" | "conversationObject", import("./CompletedBlandText/types").CompletedBlandTextWebhookPayload, {
     apiKey: {
         key: string;
@@ -14,4 +21,11 @@ export declare const webhooks: (import("@awell-health/extensions-core").Webhook<
         description: string;
         required: true;
     };
+    signingSecret: {
+        key: string;
+        label: string;
+        obfuscated: true;
+        description: string;
+        required: false;
+    };
 }>)[];

package/dist/extensions/bland/webhooks/verifyWebhookSignature.d.ts

@@ -0,0 +1,26 @@
+import { type IncomingHttpHeaders } from 'http';
+/**
+ * The header Bland delivers the webhook signature in.
+ * https://docs.bland.ai/tutorials/webhook-signing
+ */
+export declare const BLAND_SIGNATURE_HEADER = "x-webhook-signature";
+/**
+ * Verifies a Bland webhook request.
+ *
+ * Bland signs each webhook with an HMAC-SHA256 of the body using the account's
+ * webhook secret, hex-encoded in `X-Webhook-Signature`. Bland's own example
+ * verifies against `JSON.stringify(req.body)`, the re-serialized body, so a
+ * signature over either the raw bytes or that re-serialization is accepted:
+ * both need the secret to produce. The docs describe no timestamp, so a
+ * captured request can be replayed; the signature proves who sent it, not when.
+ * https://docs.bland.ai/tutorials/webhook-signing
+ *
+ * @returns `true` if the request is authorized: either no signing secret is
+ * configured (verification disabled) or the signature is present and valid.
+ */
+export declare const isWebhookRequestAuthorized: ({ signingSecret, rawBody, payload, headers, }: {
+    signingSecret: string | undefined;
+    rawBody: Buffer;
+    payload: unknown;
+    headers: IncomingHttpHeaders;
+}) => boolean;

package/dist/extensions/bland/webhooks/verifyWebhookSignature.js

@@ -0,0 +1,50 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.isWebhookRequestAuthorized = exports.BLAND_SIGNATURE_HEADER = void 0;
+const crypto_1 = require("crypto");
+const lodash_1 = require("lodash");
+/**
+ * The header Bland delivers the webhook signature in.
+ * https://docs.bland.ai/tutorials/webhook-signing
+ */
+exports.BLAND_SIGNATURE_HEADER = 'x-webhook-signature';
+const hmacHex = (secret, data) => (0, crypto_1.createHmac)('sha256', secret).update(data).digest('hex');
+/** Constant-time comparison; `timingSafeEqual` throws on different lengths. */
+const sameHex = (expected, received) => {
+    const a = Buffer.from(expected.toLowerCase());
+    const b = Buffer.from(received.trim().toLowerCase());
+    return a.length === b.length && (0, crypto_1.timingSafeEqual)(a, b);
+};
+/**
+ * Verifies a Bland webhook request.
+ *
+ * Bland signs each webhook with an HMAC-SHA256 of the body using the account's
+ * webhook secret, hex-encoded in `X-Webhook-Signature`. Bland's own example
+ * verifies against `JSON.stringify(req.body)`, the re-serialized body, so a
+ * signature over either the raw bytes or that re-serialization is accepted:
+ * both need the secret to produce. The docs describe no timestamp, so a
+ * captured request can be replayed; the signature proves who sent it, not when.
+ * https://docs.bland.ai/tutorials/webhook-signing
+ *
+ * @returns `true` if the request is authorized: either no signing secret is
+ * configured (verification disabled) or the signature is present and valid.
+ */
+const isWebhookRequestAuthorized = ({ signingSecret, rawBody, payload, headers, }) => {
+    const secret = signingSecret === null || signingSecret === void 0 ? void 0 : signingSecret.trim();
+    // When no signing secret is configured, signature verification is disabled.
+    if ((0, lodash_1.isNil)(secret) || secret.length === 0) {
+        return true;
+    }
+    const header = headers[exports.BLAND_SIGNATURE_HEADER];
+    const signature = Array.isArray(header) ? header[0] : header;
+    if ((0, lodash_1.isNil)(signature) || signature.length === 0) {
+        return false;
+    }
+    if (sameHex(hmacHex(secret, rawBody), signature)) {
+        return true;
+    }
+    return (payload !== undefined &&
+        sameHex(hmacHex(secret, JSON.stringify(payload)), signature));
+};
+exports.isWebhookRequestAuthorized = isWebhookRequestAuthorized;
+//# sourceMappingURL=verifyWebhookSignature.js.map

package/dist/extensions/bland/webhooks/verifyWebhookSignature.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"verifyWebhookSignature.js","sourceRoot":"","sources":["../../../../extensions/bland/webhooks/verifyWebhookSignature.ts"],"names":[],"mappings":";;;AAAA,mCAAoD;AAEpD,mCAA8B;AAE9B;;;GAGG;AACU,QAAA,sBAAsB,GAAG,qBAAqB,CAAA;AAE3D,MAAM,OAAO,GAAG,CAAC,MAAc,EAAE,IAAqB,EAAU,EAAE,CAChE,IAAA,mBAAU,EAAC,QAAQ,EAAE,MAAM,CAAC,CAAC,MAAM,CAAC,IAAI,CAAC,CAAC,MAAM,CAAC,KAAK,CAAC,CAAA;AAEzD,+EAA+E;AAC/E,MAAM,OAAO,GAAG,CAAC,QAAgB,EAAE,QAAgB,EAAW,EAAE;IAC9D,MAAM,CAAC,GAAG,MAAM,CAAC,IAAI,CAAC,QAAQ,CAAC,WAAW,EAAE,CAAC,CAAA;IAC7C,MAAM,CAAC,GAAG,MAAM,CAAC,IAAI,CAAC,QAAQ,CAAC,IAAI,EAAE,CAAC,WAAW,EAAE,CAAC,CAAA;IACpD,OAAO,CAAC,CAAC,MAAM,KAAK,CAAC,CAAC,MAAM,IAAI,IAAA,wBAAe,EAAC,CAAC,EAAE,CAAC,CAAC,CAAA;AACvD,CAAC,CAAA;AAED;;;;;;;;;;;;;GAaG;AACI,MAAM,0BAA0B,GAAG,CAAC,EACzC,aAAa,EACb,OAAO,EACP,OAAO,EACP,OAAO,GAMR,EAAW,EAAE;IACZ,MAAM,MAAM,GAAG,aAAa,aAAb,aAAa,uBAAb,aAAa,CAAE,IAAI,EAAE,CAAA;IACpC,4EAA4E;IAC5E,IAAI,IAAA,cAAK,EAAC,MAAM,CAAC,IAAI,MAAM,CAAC,MAAM,KAAK,CAAC,EAAE,CAAC;QACzC,OAAO,IAAI,CAAA;IACb,CAAC;IAED,MAAM,MAAM,GAAG,OAAO,CAAC,8BAAsB,CAAC,CAAA;IAC9C,MAAM,SAAS,GAAG,KAAK,CAAC,OAAO,CAAC,MAAM,CAAC,CAAC,CAAC,CAAC,MAAM,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,MAAM,CAAA;IAC5D,IAAI,IAAA,cAAK,EAAC,SAAS,CAAC,IAAI,SAAS,CAAC,MAAM,KAAK,CAAC,EAAE,CAAC;QAC/C,OAAO,KAAK,CAAA;IACd,CAAC;IAED,IAAI,OAAO,CAAC,OAAO,CAAC,MAAM,EAAE,OAAO,CAAC,EAAE,SAAS,CAAC,EAAE,CAAC;QACjD,OAAO,IAAI,CAAA;IACb,CAAC;IACD,OAAO,CACL,OAAO,KAAK,SAAS;QACrB,OAAO,CAAC,OAAO,CAAC,MAAM,EAAE,IAAI,CAAC,SAAS,CAAC,OAAO,CAAC,CAAC,EAAE,SAAS,CAAC,CAC7D,CAAA;AACH,CAAC,CAAA;AA9BY,QAAA,0BAA0B,8BA8BtC"}

package/dist/extensions/markdown.json

@@ -20,8 +20,8 @@
     "changelog": "# CHANGELOG"
   },
   "bland": {
-    "readme": "---\ntitle: Bland.ai\ndescription: To do\n---\n\n# Bland.ai\n\nWith Bland.ai you can build, test, and deploy AI phone calling agents. \n\n## Extension settings\n\nTo set up this extension, you will need to provide an API key for Bland.\n\n## Actions\n\n### Send call (with Pathway)\n\nInitiates an AI phone call using a simple prompt or a conversational pathway agent built on the Bland platform. This action is asynchronous—it triggers a call request in Bland, which queues the call. Note that the action only confirms that Bland has received the request; it does not wait for the call to complete or handle any callbacks from Bland.\n\nAwell lets you specify both the data you want to send to Bland and the structured data you’d like to receive in return. This is achieved by defining the request data for outgoing information and an analysis schema for the structured data you’ll get back.\n\n#### Request data\n\nAny JSON you put in here will be visible to the AI agent during the call - and can also be referenced with Prompt Variables.\n\nFor example, let’s say in the action you want to programmatically set the name of the person you’re calling. You could set request data to:\n\n```json\n{\n    \"name\": \"John Doe\",\n}\n```\n\n[Also see Bland documentation.](https://docs.bland.ai/api-v1/post/calls)\n\n#### Analysis schema\n\nDefine a JSON schema for how you want to get information about the call - information like email addresses, names, appointment times or any other type of custom data.\n\nFor example, if you wanted to retrieve this information from the call:\n\n```json\n{\n    \"email_address\": \"email\",\n    \"first_name\": \"string\",\n    \"last_name\": \"string\",\n    \"wants_to_book_appointment\": \"boolean\",\n    \"appointment_time\": \"YYYY-MM-DD HH:MM:SS\"\n}\n```\n\nWhen retrieving the call details, Bland will return data about the call in the following format:\n\n```json\n{\n  \"analysis\": {\n    \"email_address\": \"johndoe@gmail.com\",\n    \"first_name\": \"John\",\n    \"last_name\": \"Doe\",\n    \"wants_to_book_appointment\": true,\n    \"appointment_time\": \"2024-01-01 12:00:00\"\n  }\n}\n```\n\n[Also see Bland documentation.](https://docs.bland.ai/api-v1/post/calls)\n\n### Get call details\n\nRetrieve the details of a call based on the provider call ID.",
-    "changelog": "# CHANGELOG\n\n## Unreleased\n\n- Added `sendSms` action: send an SMS immediately via Bland `POST /v1/sms/send`. The agent message is optional; when omitted, the pathway configured on the agent number generates the message.\n- Added `createSmsConversation` action: seed an SMS conversation positioned at pathway state via Bland `POST /v1/sms/create` without sending a message.\n- Added optional timeout fields to `sendSms` (`time_out`, `timeout_message`, `warning_time`, `warning_message`): per-conversation overrides for Bland's silence-timeout flow.\n- Added `completedBlandText` webhook: triggered when a Bland SMS conversation ends. Maps conversation data (status, reason, transcript, pathway variables) to data points and resolves the patient via the `awell_patient_id` echoed back in metadata.\n"
+    "readme": "---\ntitle: Bland.ai\ndescription: To do\n---\n\n# Bland.ai\n\nWith Bland.ai you can build, test, and deploy AI phone calling agents. \n\n## Extension settings\n\nTo set up this extension, you will need to provide an API key for Bland.\n\nOptionally, add the **Webhook signing secret** to have Awell verify that webhooks really come from Bland. Create it in the Bland dev portal under Account Settings, Keys tab, \"Replace Secret\" (it is shown only once). Bland then signs each webhook with an HMAC-SHA256 of the body using the secret and sends the hex digest in the `X-Webhook-Signature` header. Awell recomputes it and rejects a webhook with no signature or a wrong one with a `401`. When the setting is empty, webhooks are not verified.\n\nThe signature proves who sent a webhook, not when: Bland's documentation describes no timestamp, so a captured request could be sent again. See [Bland's webhook signing guide](https://docs.bland.ai/tutorials/webhook-signing).\n\n## Actions\n\n### Send call (with Pathway)\n\nInitiates an AI phone call using a simple prompt or a conversational pathway agent built on the Bland platform. This action is asynchronous—it triggers a call request in Bland, which queues the call. Note that the action only confirms that Bland has received the request; it does not wait for the call to complete or handle any callbacks from Bland.\n\nAwell lets you specify both the data you want to send to Bland and the structured data you’d like to receive in return. This is achieved by defining the request data for outgoing information and an analysis schema for the structured data you’ll get back.\n\n#### Request data\n\nAny JSON you put in here will be visible to the AI agent during the call - and can also be referenced with Prompt Variables.\n\nFor example, let’s say in the action you want to programmatically set the name of the person you’re calling. You could set request data to:\n\n```json\n{\n    \"name\": \"John Doe\",\n}\n```\n\n[Also see Bland documentation.](https://docs.bland.ai/api-v1/post/calls)\n\n#### Analysis schema\n\nDefine a JSON schema for how you want to get information about the call - information like email addresses, names, appointment times or any other type of custom data.\n\nFor example, if you wanted to retrieve this information from the call:\n\n```json\n{\n    \"email_address\": \"email\",\n    \"first_name\": \"string\",\n    \"last_name\": \"string\",\n    \"wants_to_book_appointment\": \"boolean\",\n    \"appointment_time\": \"YYYY-MM-DD HH:MM:SS\"\n}\n```\n\nWhen retrieving the call details, Bland will return data about the call in the following format:\n\n```json\n{\n  \"analysis\": {\n    \"email_address\": \"johndoe@gmail.com\",\n    \"first_name\": \"John\",\n    \"last_name\": \"Doe\",\n    \"wants_to_book_appointment\": true,\n    \"appointment_time\": \"2024-01-01 12:00:00\"\n  }\n}\n```\n\n[Also see Bland documentation.](https://docs.bland.ai/api-v1/post/calls)\n\n### Get call details\n\nRetrieve the details of a call based on the provider call ID.",
+    "changelog": "# CHANGELOG\n\n## Unreleased\n\n- Added the optional **Webhook signing secret** setting. When set, the `callCompleted` and `completedBlandText` webhooks verify Bland's `X-Webhook-Signature` header (an HMAC-SHA256 of the body, hex-encoded) and reject a request with no signature or a wrong one with a `401`. When empty, nothing changes: webhooks are not verified, as before.\n- Added `sendSms` action: send an SMS immediately via Bland `POST /v1/sms/send`. The agent message is optional; when omitted, the pathway configured on the agent number generates the message.\n- Added `createSmsConversation` action: seed an SMS conversation positioned at pathway state via Bland `POST /v1/sms/create` without sending a message.\n- Added optional timeout fields to `sendSms` (`time_out`, `timeout_message`, `warning_time`, `warning_message`): per-conversation overrides for Bland's silence-timeout flow.\n- Added `completedBlandText` webhook: triggered when a Bland SMS conversation ends. Maps conversation data (status, reason, transcript, pathway variables) to data points and resolves the patient via the `awell_patient_id` echoed back in metadata.\n"
   },
   "braze": {
     "readme": "---\ntitle: Braze\ndescription: Braze is a customer engagement platform that helps you communicate with your patients.\n---\n\n# Braze\n\nBraze is a comprehensive customer engagement platform that specializes in helping businesses connect with their users through personalized messaging channels.\n\n## Extension settings\n\nAn api key and the REST Endpoint URL are needed to be provided in order for the extension to authenticate with Braze's API. \n\nAn app ID can also be specified via the extension settings or the action field. Actions requiring an app ID to be provided will throw an error if no app ID is provided via the extension settings or the action field. If both are provided, the app ID from the action field will be used.\n\nList of URLs can be found [here](https://www.braze.com/docs/api/basics/#endpoints) - make sure it's the REST Endpoint URL. Documentation on API keys can be found [here](https://www.braze.com/docs/api/basics/#about-rest-api-keys).\n\n## Supported Actins\n\n### Send SMS\n\nSend an immediate SMS message to a specified user\n\nRequired permissions: `messages.send`\n\n### Schedule SMS\n\nSchedule an SMS message to be sent at a specific time\n\nRequired permissions: `messages.schedule.create`\n\n### Send Email\n\nSend an immediate email to a specified user\n\nRequired permissions: `messages.send`\n\n### Schedule Email\n\nSchedule an email to be sent at a specific time\n\nRequired permissions: `messages.schedule.create`\n\n### Send Email Using Template\n\nSend an email using a pre-defined Braze template\n\nRequired permissions: `messages.send`\n\n### Send campaign\n\nSend a campaign message.\n\nRequired permissions: `campaigns.trigger.send`\n",
@@ -160,8 +160,8 @@
     "changelog": "# MessageBird changelog"
   },
   "metriport": {
-    "readme": "---\ntitle: Metriport\ndescription: Metriport is Plaid for healthcare data.\n---\n# Metriport\n\nMetriport is Plaid for healthcare data. We help digital health companies access and manage patient health and medical data, through an open-source and universal API.\n\nThrough a single integration, our API enables modern health companies to get the comprehensive patient data they need from both HIEs and EHRs, as well as popular wearable devices.\n\nAs a developer-first interoperability solution, Metriport is powering the next wave of innovative companies, accelerating a revolution in digital health.\n\nTo learn more visit [https://www.metriport.com/](https://www.metriport.com/)\n# Extension settings\n\nIn order to set up this extension, **you will need to provide a Metriport API key**. You can obtain an API key via the Metriport dashboard by selecting the `Developers tab`. To learn more on how to get started with Metriport visit our [quick start docs](https://docs.metriport.com/medical-api/getting-started/quickstart) for our Medical API. Also, to better understand how our API keys work check out the [API Keys section](https://docs.metriport.com/home/api-info/api-keys) of our docs as well.\n\n# Ingestion\n\n## Metriport ADT notifications (`metriportAdt`)\n\nAn ingestion endpoint for Metriport's [real-time patient notifications](https://docs.metriport.com/medical-api/handling-data/realtime-patient-notifications). Point the webhook URL in the Metriport dashboard at it. Request verification (Metriport's HMAC-SHA256 `x-metriport-signature`, with the verification ping answered by `pong`) is implemented but switched off for the pre-release; it will be enabled, and the **Webhook Key** setting required, before general availability.\n\nHandled notification types are `patient.admit`, `patient.transfer`, `patient.discharge` and `patient.discharge-summary`. For each, the FHIR bundle behind the pre-signed `payload.url` is downloaded and the patient is resolved on `payload.externalId` (the id you gave Metriport when creating the patient, i.e. your own MRN). The endpoint saves one encounter keyed on the visit number (the patient itself is created by that resolution; demographics are not written yet), so all four notifications about one visit update the same encounter (`in-progress` until the discharge, `finished` after it, with the last transfer destination as its location). Any other notification type is acknowledged and produces nothing.\n\nEvents published, for care flows to trigger on: `patient.admitted`, `patient.transferred`, `patient.discharged` and `discharge.summary-received` (on a discharge summary). Every handled notification also publishes `fhir.bundle-received`, which FHIR data movement listens for; it carries no clinical data, the bundle is looked up by ingestion id.\n\n# Custom Actions\n\n**GENERAL NOTE: Make sure to create Organizations and Facilities in Metriport before using this extension. A Patient must be associated with a Facility by providing the facilityId when stated in the actions.**\n\n## Create Patient\n\nCreates a Patient in Metriport for the specified Facility where the Patient is receiving care. The Patient is not enrolled in real-time monitoring; use **Enroll in Monitoring** for that.\n\nVisit [endpoint docs](https://docs.metriport.com/medical-api/api-reference/patient/create-patient) for more info.\n\n## Enroll in Monitoring\n\nCreates a Patient in Metriport and enrolls them in real-time monitoring in one step. It takes the same Patient details as **Create Patient**, but instead of a Facility ID it takes a **Cohort Name**. By convention a Cohort and the Facility its Patients receive care at share the same name, so the action looks both up by that name: the Patient is created in the matching Facility and added to the matching Cohort.\n\nNames are matched case-insensitively, ignoring surrounding whitespace, and must identify exactly one Cohort and exactly one Facility. Both lists are cached in memory for 24 hours; a name that is not in the cached list triggers an early refresh (at most once a minute) before the action fails, so a Cohort or Facility created recently is still found.\n\nNote that enrolling a Patient in real-time monitoring has downstream consequences: once you start receiving updates about the Patient, you are expected to contribute data back to Metriport.\n\nVisit the endpoint docs for [create patient](https://docs.metriport.com/medical-api/api-reference/patient/create-patient), [list facilities](https://docs.metriport.com/medical-api/api-reference/facility/list-facilities) and [list cohorts](https://docs.metriport.com/medical-api/api-reference/cohort/list-cohorts) for more info.\n\n## Update Patient\n\nUpdates the specified Patient.\n\nVisit [endpoint docs](https://docs.metriport.com/medical-api/api-reference/patient/update-patient) for more info.\n\n## Get Patient\n\nRetrieves the specified Patient.\n\nVisit [endpoint docs](https://docs.metriport.com/medical-api/api-reference/patient/get-patient) for more info.\n\n## Remove Patient\n\nRemoves a Patient at Metriport and at HIEs the Patient is linked to.\n\nVisit [endpoint docs](https://docs.metriport.com/medical-api/api-reference/patient/delete-patient) for more info.\n\n## List Documents\n\nLists all Documents that can be retrieved for a Patient.\n\nVisit [endpoint docs](https://docs.metriport.com/medical-api/api-reference/document/list-documents) for more info.\n\n**NOTE: It also returns the status of querying Document references across HIEs, indicating whether there is an asynchronous query in progress (status processing) or not (status completed). If the query is in progress, you will also receive the total number of Documents to be queried as well as the ones that have already been completed.**\n\n## Query Documents\n\nTriggers a Document query for the specified Patient across HIEs.\n\nVisit [endpoint docs](https://docs.metriport.com/medical-api/api-reference/document/start-document-query) for more info.\n\n**NOTE: When executed, this endpoint triggers an asynchronous Document query with HIEs and immediately returns the status of Document query, processing .**\n\n## Get Document Url\n\nGets a presigned URL for downloading the specified Document.\n\nVisit [endpoint docs](https://docs.metriport.com/medical-api/api-reference/document/get-document) for more info.\n\n**NOTE: This endpoint returns a URL which you can use to download the specified Document using the file name provided from the List Documents endpoint.**\n\n## Get Facility by Name\n\nGets the Facility with the given name, so a care flow can resolve a human-readable Facility name into the `facilityId` that the Patient and Document actions require.\n\nMetriport has no endpoint to filter Facilities by name, so this action lists all Facilities in your Organization and matches in memory. The name is matched case-insensitively and ignoring surrounding whitespace, and must match **exactly one** Facility: the action errors if no Facility matches, and also if several do, rather than guessing which one was meant.\n\nVisit [endpoint docs](https://docs.metriport.com/medical-api/api-reference/facility/list-facilities) for more info.\n\n| Field | Type | Description |\n| --- | --- | --- |\n| `facilityName` | string | The name of the Facility to look up. Matched case-insensitively, ignoring surrounding whitespace, and must match exactly one Facility in your Organization. |\n\nThe data points mirror the Facility object Metriport returns from [Get Facility](https://docs.metriport.com/medical-api/api-reference/facility/get-facility), one data point per response field:\n\n| Data point | Type | Metriport field | Description |\n| --- | --- | --- | --- |\n| `facilityId` | string | `id` | Metriport's UUID for the Facility. This is the `facilityId` the Patient and Document actions take. |\n| `facilityName` | string | `name` | The Facility name, as stored at Metriport — the canonical casing and spacing, not the name that was searched for. |\n| `npi` | string | `npi` | The Facility's National Provider Identifier. |\n| `tin` | string | `tin` | The Facility's Taxpayer Identification Number. Optional at Metriport; left unset when absent. |\n| `active` | boolean | `active` | Whether the Facility is active. Optional at Metriport; left unset when absent. |\n| `addressLine1` | string | `address.addressLine1` | Street address line 1. |\n| `addressLine2` | string | `address.addressLine2` | Street address line 2. Optional; left unset when absent. |\n| `city` | string | `address.city` | Address city. |\n| `state` | string | `address.state` | Two-letter US state or territory code. |\n| `zip` | string | `address.zip` | Address ZIP code. |\n| `country` | string | `address.country` | Address country — always `USA` at Metriport today. Left unset when absent. |\n\n## Remove Patient from Cohort\n\nRemoves the specified Patient from a cohort.\n\nVisit [endpoint docs](https://docs.metriport.com/medical-api/api-reference/cohort/remove-patients-from-cohort) for more info.\n\n## Get Webhook Bundle\n\nFetches the FHIR bundle from a Metriport webhook payload URL — e.g. the [Encounter Bundle](https://docs.metriport.com/medical-api/handling-data/patient-encounter-bundle) from an ADT notification, or a discharge summary. Pass the `bundleUrl` data point emitted by the **Realtime Update** webhook; the action downloads the bundle and returns it on the `bundle` data point.\n\nWhen the payload is a Patient Encounter Bundle, the action also rewrites it into an executable FHIR transaction and returns that on the `transactionBundle` data point, ready to hand to the Medplum **Find or create resource** action.\n\nThe Encounter's Metriport id is returned separately on the `encounterId` data point, so a later step can address the imported Encounter without re-parsing the bundle.\n\n**NOTE: Metriport pre-signed URLs are only valid for 10 minutes, so this action should run early in the care flow, shortly after the realtime update webhook fires.**\n\n| Field | Type | Description |\n| --- | --- | --- |\n| `url` | string | The pre-signed payload URL to fetch (the webhook's `bundleUrl` data point). |\n| `eventType` | string (optional) | The Metriport notification type — wire this from the realtime update webhook's `eventType` data point. Recorded on the import Provenance so admit, transfer and discharge can be told apart. |\n| `provenanceReason` | text (optional) | Free-text reason recorded on the import Provenance, describing why the data was imported. |\n\n| Data point | Type | Description |\n| --- | --- | --- |\n| `bundle` | json | The FHIR bundle fetched from the URL, exactly as Metriport sent it. |\n| `transactionBundle` | json | The same data rewritten as an executable FHIR transaction. Omitted when the payload is not a Patient Encounter Bundle. |\n| `encounterId` | string | Metriport's UUID for the Encounter in the bundle. Resolve the imported Encounter in Medplum with `Encounter?identifier=https://metriport.com/fhir/encounter\\|<encounterId>`. Omitted when the bundle carries no Encounter. |\n\n### Building the transaction bundle\n\nMetriport delivers a bundle of `type: 'collection'`, which is **not executable**. Handing it straight to Medplum does nothing useful: no entry carries `request` metadata saying what to do with it, and every internal reference points at a Metriport UUID that means nothing in Medplum. The action therefore builds a second, executable bundle rather than passing the original through.\n\nThe transformation is a pure function with no Medplum access of its own — this extension holds Metriport credentials only. That rules out reading Medplum to reconcile against what is already there, so every lookup is expressed declaratively and resolved by the server when the transaction executes.\n\n**The Patient is never written.** Awell/Medplum is the source of truth for patient demographics, so the Patient entry is dropped entirely and every reference to it becomes a conditional reference:\n\n```\nPatient?identifier=https://awellhealth.com/patients|<awell patient id>\n```\n\nOmitting the entry guarantees structurally that a Metriport ADT feed can never overwrite the patient record.\n\n**Everything else is written idempotently.** Each Metriport resource is stamped with an identifier derived from its Metriport id and written with a conditional update:\n\n```\nidentifier: { system: 'https://metriport.com/fhir/encounter', value: '<metriport id>' }\nrequest:    PUT Encounter?identifier=https://metriport.com/fhir/encounter|<metriport id>\n```\n\nA conditional update creates on zero matches and updates on one, so a redelivered notification updates in place instead of duplicating Conditions, Observations, Practitioners and Locations — and the admit and discharge notifications for one visit converge on a single Encounter. Existing identifiers are kept, so the Encounter keeps its HL7 `VN` visit number alongside ours.\n\n**References are rewritten to Metriport's own `fullUrl`s.** Metriport resolves its relationships correctly, but emits them in a form FHIR cannot match: entries carry `urn:uuid:` fullUrls while references to them are relative.\n\n```\nfullUrl:    urn:uuid:3ca5e8d2-7c84-45ab-91e7-834f8becde12\nreference:  Location/3ca5e8d2-7c84-45ab-91e7-834f8becde12\n```\n\nA transaction resolves an internal reference by matching it against `fullUrl` verbatim, and a relative reference does not match a `urn:uuid:` one — Medplum would read it as a reference to a *Medplum* Location with that id, which does not exist. Rewriting the reference to the entry's `fullUrl` closes the gap while keeping Metriport's identity. This is also why the result is a `transaction` and not a `batch`: `urn:uuid` resolution is a transaction feature.\n\n**`meta` is stripped from every resource.** Medplum's `meta.accounts` is inherited from the compartment of the Patient a resource references, but specifying `meta` at all on a create or update replaces those inherited accounts instead of adding to them. Metriport's Encounter arrives with a `meta`, so it is removed. `resource.id` is dropped too, for a separate reason: Medplum assigns identity, and the entry's `fullUrl` already carries the local identity the transaction needs.\n\n**Two entries are synthesised.** An `Organization` named *Metriport Realtime Monitoring*, created with `ifNoneExist` so an existing one is reused rather than overwritten; and a `Provenance` recording the import — what it created, when, which Metriport bundle it came from, and which ADT event triggered it (`patient.admit` → `A01`, `patient.transfer` → `A02`, `patient.discharge` → `A03`).\n\n`extensions/metriport/actions/webhookBundle/bundle/transform.test.ts` asserts the complete output for a real `patient.admit` bundle, if you want to see the whole before/after in one place.\n\n### Wiring it into a care flow\n\n1. **Realtime Update** webhook fires and emits `bundleUrl` and `eventType`.\n2. **Get Webhook Bundle** — pass `bundleUrl` to `url` and `eventType` to `eventType`. Run this early; the URL expires after 10 minutes.\n3. Medplum **Find or create resource** — pass the `transactionBundle` data point to its `resourceJson` field. No changes to that action are needed; it detects a Bundle and executes it.\n\n**PREREQUISITE: for imported resources to be tagged with the Metriport organization, the Medplum Patient must already carry it in `meta.accounts` before the notification arrives.** Resources created without a `meta` inherit their accounts from the compartment of the Patient they reference, so tagging the Patient once causes every subsequent import to inherit it automatically. Note that this only covers resources *in* the patient compartment — `Location` and `Practitioner` are shared directory resources and are intentionally created untagged, since scoping a hospital or a physician to one patient's tenant would be wrong.\n\n**NOTE: the conditional Patient reference only resolves if your Medplum Patients carry an identifier under the `https://awellhealth.com/patients` system with the Awell patient id as its value. A conditional reference that matches no Patient fails the whole transaction.**\n\n### When the transaction bundle is omitted\n\n`Get Webhook Bundle` serves several Metriport webhook types and only ADT notifications carry encounter bundles. For any payload that is not a `collection` bundle, `transactionBundle` is simply omitted and `bundle` is emitted on its own — the action still succeeds.\n\nA `collection` bundle that is missing its Patient or Encounter entry is treated differently: that is an encounter bundle which does not describe an encounter, so the action **fails** rather than silently emitting a partial result.\n\n## Store Webhook Bundle\n\nFetches the FHIR bundle from a Metriport webhook payload URL like **Get Webhook Bundle**, but stores it and returns references to it instead of the bundle. Use it when a bundle can be too large to pass between care flow steps: a discharge summary can be larger than the 5 MiB limit on messages inside Awell, which the `bundle` and `transactionBundle` data points of **Get Webhook Bundle** would then hit.\n\nIt takes the same fields as **Get Webhook Bundle**: `url`, `eventType` and `provenanceReason`.\n\n| Data point | Type | Description |\n| --- | --- | --- |\n| `bundleRef` | string | Reference to the stored bundle, exactly as Metriport sent it. |\n| `transactionBundleRef` | string | Reference to the stored executable FHIR transaction (see \"Building the transaction bundle\" above). Omitted when the payload is not a Patient Encounter Bundle. |\n| `encounterId` | string | Metriport's UUID for the Encounter in the bundle. Omitted when the bundle carries no Encounter. |\n\nA reference is opaque: pass it on, do not build or parse one. Stored bundles are named after the activity, so a retried action replaces what the failed attempt stored. The action cannot be previewed.\n\n**NOTE: Metriport pre-signed URLs are only valid for 10 minutes, so this action should run early in the care flow, shortly after the realtime update webhook fires.**\n\n### Wiring it into a care flow\n\n1. **Realtime Update** webhook fires and emits `bundleUrl` and `eventType`.\n2. **Store Webhook Bundle** — pass `bundleUrl` to `url` and `eventType` to `eventType`.\n3. Medplum **Execute stored bundle** — pass the `transactionBundleRef` data point to its `bundleRef` field.\n\n**If the Medplum bots that sync Tasks should link them to the Encounter**, map this action's `encounterId` data point to the care flow's baseline `encounter_id` data point. The bots read `encounter_id` from the baseline data points, and the mapping belongs to the action in the care flow, so a flow that moves from **Get Webhook Bundle** to this action needs it set again. `encounterId` itself is the same value in both.\n\n# Webhooks\n\n## Realtime Update\n\nAn enrollment trigger that starts a care flow when Metriport sends a [real-time patient notification](https://docs.metriport.com/medical-api/handling-data/realtime-patient-notifications).\n\nMetriport POSTs every notification type to the same endpoint. Four of them share one payload shape — a `meta` envelope plus a `payload` pointing at a pre-signed bundle URL — and this webhook enrolls a patient on all four:\n\n- `patient.admit` (HL7 ADT^A01)\n- `patient.discharge` (HL7 ADT^A03)\n- `patient.transfer` (HL7 ADT^A02)\n- `patient.discharge-summary`\n\nThe `eventType` data point carries the raw Metriport webhook type, so a care flow can branch on it. The payload's `url` is a pre-signed link to the [FHIR Encounter Bundle](https://docs.metriport.com/medical-api/handling-data/patient-encounter-bundle).\n\nThe webhook validates the request, emits the data points (including the pre-signed bundle URL on `bundleUrl`), and replies immediately — it does **not** download the bundle. Fetch the bundle later in the care flow with the **Get Webhook Bundle** action, using the `bundleUrl` data point. Because the URL expires after 10 minutes, run that action early.\n\nAny other notification type Metriport sends — `medical.document-download`, `medical.consolidated-data`, and anything added in future — is acknowledged with a `200` and does not enroll a patient. A notification whose type *is* handled but whose payload is malformed fails loudly instead, so a genuine integration problem is not mistaken for an event we chose to ignore. Metriport [verification `ping` messages](https://docs.metriport.com/medical-api/getting-started/webhooks#the-ping-message) are answered with a `200` that echoes the ping value back as `pong: <value>`.\n\n### Data points\n\n| Data point | Type | Description |\n| --- | --- | --- |\n| `eventType` | string | The Metriport webhook type: `patient.admit`, `patient.discharge`, `patient.transfer` or `patient.discharge-summary` |\n| `metriportPatientId` | string | The Metriport patient ID (also used as the patient identifier for enrollment) |\n| `externalId` | string | Your external patient ID, if provided to Metriport |\n| `when` | date | When the event occurred — the admit time on an admit event, the discharge time on a discharge event |\n| `messageId` | string | The Metriport message ID for the notification |\n| `bundleUrl` | string | Pre-signed URL to the FHIR bundle; fetch it with the **Get Webhook Bundle** action (valid for 10 minutes) |\n\n### Verifying incoming requests\n\nOptionally set the **Webhook Key** setting to the webhook key from the Metriport dashboard (Settings/Developers tab). Metriport [authenticates each webhook](https://docs.metriport.com/medical-api/getting-started/webhooks#authentication) with an HMAC-SHA256 signature of the raw request body, keyed with your webhook key and sent in the `x-metriport-signature` header. When the setting is populated, the webhook recomputes the HMAC over the raw body and rejects any request whose signature is missing or does not match (`401`). When left empty, requests are not verified.\n\n## More Info\n\nFor more information on how to integrate with Metriport please visit our [Medical API docs](https://docs.metriport.com/medical-api/getting-started/quickstart)\n",
-    "changelog": "# Metriport changelog\n\n## October 2026\n\n- Add `Store Webhook Bundle` action: fetches the FHIR bundle from a Metriport webhook payload URL like `Get Webhook Bundle`, but stores the bundle and its importable transaction rewrite and returns references to them (`bundleRef`, `transactionBundleRef`) instead of the bundles, so a bundle larger than the 5 MiB limit on messages inside Awell, such as a discharge summary, no longer blocks the care flow. Pair it with the Medplum `Execute stored bundle` action. `Get Webhook Bundle` is unchanged.\n- A bundle download is now limited to 100 MB and 60 seconds (it had neither limit), for `Get Webhook Bundle`, `Store Webhook Bundle` and the `metriportAdt` endpoint. A larger bundle now fails with a clear error instead of exhausting the memory of the pod that runs every tenant's jobs.\n\n## September 2026\n\n- Add the `metriportAdt` ingestion endpoint (`source: 'webhook'`): receives Metriport real-time notifications, handles `patient.admit`, `patient.transfer`, `patient.discharge` and `patient.discharge-summary`, downloads the FHIR bundle each points at, and saves one encounter per visit (the patient is created by identifier resolution; demographics are not written yet), so admit, transfer, discharge and the summary converge on the same encounter. Publishes `patient.admitted` / `patient.transferred` / `patient.discharged` / `discharge.summary-received` for care flows and `fhir.bundle-received` for FHIR data movement. Any other notification type is acknowledged without producing a record; HMAC-SHA256 signature verification (with the ping answered by `pong`) is implemented but switched off for the pre-release. The extension now declares `identifier.system` (`https://metriport.com`).\n- Add `Enroll in Monitoring` action: creates a Patient and enrolls them in real-time monitoring in one step. It takes the same Patient details as `Create Patient` but a **Cohort Name** instead of a Facility ID; by convention a Cohort and its Facility share a name, so both are resolved from that one input. Facility and Cohort lists are cached in memory for 24 hours per API credential, refreshing early (at most once a minute) when a name is not found.\n- **Breaking: remove the `Cohort` field from `Create Patient` and `Update Patient`.** Real-time monitoring enrollment now lives on `Enroll in Monitoring`; care flows that passed a cohort ID to `Create Patient` should switch to the new action.\n\n## August 2026\n\n- Rename the `enrollment` webhook to `realtimeUpdate`. The old name described what Awell does with the notification rather than what Metriport sends, which read confusingly next to the genuine enrolment concepts (the `Cohort` field, enrolling a patient into a care flow). Behaviour is unchanged. **Breaking: the webhook endpoint URL changes, so any webhook already configured in the Metriport dashboard must be repointed.**\n- `Date of Birth` on the `Create Patient` and `Update Patient` actions is now a date field rather than a free-text string, so care flows can map a date onto it directly instead of hand-formatting `YYYY-MM-DD`. The value is normalised to the date-only string Metriport expects, so care flows already passing `YYYY-MM-DD` are unaffected.\n\n## July 2026\n\n- Add `enrollment` webhook: an enrollment trigger for Metriport real-time patient notifications. The `eventType` data point carries the Metriport webhook type (`patient.admit` or `patient.discharge-summary`) so care flows can distinguish on it. The webhook validates and replies immediately, emitting the pre-signed FHIR bundle URL on the `bundleUrl` data point rather than downloading the bundle inline.\n- Add `Get Webhook Bundle` action: fetches the FHIR bundle from a Metriport webhook payload URL (the webhook's `bundleUrl`), for use later in the care flow.\n- Add optional `Webhook Key` setting used to verify incoming webhook requests via Metriport's HMAC-SHA256 signature (`x-metriport-signature` header), computed over the raw request body.\n"
+    "readme": "---\ntitle: Metriport\ndescription: Metriport is Plaid for healthcare data.\n---\n# Metriport\n\nMetriport is Plaid for healthcare data. We help digital health companies access and manage patient health and medical data, through an open-source and universal API.\n\nThrough a single integration, our API enables modern health companies to get the comprehensive patient data they need from both HIEs and EHRs, as well as popular wearable devices.\n\nAs a developer-first interoperability solution, Metriport is powering the next wave of innovative companies, accelerating a revolution in digital health.\n\nTo learn more visit [https://www.metriport.com/](https://www.metriport.com/)\n# Extension settings\n\nIn order to set up this extension, **you will need to provide a Metriport API key**. You can obtain an API key via the Metriport dashboard by selecting the `Developers tab`. To learn more on how to get started with Metriport visit our [quick start docs](https://docs.metriport.com/medical-api/getting-started/quickstart) for our Medical API. Also, to better understand how our API keys work check out the [API Keys section](https://docs.metriport.com/home/api-info/api-keys) of our docs as well.\n\n# Ingestion\n\n## Metriport ADT notifications (`metriportAdt`)\n\nAn ingestion endpoint for Metriport's [real-time patient notifications](https://docs.metriport.com/medical-api/handling-data/realtime-patient-notifications). Point the webhook URL in the Metriport dashboard at it. Request verification (Metriport's HMAC-SHA256 `x-metriport-signature`, with the verification ping answered by `pong`) is implemented but switched off for the pre-release; it will be enabled, and the **Webhook Key** setting required, before general availability.\n\nHandled notification types are `patient.admit`, `patient.transfer`, `patient.discharge` and `patient.discharge-summary`. For each, the FHIR bundle behind the pre-signed `payload.url` is downloaded and the patient is resolved on `payload.externalId` (the id you gave Metriport when creating the patient, i.e. your own MRN). The endpoint saves one encounter keyed on the visit number (the patient itself is created by that resolution; demographics are not written yet), so all four notifications about one visit update the same encounter (`in-progress` until the discharge, `finished` after it, with the last transfer destination as its location). Any other notification type is acknowledged and produces nothing.\n\nEvents published, for care flows to trigger on: `patient.admitted`, `patient.transferred`, `patient.discharged` and `discharge.summary-received` (on a discharge summary). Every handled notification also publishes `fhir.bundle-received`, which FHIR data movement listens for; it carries no clinical data, the bundle is looked up by ingestion id.\n\n# Custom Actions\n\n**GENERAL NOTE: Make sure to create Organizations and Facilities in Metriport before using this extension. A Patient must be associated with a Facility by providing the facilityId when stated in the actions.**\n\n## Create Patient\n\nCreates a Patient in Metriport for the specified Facility where the Patient is receiving care. The Patient is not enrolled in real-time monitoring; use **Enroll in Monitoring** for that.\n\nVisit [endpoint docs](https://docs.metriport.com/medical-api/api-reference/patient/create-patient) for more info.\n\n## Enroll in Monitoring\n\nCreates a Patient in Metriport and enrolls them in real-time monitoring in one step. It takes the same Patient details as **Create Patient**, but instead of a Facility ID it takes a **Cohort Name**. By convention a Cohort and the Facility its Patients receive care at share the same name, so the action looks both up by that name: the Patient is created in the matching Facility and added to the matching Cohort.\n\nNames are matched case-insensitively, ignoring surrounding whitespace, and must identify exactly one Cohort and exactly one Facility. Both lists are cached in memory for 24 hours; a name that is not in the cached list triggers an early refresh (at most once a minute) before the action fails, so a Cohort or Facility created recently is still found.\n\nNote that enrolling a Patient in real-time monitoring has downstream consequences: once you start receiving updates about the Patient, you are expected to contribute data back to Metriport.\n\nVisit the endpoint docs for [create patient](https://docs.metriport.com/medical-api/api-reference/patient/create-patient), [list facilities](https://docs.metriport.com/medical-api/api-reference/facility/list-facilities) and [list cohorts](https://docs.metriport.com/medical-api/api-reference/cohort/list-cohorts) for more info.\n\n## Update Patient\n\nUpdates the specified Patient.\n\nVisit [endpoint docs](https://docs.metriport.com/medical-api/api-reference/patient/update-patient) for more info.\n\n## Get Patient\n\nRetrieves the specified Patient.\n\nVisit [endpoint docs](https://docs.metriport.com/medical-api/api-reference/patient/get-patient) for more info.\n\n## Remove Patient\n\nRemoves a Patient at Metriport and at HIEs the Patient is linked to.\n\nVisit [endpoint docs](https://docs.metriport.com/medical-api/api-reference/patient/delete-patient) for more info.\n\n## List Documents\n\nLists all Documents that can be retrieved for a Patient.\n\nVisit [endpoint docs](https://docs.metriport.com/medical-api/api-reference/document/list-documents) for more info.\n\n**NOTE: It also returns the status of querying Document references across HIEs, indicating whether there is an asynchronous query in progress (status processing) or not (status completed). If the query is in progress, you will also receive the total number of Documents to be queried as well as the ones that have already been completed.**\n\n## Query Documents\n\nTriggers a Document query for the specified Patient across HIEs.\n\nVisit [endpoint docs](https://docs.metriport.com/medical-api/api-reference/document/start-document-query) for more info.\n\n**NOTE: When executed, this endpoint triggers an asynchronous Document query with HIEs and immediately returns the status of Document query, processing .**\n\n## Get Document Url\n\nGets a presigned URL for downloading the specified Document.\n\nVisit [endpoint docs](https://docs.metriport.com/medical-api/api-reference/document/get-document) for more info.\n\n**NOTE: This endpoint returns a URL which you can use to download the specified Document using the file name provided from the List Documents endpoint.**\n\n## Get Facility by Name\n\nGets the Facility with the given name, so a care flow can resolve a human-readable Facility name into the `facilityId` that the Patient and Document actions require.\n\nMetriport has no endpoint to filter Facilities by name, so this action lists all Facilities in your Organization and matches in memory. The name is matched case-insensitively and ignoring surrounding whitespace, and must match **exactly one** Facility: the action errors if no Facility matches, and also if several do, rather than guessing which one was meant.\n\nVisit [endpoint docs](https://docs.metriport.com/medical-api/api-reference/facility/list-facilities) for more info.\n\n| Field | Type | Description |\n| --- | --- | --- |\n| `facilityName` | string | The name of the Facility to look up. Matched case-insensitively, ignoring surrounding whitespace, and must match exactly one Facility in your Organization. |\n\nThe data points mirror the Facility object Metriport returns from [Get Facility](https://docs.metriport.com/medical-api/api-reference/facility/get-facility), one data point per response field:\n\n| Data point | Type | Metriport field | Description |\n| --- | --- | --- | --- |\n| `facilityId` | string | `id` | Metriport's UUID for the Facility. This is the `facilityId` the Patient and Document actions take. |\n| `facilityName` | string | `name` | The Facility name, as stored at Metriport — the canonical casing and spacing, not the name that was searched for. |\n| `npi` | string | `npi` | The Facility's National Provider Identifier. |\n| `tin` | string | `tin` | The Facility's Taxpayer Identification Number. Optional at Metriport; left unset when absent. |\n| `active` | boolean | `active` | Whether the Facility is active. Optional at Metriport; left unset when absent. |\n| `addressLine1` | string | `address.addressLine1` | Street address line 1. |\n| `addressLine2` | string | `address.addressLine2` | Street address line 2. Optional; left unset when absent. |\n| `city` | string | `address.city` | Address city. |\n| `state` | string | `address.state` | Two-letter US state or territory code. |\n| `zip` | string | `address.zip` | Address ZIP code. |\n| `country` | string | `address.country` | Address country — always `USA` at Metriport today. Left unset when absent. |\n\n## Remove Patient from Cohort\n\nRemoves the specified Patient from a cohort.\n\nVisit [endpoint docs](https://docs.metriport.com/medical-api/api-reference/cohort/remove-patients-from-cohort) for more info.\n\n## Get Webhook Bundle\n\nFetches the FHIR bundle from a Metriport webhook payload URL — e.g. the [Encounter Bundle](https://docs.metriport.com/medical-api/handling-data/patient-encounter-bundle) from an ADT notification, or a discharge summary. Pass the `bundleUrl` data point emitted by the **Realtime Update** webhook; the action downloads the bundle and returns it on the `bundle` data point.\n\nWhen the payload is a Patient Encounter Bundle, the action also rewrites it into an executable FHIR transaction and returns that on the `transactionBundle` data point, ready to hand to the Medplum **Find or create resource** action.\n\nThe Encounter's Metriport id is returned separately on the `encounterId` data point, so a later step can address the imported Encounter without re-parsing the bundle.\n\n**NOTE: Metriport pre-signed URLs are only valid for 10 minutes, so this action should run early in the care flow, shortly after the realtime update webhook fires.**\n\n| Field | Type | Description |\n| --- | --- | --- |\n| `url` | string | The pre-signed payload URL to fetch (the webhook's `bundleUrl` data point). |\n| `eventType` | string (optional) | The Metriport notification type — wire this from the realtime update webhook's `eventType` data point. Recorded on the import Provenance so admit, transfer and discharge can be told apart. |\n| `provenanceReason` | text (optional) | Free-text reason recorded on the import Provenance, describing why the data was imported. |\n\n| Data point | Type | Description |\n| --- | --- | --- |\n| `bundle` | json | The FHIR bundle fetched from the URL, exactly as Metriport sent it. |\n| `transactionBundle` | json | The same data rewritten as an executable FHIR transaction. Omitted when the payload is not a Patient Encounter Bundle. |\n| `encounterId` | string | Metriport's UUID for the Encounter in the bundle. Resolve the imported Encounter in Medplum with `Encounter?identifier=https://metriport.com/fhir/encounter\\|<encounterId>`. Omitted when the bundle carries no Encounter. |\n| `reasonForVisit` … `dischargeSummaryCoverage` | string / json | The discharge summary fields, only for a `patient.discharge-summary` bundle. See \"Discharge summary fields\" below. |\n\n### Discharge summary fields\n\nA `patient.discharge-summary` bundle is Metriport's FHIR conversion of the HIE's discharge summary document: one `Composition` plus the patient's encounter history and the clinical resources the document references. The Composition's sections carry title-only narratives, so there is no text to read off them; the content lives in the resources each section points at. Both bundle actions lift the fields a care team asks for out of those resources and return them as plain data points, so a care flow, Panels or an analytics export can use them without parsing the bundle. For any other bundle the fields are all omitted.\n\nEvery field is read relative to the encounter the Composition is about (`Composition.encounter`), **not** the first Encounter in the bundle, which is just the patient's oldest visit. Each is omitted, never empty, when the document does not carry it.\n\n| Data point | Type | Where it comes from |\n| --- | --- | --- |\n| `reasonForVisit` | string | The encounter's `reasonCode` texts, `; `-separated. |\n| `visitDiagnosis` | string | The encounter's diagnoses as `<text> (<ICD-10-CM code>)`, `; `-separated, from `Encounter.diagnosis`, else from the Conditions categorised `encounter-diagnosis` that point at the encounter. |\n| `planOfTreatment` | string | The CarePlans in the Plan of care section (LOINC `18776-5`): description, then one line per activity. |\n| `procedures` | string | The Procedures in the Procedures section (`47519-4`) as `<name> (<date>)`, `; `-separated. |\n| `procedureNote` | string | The notes those Procedures report to (`Procedure.report`), each headed by the report's name. The source files these under Results rather than in a section of their own. |\n| `dischargeDisposition` | string | `Encounter.hospitalization.dischargeDisposition` as text. |\n| `dischargeDispositionCode` | string | The same, as its code (`home`, `snf`, `rehab`, …, from `http://terminology.hl7.org/CodeSystem/discharge-disposition`). |\n| `dischargeInstructions` | string | The note in the Hospital discharge instructions section (`8653-8`), else in the Discharge instructions document section (`74213-0`). |\n| `dischargeSummaryCoverage` | json | `{ documentType, documentTypeText, sections, fields }`: the Composition's LOINC type, the section codes it carried, and which of the fields above were found. Lets coverage be measured instead of guessed. |\n\nNotes are carried as base64 `DiagnosticReport.presentedForm` attachments, `text/html` or `text/plain` depending on the source EHR. HTML is reduced to plain text (paragraphs and breaks become line breaks, tags and entities are dropped or decoded); anything that is not `text/*`, such as a PDF, yields nothing. A single field is capped at 100,000 characters, far above any note seen, purely so a pathological document cannot push the activity result over the message size limit.\n\nThis is built against the documents seen from two source EHR families, keyed on section LOINC codes because the titles differ between them (\"Plan of Treatment\" in one, \"Treatment Plan\" in the other). It targets the common pattern, not every variant: a document that files a field somewhere else simply does not yield it, and `dischargeSummaryCoverage` says so.\n\n### Building the transaction bundle\n\nMetriport delivers a bundle of `type: 'collection'`, which is **not executable**. Handing it straight to Medplum does nothing useful: no entry carries `request` metadata saying what to do with it, and every internal reference points at a Metriport UUID that means nothing in Medplum. The action therefore builds a second, executable bundle rather than passing the original through.\n\nThe transformation is a pure function with no Medplum access of its own — this extension holds Metriport credentials only. That rules out reading Medplum to reconcile against what is already there, so every lookup is expressed declaratively and resolved by the server when the transaction executes.\n\n**The Patient is never written.** Awell/Medplum is the source of truth for patient demographics, so the Patient entry is dropped entirely and every reference to it becomes a conditional reference:\n\n```\nPatient?identifier=https://awellhealth.com/patients|<awell patient id>\n```\n\nOmitting the entry guarantees structurally that a Metriport ADT feed can never overwrite the patient record.\n\n**Everything else is written idempotently.** Each Metriport resource is stamped with an identifier derived from its Metriport id and written with a conditional update:\n\n```\nidentifier: { system: 'https://metriport.com/fhir/encounter', value: '<metriport id>' }\nrequest:    PUT Encounter?identifier=https://metriport.com/fhir/encounter|<metriport id>\n```\n\nA conditional update creates on zero matches and updates on one, so a redelivered notification updates in place instead of duplicating Conditions, Observations, Practitioners and Locations — and the admit and discharge notifications for one visit converge on a single Encounter. Existing identifiers are kept, so the Encounter keeps its HL7 `VN` visit number alongside ours.\n\n**References are rewritten to Metriport's own `fullUrl`s.** Metriport resolves its relationships correctly, but emits them in a form FHIR cannot match: entries carry `urn:uuid:` fullUrls while references to them are relative.\n\n```\nfullUrl:    urn:uuid:3ca5e8d2-7c84-45ab-91e7-834f8becde12\nreference:  Location/3ca5e8d2-7c84-45ab-91e7-834f8becde12\n```\n\nA transaction resolves an internal reference by matching it against `fullUrl` verbatim, and a relative reference does not match a `urn:uuid:` one — Medplum would read it as a reference to a *Medplum* Location with that id, which does not exist. Rewriting the reference to the entry's `fullUrl` closes the gap while keeping Metriport's identity. This is also why the result is a `transaction` and not a `batch`: `urn:uuid` resolution is a transaction feature.\n\n**`meta` is stripped from every resource.** Medplum's `meta.accounts` is inherited from the compartment of the Patient a resource references, but specifying `meta` at all on a create or update replaces those inherited accounts instead of adding to them. Metriport's Encounter arrives with a `meta`, so it is removed. `resource.id` is dropped too, for a separate reason: Medplum assigns identity, and the entry's `fullUrl` already carries the local identity the transaction needs.\n\n**Two entries are synthesised.** An `Organization` named *Metriport Realtime Monitoring*, created with `ifNoneExist` so an existing one is reused rather than overwritten; and a `Provenance` recording the import — what it created, when, which Metriport bundle it came from, and which ADT event triggered it (`patient.admit` → `A01`, `patient.transfer` → `A02`, `patient.discharge` → `A03`).\n\n`extensions/metriport/actions/webhookBundle/bundle/transform.test.ts` asserts the complete output for a real `patient.admit` bundle, if you want to see the whole before/after in one place.\n\n### Wiring it into a care flow\n\n1. **Realtime Update** webhook fires and emits `bundleUrl` and `eventType`.\n2. **Get Webhook Bundle** — pass `bundleUrl` to `url` and `eventType` to `eventType`. Run this early; the URL expires after 10 minutes.\n3. Medplum **Find or create resource** — pass the `transactionBundle` data point to its `resourceJson` field. No changes to that action are needed; it detects a Bundle and executes it.\n\n**PREREQUISITE: for imported resources to be tagged with the Metriport organization, the Medplum Patient must already carry it in `meta.accounts` before the notification arrives.** Resources created without a `meta` inherit their accounts from the compartment of the Patient they reference, so tagging the Patient once causes every subsequent import to inherit it automatically. Note that this only covers resources *in* the patient compartment — `Location` and `Practitioner` are shared directory resources and are intentionally created untagged, since scoping a hospital or a physician to one patient's tenant would be wrong.\n\n**NOTE: the conditional Patient reference only resolves if your Medplum Patients carry an identifier under the `https://awellhealth.com/patients` system with the Awell patient id as its value. A conditional reference that matches no Patient fails the whole transaction.**\n\n### When the transaction bundle is omitted\n\n`Get Webhook Bundle` serves several Metriport webhook types and only ADT notifications carry encounter bundles. For any payload that is not a `collection` bundle, `transactionBundle` is simply omitted and `bundle` is emitted on its own — the action still succeeds.\n\nA `collection` bundle that is missing its Patient or Encounter entry is treated differently: that is an encounter bundle which does not describe an encounter, so the action **fails** rather than silently emitting a partial result.\n\n## Store Webhook Bundle\n\nFetches the FHIR bundle from a Metriport webhook payload URL like **Get Webhook Bundle**, but stores it and returns references to it instead of the bundle. Use it when a bundle can be too large to pass between care flow steps: a discharge summary can be larger than the 5 MiB limit on messages inside Awell, which the `bundle` and `transactionBundle` data points of **Get Webhook Bundle** would then hit.\n\nIt takes the same fields as **Get Webhook Bundle**: `url`, `eventType` and `provenanceReason`.\n\n| Data point | Type | Description |\n| --- | --- | --- |\n| `bundleRef` | string | Reference to the stored bundle, exactly as Metriport sent it. |\n| `transactionBundleRef` | string | Reference to the stored executable FHIR transaction (see \"Building the transaction bundle\" above). Omitted when the payload is not a Patient Encounter Bundle. |\n| `encounterId` | string | Metriport's UUID for the Encounter in the bundle. Omitted when the bundle carries no Encounter. |\n| `reasonForVisit` … `dischargeSummaryCoverage` | string / json | The discharge summary fields, only for a `patient.discharge-summary` bundle, exactly as **Get Webhook Bundle** returns them (see \"Discharge summary fields\" above). They are small, so they travel as plain data points even though the bundle itself is stored. |\n\nA reference is opaque: pass it on, do not build or parse one. Stored bundles are named after the activity, so a retried action replaces what the failed attempt stored. The action cannot be previewed.\n\n**NOTE: Metriport pre-signed URLs are only valid for 10 minutes, so this action should run early in the care flow, shortly after the realtime update webhook fires.**\n\n### Wiring it into a care flow\n\n1. **Realtime Update** webhook fires and emits `bundleUrl` and `eventType`.\n2. **Store Webhook Bundle** — pass `bundleUrl` to `url` and `eventType` to `eventType`.\n3. Medplum **Execute stored bundle** — pass the `transactionBundleRef` data point to its `bundleRef` field.\n\n**If the Medplum bots that sync Tasks should link them to the Encounter**, map this action's `encounterId` data point to the care flow's baseline `encounter_id` data point. The bots read `encounter_id` from the baseline data points, and the mapping belongs to the action in the care flow, so a flow that moves from **Get Webhook Bundle** to this action needs it set again. `encounterId` itself is the same value in both.\n\n# Webhooks\n\n## Realtime Update\n\nAn enrollment trigger that starts a care flow when Metriport sends a [real-time patient notification](https://docs.metriport.com/medical-api/handling-data/realtime-patient-notifications).\n\nMetriport POSTs every notification type to the same endpoint. Four of them share one payload shape — a `meta` envelope plus a `payload` pointing at a pre-signed bundle URL — and this webhook enrolls a patient on all four:\n\n- `patient.admit` (HL7 ADT^A01)\n- `patient.discharge` (HL7 ADT^A03)\n- `patient.transfer` (HL7 ADT^A02)\n- `patient.discharge-summary`\n\nThe `eventType` data point carries the raw Metriport webhook type, so a care flow can branch on it. The payload's `url` is a pre-signed link to the [FHIR Encounter Bundle](https://docs.metriport.com/medical-api/handling-data/patient-encounter-bundle).\n\nThe webhook validates the request, emits the data points (including the pre-signed bundle URL on `bundleUrl`), and replies immediately — it does **not** download the bundle. Fetch the bundle later in the care flow with the **Get Webhook Bundle** action, using the `bundleUrl` data point. Because the URL expires after 10 minutes, run that action early.\n\nAny other notification type Metriport sends — `medical.document-download`, `medical.consolidated-data`, and anything added in future — is acknowledged with a `200` and does not enroll a patient. A notification whose type *is* handled but whose payload is malformed fails loudly instead, so a genuine integration problem is not mistaken for an event we chose to ignore. Metriport [verification `ping` messages](https://docs.metriport.com/medical-api/getting-started/webhooks#the-ping-message) are answered with a `200` that echoes the ping value back as `pong: <value>`.\n\n### Data points\n\n| Data point | Type | Description |\n| --- | --- | --- |\n| `eventType` | string | The Metriport webhook type: `patient.admit`, `patient.discharge`, `patient.transfer` or `patient.discharge-summary` |\n| `metriportPatientId` | string | The Metriport patient ID (also used as the patient identifier for enrollment) |\n| `externalId` | string | Your external patient ID, if provided to Metriport |\n| `when` | date | When the event occurred — the admit time on an admit event, the discharge time on a discharge event |\n| `messageId` | string | The Metriport message ID for the notification |\n| `bundleUrl` | string | Pre-signed URL to the FHIR bundle; fetch it with the **Get Webhook Bundle** action (valid for 10 minutes) |\n\n### Verifying incoming requests\n\nOptionally set the **Webhook Key** setting to the webhook key from the Metriport dashboard (Settings/Developers tab). Metriport [authenticates each webhook](https://docs.metriport.com/medical-api/getting-started/webhooks#authentication) with an HMAC-SHA256 signature of the raw request body, keyed with your webhook key and sent in the `x-metriport-signature` header. When the setting is populated, the webhook recomputes the HMAC over the raw body and rejects any request whose signature is missing or does not match (`401`). When left empty, requests are not verified.\n\n## More Info\n\nFor more information on how to integrate with Metriport please visit our [Medical API docs](https://docs.metriport.com/medical-api/getting-started/quickstart)\n",
+    "changelog": "# Metriport changelog\n\n## October 2026\n\n- `Get Webhook Bundle` and `Store Webhook Bundle` now lift the discharge summary fields out of a `patient.discharge-summary` bundle and return them as plain data points: `reasonForVisit`, `visitDiagnosis`, `planOfTreatment`, `procedures`, `procedureNote`, `dischargeDisposition`, `dischargeDispositionCode` and `dischargeInstructions`, plus `dischargeSummaryCoverage` (json) saying which document type it was and which fields it yielded. The fields are read from the resources the Composition's sections point at, relative to the encounter the Composition is about, since the sections themselves carry title-only narratives; notes are decoded from `DiagnosticReport.presentedForm` to plain text. All are omitted for any other bundle, and each is omitted when the document lacks it. Built for the common document shapes seen from two source EHR families (see the README for the exact mapping).\n- Add `Store Webhook Bundle` action: fetches the FHIR bundle from a Metriport webhook payload URL like `Get Webhook Bundle`, but stores the bundle and its importable transaction rewrite and returns references to them (`bundleRef`, `transactionBundleRef`) instead of the bundles, so a bundle larger than the 5 MiB limit on messages inside Awell, such as a discharge summary, no longer blocks the care flow. Pair it with the Medplum `Execute stored bundle` action. `Get Webhook Bundle` is unchanged.\n- A bundle download is now limited to 100 MB and 60 seconds (it had neither limit), for `Get Webhook Bundle`, `Store Webhook Bundle` and the `metriportAdt` endpoint. A larger bundle now fails with a clear error instead of exhausting the memory of the pod that runs every tenant's jobs.\n\n## September 2026\n\n- Add the `metriportAdt` ingestion endpoint (`source: 'webhook'`): receives Metriport real-time notifications, handles `patient.admit`, `patient.transfer`, `patient.discharge` and `patient.discharge-summary`, downloads the FHIR bundle each points at, and saves one encounter per visit (the patient is created by identifier resolution; demographics are not written yet), so admit, transfer, discharge and the summary converge on the same encounter. Publishes `patient.admitted` / `patient.transferred` / `patient.discharged` / `discharge.summary-received` for care flows and `fhir.bundle-received` for FHIR data movement. Any other notification type is acknowledged without producing a record; HMAC-SHA256 signature verification (with the ping answered by `pong`) is implemented but switched off for the pre-release. The extension now declares `identifier.system` (`https://metriport.com`).\n- Add `Enroll in Monitoring` action: creates a Patient and enrolls them in real-time monitoring in one step. It takes the same Patient details as `Create Patient` but a **Cohort Name** instead of a Facility ID; by convention a Cohort and its Facility share a name, so both are resolved from that one input. Facility and Cohort lists are cached in memory for 24 hours per API credential, refreshing early (at most once a minute) when a name is not found.\n- **Breaking: remove the `Cohort` field from `Create Patient` and `Update Patient`.** Real-time monitoring enrollment now lives on `Enroll in Monitoring`; care flows that passed a cohort ID to `Create Patient` should switch to the new action.\n\n## August 2026\n\n- Rename the `enrollment` webhook to `realtimeUpdate`. The old name described what Awell does with the notification rather than what Metriport sends, which read confusingly next to the genuine enrolment concepts (the `Cohort` field, enrolling a patient into a care flow). Behaviour is unchanged. **Breaking: the webhook endpoint URL changes, so any webhook already configured in the Metriport dashboard must be repointed.**\n- `Date of Birth` on the `Create Patient` and `Update Patient` actions is now a date field rather than a free-text string, so care flows can map a date onto it directly instead of hand-formatting `YYYY-MM-DD`. The value is normalised to the date-only string Metriport expects, so care flows already passing `YYYY-MM-DD` are unaffected.\n\n## July 2026\n\n- Add `enrollment` webhook: an enrollment trigger for Metriport real-time patient notifications. The `eventType` data point carries the Metriport webhook type (`patient.admit` or `patient.discharge-summary`) so care flows can distinguish on it. The webhook validates and replies immediately, emitting the pre-signed FHIR bundle URL on the `bundleUrl` data point rather than downloading the bundle inline.\n- Add `Get Webhook Bundle` action: fetches the FHIR bundle from a Metriport webhook payload URL (the webhook's `bundleUrl`), for use later in the care flow.\n- Add optional `Webhook Key` setting used to verify incoming webhook requests via Metriport's HMAC-SHA256 signature (`x-metriport-signature` header), computed over the raw request body.\n"
   },
   "nexuzhealth": {
     "readme": "---\ntitle: nexuzhealth\ndescription: Demo extension for nexuzhealth\n---\n\nThis is an extension that can only be used for demo purposes.",

package/dist/extensions/metriport/actions/index.d.ts

@@ -666,7 +666,7 @@ export declare const actions: {
             description: string;
             required: false;
         };
-    }, "bundle" | "transactionBundle" | "encounterId">;
+    }, "reasonForVisit" | "visitDiagnosis" | "planOfTreatment" | "procedures" | "procedureNote" | "dischargeDisposition" | "dischargeDispositionCode" | "dischargeInstructions" | "dischargeSummaryCoverage" | "bundle" | "transactionBundle" | "encounterId">;
     storeWebhookBundle: import("@awell-health/extensions-core").Action<{
         url: {
             id: string;
@@ -724,7 +724,7 @@ export declare const actions: {
             description: string;
             required: false;
         };
-    }, "bundleRef" | "encounterId" | "transactionBundleRef">;
+    }, "bundleRef" | "reasonForVisit" | "visitDiagnosis" | "planOfTreatment" | "procedures" | "procedureNote" | "dischargeDisposition" | "dischargeDispositionCode" | "dischargeInstructions" | "dischargeSummaryCoverage" | "encounterId" | "transactionBundleRef">;
     removePatientFromCohort: import("@awell-health/extensions-core").Action<{
         cohortId: {
             id: string;

package/dist/extensions/metriport/actions/storeWebhookBundle/dataPoints.d.ts

@@ -1,4 +1,40 @@
 export declare const dataPoints: {
+    reasonForVisit: {
+        key: string;
+        valueType: "string";
+    };
+    visitDiagnosis: {
+        key: string;
+        valueType: "string";
+    };
+    planOfTreatment: {
+        key: string;
+        valueType: "string";
+    };
+    procedures: {
+        key: string;
+        valueType: "string";
+    };
+    procedureNote: {
+        key: string;
+        valueType: "string";
+    };
+    dischargeDisposition: {
+        key: string;
+        valueType: "string";
+    };
+    dischargeDispositionCode: {
+        key: string;
+        valueType: "string";
+    };
+    dischargeInstructions: {
+        key: string;
+        valueType: "string";
+    };
+    dischargeSummaryCoverage: {
+        key: string;
+        valueType: "json";
+    };
     /** Reference to the stored bundle, exactly as Metriport sent it. */
     bundleRef: {
         key: string;

package/dist/extensions/metriport/actions/storeWebhookBundle/dataPoints.js

@@ -1,6 +1,7 @@
 "use strict";
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.dataPoints = void 0;
+const dischargeSummary_1 = require("../webhookBundle/dischargeSummary");
 exports.dataPoints = {
     /** Reference to the stored bundle, exactly as Metriport sent it. */
     bundleRef: {
@@ -23,5 +24,11 @@ exports.dataPoints = {
         key: 'encounterId',
         valueType: 'string',
     },
+    /**
+     * The discharge summary fields, present only when the bundle is a
+     * `patient.discharge-summary` document. Unlike the bundle itself these are
+     * small, so they are returned as plain data points rather than stored.
+     */
+    ...dischargeSummary_1.dischargeSummaryDataPoints,
 };
 //# sourceMappingURL=dataPoints.js.map

package/dist/extensions/metriport/actions/storeWebhookBundle/dataPoints.js.map

@@ -1 +1 @@
-{"version":3,"file":"dataPoints.js","sourceRoot":"","sources":["../../../../../extensions/metriport/actions/storeWebhookBundle/dataPoints.ts"],"names":[],"mappings":";;;AAEa,QAAA,UAAU,GAAG;IACxB,oEAAoE;IACpE,SAAS,EAAE;QACT,GAAG,EAAE,WAAW;QAChB,SAAS,EAAE,QAAQ;KACpB;IACD;;;OAGG;IACH,oBAAoB,EAAE;QACpB,GAAG,EAAE,sBAAsB;QAC3B,SAAS,EAAE,QAAQ;KACpB;IACD;;;OAGG;IACH,WAAW,EAAE;QACX,GAAG,EAAE,aAAa;QAClB,SAAS,EAAE,QAAQ;KACpB;CAC4C,CAAA"}
+{"version":3,"file":"dataPoints.js","sourceRoot":"","sources":["../../../../../extensions/metriport/actions/storeWebhookBundle/dataPoints.ts"],"names":[],"mappings":";;;AACA,wEAA8E;AAEjE,QAAA,UAAU,GAAG;IACxB,oEAAoE;IACpE,SAAS,EAAE;QACT,GAAG,EAAE,WAAW;QAChB,SAAS,EAAE,QAAQ;KACpB;IACD;;;OAGG;IACH,oBAAoB,EAAE;QACpB,GAAG,EAAE,sBAAsB;QAC3B,SAAS,EAAE,QAAQ;KACpB;IACD;;;OAGG;IACH,WAAW,EAAE;QACX,GAAG,EAAE,aAAa;QAClB,SAAS,EAAE,QAAQ;KACpB;IACD;;;;OAIG;IACH,GAAG,6CAA0B;CACgB,CAAA"}

package/dist/extensions/metriport/actions/storeWebhookBundle/storeWebhookBundle.js

@@ -24,7 +24,7 @@ exports.storeWebhookBundle = {
             const { url, eventType, provenanceReason } = validation_1.getWebhookBundleSchema.parse(payload.fields);
             // No `log`: it would write every resource's identifiers (MRNs and the
             // like) to the logs, and a bundle can hold tens of thousands of resources.
-            const { bundle, transactionBundle, encounterId } = await (0, fetchWebhookBundle_1.fetchWebhookBundle)({
+            const { bundle, transactionBundle, encounterId, dischargeSummary } = await (0, fetchWebhookBundle_1.fetchWebhookBundle)({
                 url,
                 awellPatientId: payload.patient.id,
                 eventType,
@@ -40,6 +40,9 @@ exports.storeWebhookBundle = {
                     bundleRef,
                     ...(transactionBundleRef !== undefined ? { transactionBundleRef } : {}),
                     ...(encounterId !== undefined ? { encounterId } : {}),
+                    // The discharge summary fields are small by construction; they are
+                    // the one part of a summary that is meant to travel as data points.
+                    ...dischargeSummary,
                 },
             });
         }

package/dist/extensions/metriport/actions/storeWebhookBundle/storeWebhookBundle.js.map

@@ -1 +1 @@
-{"version":3,"file":"storeWebhookBundle.js","sourceRoot":"","sources":["../../../../../extensions/metriport/actions/storeWebhookBundle/storeWebhookBundle.ts"],"names":[],"mappings":";;;AAAA,mEAAqE;AAErE,4DAA8D;AAC9D,oDAAgD;AAChD,4EAAwE;AACxE,4DAAoE;AACpE,6CAAyC;AAE5B,QAAA,kBAAkB,GAI3B;IACF,GAAG,EAAE,oBAAoB;IACzB,QAAQ,EAAE,0BAAQ,CAAC,gBAAgB;IACnC,KAAK,EAAE,sBAAsB;IAC7B,WAAW,EACT,uXAAuX;IACzX,MAAM,EAAN,eAAM;IACN,wDAAwD;IACxD,WAAW,EAAE,KAAK;IAClB,sEAAsE;IACtE,2CAA2C;IAC3C,0BAA0B,EAAE,IAAI;IAChC,UAAU,EAAV,uBAAU;IACV,OAAO,EAAE,KAAK,EAAE,EAAE,OAAO,EAAE,UAAU,EAAE,OAAO,EAAE,OAAO,EAAE,EAAiB,EAAE;QAC1E,IAAI,CAAC;YACH,MAAM,EAAE,GAAG,EAAE,SAAS,EAAE,gBAAgB,EAAE,GAAG,mCAAsB,CAAC,KAAK,CACvE,OAAO,CAAC,MAAM,CACf,CAAA;YAED,sEAAsE;YACtE,2EAA2E;YAC3E,MAAM,EAAE,MAAM,EAAE,iBAAiB,EAAE,WAAW,EAAE,GAC9C,MAAM,IAAA,uCAAkB,EAAC;gBACvB,GAAG;gBACH,cAAc,EAAE,OAAO,CAAC,OAAO,CAAC,EAAE;gBAClC,SAAS;gBACT,MAAM,EAAE,gBAAgB;aACzB,CAAC,CAAA;YAEJ,MAAM,UAAU,GAAG,CAAC,IAAY,EAAU,EAAE,CAC1C,aAAa,OAAO,CAAC,QAAQ,CAAC,EAAE,IAAI,IAAI,OAAO,CAAA;YAEjD,MAAM,SAAS,GAAG,MAAM,OAAO,CAAC,WAAW,CAAC,GAAG,CAC7C,UAAU,CAAC,QAAQ,CAAC,EACpB,IAAI,CAAC,SAAS,CAAC,MAAM,CAAC,CACvB,CAAA;YACD,MAAM,oBAAoB,GACxB,iBAAiB,KAAK,SAAS;gBAC7B,CAAC,CAAC,SAAS;gBACX,CAAC,CAAC,MAAM,OAAO,CAAC,WAAW,CAAC,GAAG,CAC3B,UAAU,CAAC,oBAAoB,CAAC,EAChC,IAAI,CAAC,SAAS,CAAC,iBAAiB,CAAC,CAClC,CAAA;YAEP,MAAM,UAAU,CAAC;gBACf,WAAW,EAAE;oBACX,SAAS;oBACT,GAAG,CAAC,oBAAoB,KAAK,SAAS,CAAC,CAAC,CAAC,EAAE,oBAAoB,EAAE,CAAC,CAAC,CAAC,EAAE,CAAC;oBACvE,GAAG,CAAC,WAAW,KAAK,SAAS,CAAC,CAAC,CAAC,EAAE,WAAW,EAAE,CAAC,CAAC,CAAC,EAAE,CAAC;iBACtD;aACF,CAAC,CAAA;QACJ,CAAC;QAAC,OAAO,GAAG,EAAE,CAAC;YACb,MAAM,IAAA,iCAAkB,EAAC,GAAG,EAAE,OAAO,CAAC,CAAA;QACxC,CAAC;IACH,CAAC;CACF,CAAA"}
+{"version":3,"file":"storeWebhookBundle.js","sourceRoot":"","sources":["../../../../../extensions/metriport/actions/storeWebhookBundle/storeWebhookBundle.ts"],"names":[],"mappings":";;;AAAA,mEAAqE;AAErE,4DAA8D;AAC9D,oDAAgD;AAChD,4EAAwE;AACxE,4DAAoE;AACpE,6CAAyC;AAE5B,QAAA,kBAAkB,GAI3B;IACF,GAAG,EAAE,oBAAoB;IACzB,QAAQ,EAAE,0BAAQ,CAAC,gBAAgB;IACnC,KAAK,EAAE,sBAAsB;IAC7B,WAAW,EACT,uXAAuX;IACzX,MAAM,EAAN,eAAM;IACN,wDAAwD;IACxD,WAAW,EAAE,KAAK;IAClB,sEAAsE;IACtE,2CAA2C;IAC3C,0BAA0B,EAAE,IAAI;IAChC,UAAU,EAAV,uBAAU;IACV,OAAO,EAAE,KAAK,EAAE,EAAE,OAAO,EAAE,UAAU,EAAE,OAAO,EAAE,OAAO,EAAE,EAAiB,EAAE;QAC1E,IAAI,CAAC;YACH,MAAM,EAAE,GAAG,EAAE,SAAS,EAAE,gBAAgB,EAAE,GAAG,mCAAsB,CAAC,KAAK,CACvE,OAAO,CAAC,MAAM,CACf,CAAA;YAED,sEAAsE;YACtE,2EAA2E;YAC3E,MAAM,EAAE,MAAM,EAAE,iBAAiB,EAAE,WAAW,EAAE,gBAAgB,EAAE,GAChE,MAAM,IAAA,uCAAkB,EAAC;gBACvB,GAAG;gBACH,cAAc,EAAE,OAAO,CAAC,OAAO,CAAC,EAAE;gBAClC,SAAS;gBACT,MAAM,EAAE,gBAAgB;aACzB,CAAC,CAAA;YAEJ,MAAM,UAAU,GAAG,CAAC,IAAY,EAAU,EAAE,CAC1C,aAAa,OAAO,CAAC,QAAQ,CAAC,EAAE,IAAI,IAAI,OAAO,CAAA;YAEjD,MAAM,SAAS,GAAG,MAAM,OAAO,CAAC,WAAW,CAAC,GAAG,CAC7C,UAAU,CAAC,QAAQ,CAAC,EACpB,IAAI,CAAC,SAAS,CAAC,MAAM,CAAC,CACvB,CAAA;YACD,MAAM,oBAAoB,GACxB,iBAAiB,KAAK,SAAS;gBAC7B,CAAC,CAAC,SAAS;gBACX,CAAC,CAAC,MAAM,OAAO,CAAC,WAAW,CAAC,GAAG,CAC3B,UAAU,CAAC,oBAAoB,CAAC,EAChC,IAAI,CAAC,SAAS,CAAC,iBAAiB,CAAC,CAClC,CAAA;YAEP,MAAM,UAAU,CAAC;gBACf,WAAW,EAAE;oBACX,SAAS;oBACT,GAAG,CAAC,oBAAoB,KAAK,SAAS,CAAC,CAAC,CAAC,EAAE,oBAAoB,EAAE,CAAC,CAAC,CAAC,EAAE,CAAC;oBACvE,GAAG,CAAC,WAAW,KAAK,SAAS,CAAC,CAAC,CAAC,EAAE,WAAW,EAAE,CAAC,CAAC,CAAC,EAAE,CAAC;oBACrD,mEAAmE;oBACnE,oEAAoE;oBACpE,GAAG,gBAAgB;iBACpB;aACF,CAAC,CAAA;QACJ,CAAC;QAAC,OAAO,GAAG,EAAE,CAAC;YACb,MAAM,IAAA,iCAAkB,EAAC,GAAG,EAAE,OAAO,CAAC,CAAA;QACxC,CAAC;IACH,CAAC;CACF,CAAA"}