@drawbridge/drawbridge-utils 0.0.107 → 0.0.108

package/dist/connections/index.cjs

@@ -76,14 +76,49 @@ var HOOKS = Object.freeze({
     "cleanup"
   ]),
   // Receiving from the vendor.
+  //
+  // Split across TWO SERVICES, and the split is the point. `verify` and `event`
+  // and `receive` run in drawbridge-webhooks against the vendor's open
+  // connection, where the budget is whatever that vendor's timeout is —
+  // Shopify's is about five seconds, and missing it means they retry and the
+  // delivery is buffered twice. `process` runs in drawbridge-sync off the
+  // buffer, where it can take as long as it needs and retry without the vendor
+  // ever knowing.
+  //
+  // One hook spanning that seam would hide it, and the thing it hides is the
+  // one most likely to bite: slow work written on the receiving side turns
+  // into duplicate deliveries.
   inbound: Object.freeze([
-    // Prove the request came from the vendor. Signature schemes differ per
-    // vendor, which is exactly why this is a hook and not one shared function.
+    // Prove the request came from the vendor, AND return the payload it
+    // carries. One hook rather than two because for some vendors they are
+    // genuinely one operation: a JWT-bodied webhook (Kinde) cannot be decoded
+    // into anything trustworthy without verifying it first, and a decode that
+    // runs before the signature check is exactly the bug this shape prevents.
+    //
+    // So the raw bytes stop here. Everything downstream receives the payload
+    // this returned, which means nothing downstream can act on unverified
+    // data even by mistake.
+    //
+    // It is also where a request gets refused for any other reason — an event
+    // outside the allowlist, a connection in the wrong state. Anything that
+    // can reject belongs here, so the route holds no rules of its own.
     "verify",
-    // Name the event, from wherever this vendor puts it.
-    "topic",
-    // Do the work the event implies.
-    "handle"
+    // Name the event, from wherever this vendor puts it. A header for
+    // Shopify, the route itself for Twilio, a claim in the payload for a
+    // JWT-bodied vendor.
+    "event",
+    // What to buffer and what to answer RIGHT NOW, while the vendor waits.
+    // Thin by obligation. Most vendors only shape a buffer doc here; one that
+    // must reply with content (Twilio answers HELP inline with TwiML, which
+    // carriers require) returns that too.
+    "receive",
+    // Do the work the event implies. Runs in drawbridge-sync, off the buffer.
+    //
+    // DECLARED here, IMPLEMENTED there — the same split as the step handlers,
+    // and for the same reason: this half needs controllers, queues and vendor
+    // SDKs, and putting those behind a published package makes every consumer
+    // carry them. The declaration is what proves the implementation exists.
+    "process"
   ]),
   // Vendor data a campaign draws on. Named for what every store platform has,
   // not for what Shopify calls it: Shopify says discounts, Stripe says coupons
@@ -309,8 +344,9 @@ var klaviyo_default2 = {
     "catalog.prices": false,
     "catalog.products": false,
     "catalog.promotions": false,
-    "inbound.handle": false,
-    "inbound.topic": false,
+    "inbound.event": false,
+    "inbound.process": false,
+    "inbound.receive": false,
     "inbound.verify": false,
     "lifecycle.cleanup": false,
     "lifecycle.register": false,
@@ -380,8 +416,9 @@ var mailchimp_default2 = {
     "catalog.prices": false,
     "catalog.products": false,
     "catalog.promotions": false,
-    "inbound.handle": false,
-    "inbound.topic": false,
+    "inbound.event": false,
+    "inbound.process": false,
+    "inbound.receive": false,
     "inbound.verify": false,
     "lifecycle.cleanup": false,
     "lifecycle.register": false,
@@ -415,7 +452,42 @@ var shopify_default = `<svg width="500" height="500" viewBox="0 0 500 500" fill=
 <path d="M258.993 193.019L249.103 230.052C249.103 230.052 238.079 225.023 225 225.85C205.833 227.059 205.628 239.171 205.824 242.21C206.865 258.756 250.376 262.381 252.821 301.171C254.745 331.688 236.656 352.574 210.592 354.21C179.313 356.19 162.089 337.711 162.089 337.711L168.716 309.472C168.716 309.472 186.052 322.569 199.921 321.686C208.993 321.119 212.228 313.738 211.903 308.514C210.536 286.921 175.102 288.185 172.862 252.695C170.985 222.811 190.57 192.554 233.803 189.821C250.46 188.762 258.993 193.028 258.993 193.028" fill="white"/>
 </svg>`;
 
+// lib/connections/inbound.js
+var import_node_crypto2 = require("crypto");
+var verifySignature = ({ body, descriptor, headers }) => {
+  const provided = headers[descriptor.headers.signature];
+  if (!provided) {
+    throw Object.assign(new Error("Missing webhook signature"), { status: 401 });
+  }
+  const digest = (0, import_node_crypto2.createHmac)(descriptor.signature.algorithm, process.env[descriptor.signature.secret]).update(body).digest(descriptor.signature.encoding);
+  const digestBuffer = Buffer.from(digest, descriptor.signature.encoding);
+  const providedBuffer = Buffer.from(provided, descriptor.signature.encoding);
+  if (digestBuffer.length !== providedBuffer.length || !(0, import_node_crypto2.timingSafeEqual)(digestBuffer, providedBuffer)) {
+    throw Object.assign(new Error("Invalid webhook signature"), { status: 401 });
+  }
+  return JSON.parse(body.toString());
+};
+var readEventHeader = ({ descriptor, headers }) => headers[descriptor.headers.event];
+
 // lib/connections/shopify.js
+var inbound = {
+  headers: {
+    event: "x-shopify-topic",
+    id: "x-shopify-webhook-id",
+    shop: "x-shopify-shop-domain",
+    signature: "x-shopify-hmac-sha256"
+  },
+  signature: {
+    algorithm: "sha256",
+    encoding: "base64",
+    secret: "SHOPIFY_API_SECRET"
+  }
+};
+var COMPLIANCE_TOPICS = /* @__PURE__ */ new Set([
+  "customers/data_request",
+  "customers/redact",
+  "shop/redact"
+]);
 var shopify_default2 = {
   // INSTALL, not oauth. The grant is an OAuth grant, but the merchant never
   // sees a consent screen we sent them to -- they start at the App Store, and
@@ -460,30 +532,31 @@ var shopify_default2 = {
     }
   ],
   group: "ecommerce",
-  // WHERE THIS VENDOR PUTS THINGS ON AN INBOUND REQUEST. Header names are facts
-  // about someone else's product, so they belong beside the rest of the vendor
-  // rather than as string literals in a route — which is where they were, and
-  // is why a second inbound vendor meant a second route file.
-  //
-  // `signature` describes an HMAC scheme the shared verifier can run: hash the
-  // raw body with the named secret and compare, constant-time, against the
-  // header. Vendors whose scheme is not that shape — Stripe signs a timestamped
-  // payload — declare no signature block and implement inbound.verify instead.
-  // That is why verify is a hook and not config.
-  inbound: {
-    headers: {
-      id: "x-shopify-webhook-id",
-      shop: "x-shopify-shop-domain",
-      signature: "x-shopify-hmac-sha256",
-      topic: "x-shopify-topic"
+  // verify and event lean entirely on the shared HMAC helper — Shopify's scheme
+  // is exactly the shape it covers, so there is nothing vendor-specific to
+  // write for either. receive is the one hook that genuinely differs by
+  // action: /events buffers whatever arrives with the shop domain stamped on;
+  // /compliance enforces the topic allowlist above, because answering one late
+  // is a legal deadline rather than a retry.
+  hooks: {
+    "inbound.event": (args) => readEventHeader({ ...args, descriptor: inbound }),
+    "inbound.receive": ({ action, event, headers, payload }) => {
+      if (action === "compliance" && !COMPLIANCE_TOPICS.has(event)) {
+        throw Object.assign(new Error("Unrecognized compliance topic: " + event), { status: 401 });
+      }
+      return {
+        // Compliance payloads already carry shop_domain in the body — Shopify's
+        // own GDPR shape. The app-level event stream does not; that domain
+        // lives only in the header, so it is stamped on here rather than left
+        // for drawbridge-sync to reach into headers nobody hands it.
+        data: action === "compliance" ? payload : { ...payload, shop_domain: headers[inbound.headers.shop] || null },
+        provider: { id: headers[inbound.headers.id] || null }
+      };
     },
-    signature: {
-      algorithm: "sha256",
-      encoding: "base64",
-      secret: "SHOPIFY_API_SECRET"
-    }
+    "inbound.verify": (args) => verifySignature({ ...args, descriptor: inbound })
   },
   icon: shopify_default,
+  inbound,
   label: "shopify",
   // A pre-launch integration: it only surfaces once the App Store listing
   // exists and the app is fully configured. Requiring all four means it can
@@ -512,8 +585,9 @@ var shopify_default2 = {
     "catalog.prices": false,
     "catalog.products": true,
     "catalog.promotions": true,
-    "inbound.handle": true,
-    "inbound.topic": true,
+    "inbound.event": true,
+    "inbound.process": true,
+    "inbound.receive": true,
     "inbound.verify": true,
     "lifecycle.cleanup": true,
     "lifecycle.register": true,
@@ -673,8 +747,9 @@ var webhook_default = {
     "catalog.prices": false,
     "catalog.products": false,
     "catalog.promotions": false,
-    "inbound.handle": false,
-    "inbound.topic": false,
+    "inbound.event": false,
+    "inbound.process": false,
+    "inbound.receive": false,
     "inbound.verify": false,
     "lifecycle.cleanup": false,
     "lifecycle.register": false,
@@ -764,8 +839,8 @@ var build = (manifest) => {
       }
     }
   }
-  if (((_d = manifest.supports) == null ? void 0 : _d["inbound.topic"]) && !((_f = (_e = manifest.inbound) == null ? void 0 : _e.headers) == null ? void 0 : _f.topic)) {
-    throw new Error(manifest.slug + " supports inbound.topic but declares no inbound.headers.topic");
+  if (((_d = manifest.supports) == null ? void 0 : _d["inbound.event"]) && !((_f = (_e = manifest.inbound) == null ? void 0 : _e.headers) == null ? void 0 : _f.event)) {
+    throw new Error(manifest.slug + " supports inbound.event but declares no inbound.headers.event");
   }
   if (((_g = manifest.supports) == null ? void 0 : _g["inbound.verify"]) && !((_i = (_h = manifest.inbound) == null ? void 0 : _h.headers) == null ? void 0 : _i.signature)) {
     throw new Error(manifest.slug + " supports inbound.verify but declares no inbound.headers.signature");
@@ -880,7 +955,7 @@ var runHook = async (slug, name, args = {}) => {
   try {
     return { outcome: OUTCOMES.answered, result: await hook(args) };
   } catch (error) {
-    return { error: (error == null ? void 0 : error.message) || "failed", outcome: OUTCOMES.failed };
+    return { error: (error == null ? void 0 : error.message) || "failed", outcome: OUTCOMES.failed, status: (error == null ? void 0 : error.status) || null };
   }
 };
 var stepQueues = (env = {}) => Object.fromEntries(
@@ -946,7 +1021,7 @@ var projectConnection = (record) => {
 var resolveConnection = (item, data) => {
   if (!item) return item;
   return Object.fromEntries(
-    Object.entries(item).filter(([key]) => !["auth", "enabled", "fields", "inbound", "requires", "steps", "supports"].includes(key)).map(([key, value]) => [
+    Object.entries(item).filter(([key]) => !["auth", "enabled", "fields", "hooks", "inbound", "requires", "steps", "supports"].includes(key)).map(([key, value]) => [
       key,
       typeof value === "function" ? value(data) : value
     ])

package/dist/connections/index.d.cts

@@ -1,5 +1,5 @@
 export { consentUrl, exchange, pkcePair, refresh } from './oauth.cjs';
-import 'node:crypto';
+import { createHmac, timingSafeEqual } from 'node:crypto';
 
 // THE HOOK VOCABULARY. Closed, and every connection answers all of it.
 //
@@ -48,14 +48,49 @@ const HOOKS = Object.freeze({
 	]),
 
 	// Receiving from the vendor.
+	//
+	// Split across TWO SERVICES, and the split is the point. `verify` and `event`
+	// and `receive` run in drawbridge-webhooks against the vendor's open
+	// connection, where the budget is whatever that vendor's timeout is —
+	// Shopify's is about five seconds, and missing it means they retry and the
+	// delivery is buffered twice. `process` runs in drawbridge-sync off the
+	// buffer, where it can take as long as it needs and retry without the vendor
+	// ever knowing.
+	//
+	// One hook spanning that seam would hide it, and the thing it hides is the
+	// one most likely to bite: slow work written on the receiving side turns
+	// into duplicate deliveries.
 	inbound : Object.freeze([
-		// Prove the request came from the vendor. Signature schemes differ per
-		// vendor, which is exactly why this is a hook and not one shared function.
+		// Prove the request came from the vendor, AND return the payload it
+		// carries. One hook rather than two because for some vendors they are
+		// genuinely one operation: a JWT-bodied webhook (Kinde) cannot be decoded
+		// into anything trustworthy without verifying it first, and a decode that
+		// runs before the signature check is exactly the bug this shape prevents.
+		//
+		// So the raw bytes stop here. Everything downstream receives the payload
+		// this returned, which means nothing downstream can act on unverified
+		// data even by mistake.
+		//
+		// It is also where a request gets refused for any other reason — an event
+		// outside the allowlist, a connection in the wrong state. Anything that
+		// can reject belongs here, so the route holds no rules of its own.
 		'verify',
-		// Name the event, from wherever this vendor puts it.
-		'topic',
-		// Do the work the event implies.
-		'handle'
+		// Name the event, from wherever this vendor puts it. A header for
+		// Shopify, the route itself for Twilio, a claim in the payload for a
+		// JWT-bodied vendor.
+		'event',
+		// What to buffer and what to answer RIGHT NOW, while the vendor waits.
+		// Thin by obligation. Most vendors only shape a buffer doc here; one that
+		// must reply with content (Twilio answers HELP inline with TwiML, which
+		// carriers require) returns that too.
+		'receive',
+		// Do the work the event implies. Runs in drawbridge-sync, off the buffer.
+		//
+		// DECLARED here, IMPLEMENTED there — the same split as the step handlers,
+		// and for the same reason: this half needs controllers, queues and vendor
+		// SDKs, and putting those behind a published package makes every consumer
+		// carry them. The declaration is what proves the implementation exists.
+		'process'
 	]),
 
 	// Vendor data a campaign draws on. Named for what every store platform has,
@@ -261,8 +296,9 @@ var klaviyo = {
 		'catalog.prices' : false,
 		'catalog.products' : false,
 		'catalog.promotions' : false,
-		'inbound.handle' : false,
-		'inbound.topic' : false,
+		'inbound.event' : false,
+		'inbound.process' : false,
+		'inbound.receive' : false,
 		'inbound.verify' : false,
 		'lifecycle.cleanup' : false,
 		'lifecycle.register' : false,
@@ -342,8 +378,9 @@ var mailchimp = {
 		'catalog.prices' : false,
 		'catalog.products' : false,
 		'catalog.promotions' : false,
-		'inbound.handle' : false,
-		'inbound.topic' : false,
+		'inbound.event' : false,
+		'inbound.process' : false,
+		'inbound.receive' : false,
 		'inbound.verify' : false,
 		'lifecycle.cleanup' : false,
 		'lifecycle.register' : false,
@@ -382,6 +419,96 @@ var icon$1 = `<svg width="500" height="500" viewBox="0 0 500 500" fill="none" xm
 <path d="M258.993 193.019L249.103 230.052C249.103 230.052 238.079 225.023 225 225.85C205.833 227.059 205.628 239.171 205.824 242.21C206.865 258.756 250.376 262.381 252.821 301.171C254.745 331.688 236.656 352.574 210.592 354.21C179.313 356.19 162.089 337.711 162.089 337.711L168.716 309.472C168.716 309.472 186.052 322.569 199.921 321.686C208.993 321.119 212.228 313.738 211.903 308.514C210.536 286.921 175.102 288.185 172.862 252.695C170.985 222.811 190.57 192.554 233.803 189.821C250.46 188.762 258.993 193.028 258.993 193.028" fill="white"/>
 </svg>`;
 
+// THE SHARED HALF OF inbound.verify.
+//
+// A vendor whose scheme is "hash the raw body with a shared secret and compare,
+// constant-time, against a header" declares that shape as `inbound.signature`
+// data on its manifest (algorithm, encoding, the env var naming the secret) and
+// wires this straight in as its hook — Shopify does exactly that.
+//
+// A vendor whose scheme is not that shape — Twilio signs the REGISTERED URL
+// rather than the body, a JWT-bodied vendor verifies against a JWKS — writes its
+// own inbound.verify instead. That is why verify is a hook and not config: this
+// file covers the common case, not the contract.
+const verifySignature = ({ body, descriptor, headers }) => {
+
+	const provided = headers[ descriptor.headers.signature ];
+
+	if( ! provided ){
+
+		throw Object.assign( new Error( 'Missing webhook signature' ), { status : 401 });
+
+	}
+
+	const digest = createHmac( descriptor.signature.algorithm, process.env[ descriptor.signature.secret ] )
+		.update( body )
+		.digest( descriptor.signature.encoding );
+
+	// Buffers of different lengths crash timingSafeEqual rather than compare
+	// false — decided here, before the length itself becomes a timing signal.
+	const digestBuffer = Buffer.from( digest, descriptor.signature.encoding );
+	const providedBuffer = Buffer.from( provided, descriptor.signature.encoding );
+
+	if(
+		digestBuffer.length !== providedBuffer.length ||
+		! timingSafeEqual( digestBuffer, providedBuffer )
+	){
+
+		throw Object.assign( new Error( 'Invalid webhook signature' ), { status : 401 });
+
+	}
+
+	// The proof and the parse happen together on purpose. Nothing downstream of
+	// inbound.verify ever sees the raw bytes, which is what makes acting on
+	// unverified data impossible rather than merely discouraged.
+	return JSON.parse( body.toString() );
+
+};
+
+// THE SHARED HALF OF inbound.event, for a vendor that puts it in a header.
+const readEventHeader = ({ descriptor, headers }) => headers[ descriptor.headers.event ];
+
+// WHERE THIS VENDOR PUTS THINGS ON AN INBOUND REQUEST. Header names are facts
+// about someone else's product, so they belong beside the rest of the vendor
+// rather than as string literals in a route — which is where they were, and is
+// why a second inbound vendor meant a second route file.
+//
+// Pulled out to a const (rather than written inline under `inbound:` below) so
+// the hooks further down can reference the SAME object the manifest publishes,
+// instead of a second copy that could drift from it.
+//
+// `signature` describes an HMAC scheme the shared verifier can run: hash the
+// raw body with the named secret and compare, constant-time, against the
+// header. Vendors whose scheme is not that shape declare no signature block and
+// implement inbound.verify themselves — a JWT-bodied vendor (Kinde) verifies
+// against a JWKS and returns the decoded claims, and Twilio signs the
+// registered URL rather than the body. That is why verify is a hook and not
+// config.
+const inbound = {
+	headers : {
+		event : 'x-shopify-topic',
+		id : 'x-shopify-webhook-id',
+		shop : 'x-shopify-shop-domain',
+		signature : 'x-shopify-hmac-sha256'
+	},
+	signature : {
+		algorithm : 'sha256',
+		encoding : 'base64',
+		secret : 'SHOPIFY_API_SECRET'
+	}
+};
+
+// Shopify's own GDPR deadline, not ours — these three are the only topics
+// registered under `compliance_topics` in the app toml, and Shopify expects an
+// answer even for a shop that has already uninstalled. Anything else on this
+// action is refused here rather than buffered, the same way a bad signature is:
+// it is a request that should never have arrived.
+const COMPLIANCE_TOPICS = new Set([
+	'customers/data_request',
+	'customers/redact',
+	'shop/redact'
+]);
+
 // Shopify — installed from the App Store, never connected with keys.
 var shopify = {
 	// INSTALL, not oauth. The grant is an OAuth grant, but the merchant never
@@ -427,30 +554,38 @@ var shopify = {
 		}
 	],
 	group : 'ecommerce',
-	// WHERE THIS VENDOR PUTS THINGS ON AN INBOUND REQUEST. Header names are facts
-	// about someone else's product, so they belong beside the rest of the vendor
-	// rather than as string literals in a route — which is where they were, and
-	// is why a second inbound vendor meant a second route file.
-	//
-	// `signature` describes an HMAC scheme the shared verifier can run: hash the
-	// raw body with the named secret and compare, constant-time, against the
-	// header. Vendors whose scheme is not that shape — Stripe signs a timestamped
-	// payload — declare no signature block and implement inbound.verify instead.
-	// That is why verify is a hook and not config.
-	inbound : {
-		headers : {
-			id : 'x-shopify-webhook-id',
-			shop : 'x-shopify-shop-domain',
-			signature : 'x-shopify-hmac-sha256',
-			topic : 'x-shopify-topic'
+	// verify and event lean entirely on the shared HMAC helper — Shopify's scheme
+	// is exactly the shape it covers, so there is nothing vendor-specific to
+	// write for either. receive is the one hook that genuinely differs by
+	// action: /events buffers whatever arrives with the shop domain stamped on;
+	// /compliance enforces the topic allowlist above, because answering one late
+	// is a legal deadline rather than a retry.
+	hooks : {
+		'inbound.event' : ( args ) => readEventHeader({ ...args, descriptor : inbound }),
+		'inbound.receive' : ({ action, event, headers, payload }) => {
+
+			if( action === 'compliance' && ! COMPLIANCE_TOPICS.has( event ) ){
+
+				throw Object.assign( new Error( 'Unrecognized compliance topic: ' + event ), { status : 401 });
+
+			}
+
+			return {
+				// Compliance payloads already carry shop_domain in the body — Shopify's
+				// own GDPR shape. The app-level event stream does not; that domain
+				// lives only in the header, so it is stamped on here rather than left
+				// for drawbridge-sync to reach into headers nobody hands it.
+				data : action === 'compliance'
+					? payload
+					: { ...payload, shop_domain : headers[ inbound.headers.shop ] || null },
+				provider : { id : headers[ inbound.headers.id ] || null }
+			};
+
 		},
-		signature : {
-			algorithm : 'sha256',
-			encoding : 'base64',
-			secret : 'SHOPIFY_API_SECRET'
-		}
+		'inbound.verify' : ( args ) => verifySignature({ ...args, descriptor : inbound })
 	},
 	icon: icon$1,
+	inbound,
 	label : 'shopify',
 	// A pre-launch integration: it only surfaces once the App Store listing
 	// exists and the app is fully configured. Requiring all four means it can
@@ -479,8 +614,9 @@ var shopify = {
 		'catalog.prices' : false,
 		'catalog.products' : true,
 		'catalog.promotions' : true,
-		'inbound.handle' : true,
-		'inbound.topic' : true,
+		'inbound.event' : true,
+		'inbound.process' : true,
+		'inbound.receive' : true,
 		'inbound.verify' : true,
 		'lifecycle.cleanup' : true,
 		'lifecycle.register' : true,
@@ -647,8 +783,9 @@ var webhook = {
 		'catalog.prices' : false,
 		'catalog.products' : false,
 		'catalog.promotions' : false,
-		'inbound.handle' : false,
-		'inbound.topic' : false,
+		'inbound.event' : false,
+		'inbound.process' : false,
+		'inbound.receive' : false,
 		'inbound.verify' : false,
 		'lifecycle.cleanup' : false,
 		'lifecycle.register' : false,
@@ -835,9 +972,9 @@ const build = ( manifest ) => {
 	// A vendor that receives from the outside must say where it puts the event
 	// name. Without it the receiver has nothing to dispatch on, and the failure
 	// is a request accepted and dropped rather than an error.
-	if( manifest.supports?.[ 'inbound.topic' ] && ! manifest.inbound?.headers?.topic ){
+	if( manifest.supports?.[ 'inbound.event' ] && ! manifest.inbound?.headers?.event ){
 
-		throw new Error( manifest.slug + ' supports inbound.topic but declares no inbound.headers.topic' );
+		throw new Error( manifest.slug + ' supports inbound.event but declares no inbound.headers.event' );
 
 	}
 
@@ -1090,7 +1227,11 @@ const runHook = async ( slug, name, args = {} ) => {
 
 	} catch ( error ) {
 
-		return { error : error?.message || 'failed', outcome : OUTCOMES.failed };
+		// A hook throws to REJECT, not just to report failure — inbound.verify
+		// on a forged signature, inbound.receive on a topic outside the vendor's
+		// declared set. The status rides along so a caller can answer 401 rather
+		// than always folding a hook's own rejection into a 500.
+		return { error : error?.message || 'failed', outcome : OUTCOMES.failed, status : error?.status || null };
 
 	}
 
@@ -1216,7 +1357,7 @@ const resolveConnection = ( item, data ) => {
 
 	return Object.fromEntries(
 		Object.entries( item )
-			.filter( ( [ key ] ) => ! [ 'auth', 'enabled', 'fields', 'inbound', 'requires', 'steps', 'supports' ].includes( key ) )
+			.filter( ( [ key ] ) => ! [ 'auth', 'enabled', 'fields', 'hooks', 'inbound', 'requires', 'steps', 'supports' ].includes( key ) )
 			.map( ( [ key, value ] ) => [
 				key,
 				( typeof value === 'function' ? value( data ) : value )

package/dist/connections/index.d.ts

@@ -1,5 +1,5 @@
 export { consentUrl, exchange, pkcePair, refresh } from './oauth.js';
-import 'node:crypto';
+import { createHmac, timingSafeEqual } from 'node:crypto';
 
 // THE HOOK VOCABULARY. Closed, and every connection answers all of it.
 //
@@ -48,14 +48,49 @@ const HOOKS = Object.freeze({
 	]),
 
 	// Receiving from the vendor.
+	//
+	// Split across TWO SERVICES, and the split is the point. `verify` and `event`
+	// and `receive` run in drawbridge-webhooks against the vendor's open
+	// connection, where the budget is whatever that vendor's timeout is —
+	// Shopify's is about five seconds, and missing it means they retry and the
+	// delivery is buffered twice. `process` runs in drawbridge-sync off the
+	// buffer, where it can take as long as it needs and retry without the vendor
+	// ever knowing.
+	//
+	// One hook spanning that seam would hide it, and the thing it hides is the
+	// one most likely to bite: slow work written on the receiving side turns
+	// into duplicate deliveries.
 	inbound : Object.freeze([
-		// Prove the request came from the vendor. Signature schemes differ per
-		// vendor, which is exactly why this is a hook and not one shared function.
+		// Prove the request came from the vendor, AND return the payload it
+		// carries. One hook rather than two because for some vendors they are
+		// genuinely one operation: a JWT-bodied webhook (Kinde) cannot be decoded
+		// into anything trustworthy without verifying it first, and a decode that
+		// runs before the signature check is exactly the bug this shape prevents.
+		//
+		// So the raw bytes stop here. Everything downstream receives the payload
+		// this returned, which means nothing downstream can act on unverified
+		// data even by mistake.
+		//
+		// It is also where a request gets refused for any other reason — an event
+		// outside the allowlist, a connection in the wrong state. Anything that
+		// can reject belongs here, so the route holds no rules of its own.
 		'verify',
-		// Name the event, from wherever this vendor puts it.
-		'topic',
-		// Do the work the event implies.
-		'handle'
+		// Name the event, from wherever this vendor puts it. A header for
+		// Shopify, the route itself for Twilio, a claim in the payload for a
+		// JWT-bodied vendor.
+		'event',
+		// What to buffer and what to answer RIGHT NOW, while the vendor waits.
+		// Thin by obligation. Most vendors only shape a buffer doc here; one that
+		// must reply with content (Twilio answers HELP inline with TwiML, which
+		// carriers require) returns that too.
+		'receive',
+		// Do the work the event implies. Runs in drawbridge-sync, off the buffer.
+		//
+		// DECLARED here, IMPLEMENTED there — the same split as the step handlers,
+		// and for the same reason: this half needs controllers, queues and vendor
+		// SDKs, and putting those behind a published package makes every consumer
+		// carry them. The declaration is what proves the implementation exists.
+		'process'
 	]),
 
 	// Vendor data a campaign draws on. Named for what every store platform has,
@@ -261,8 +296,9 @@ var klaviyo = {
 		'catalog.prices' : false,
 		'catalog.products' : false,
 		'catalog.promotions' : false,
-		'inbound.handle' : false,
-		'inbound.topic' : false,
+		'inbound.event' : false,
+		'inbound.process' : false,
+		'inbound.receive' : false,
 		'inbound.verify' : false,
 		'lifecycle.cleanup' : false,
 		'lifecycle.register' : false,
@@ -342,8 +378,9 @@ var mailchimp = {
 		'catalog.prices' : false,
 		'catalog.products' : false,
 		'catalog.promotions' : false,
-		'inbound.handle' : false,
-		'inbound.topic' : false,
+		'inbound.event' : false,
+		'inbound.process' : false,
+		'inbound.receive' : false,
 		'inbound.verify' : false,
 		'lifecycle.cleanup' : false,
 		'lifecycle.register' : false,
@@ -382,6 +419,96 @@ var icon$1 = `<svg width="500" height="500" viewBox="0 0 500 500" fill="none" xm
 <path d="M258.993 193.019L249.103 230.052C249.103 230.052 238.079 225.023 225 225.85C205.833 227.059 205.628 239.171 205.824 242.21C206.865 258.756 250.376 262.381 252.821 301.171C254.745 331.688 236.656 352.574 210.592 354.21C179.313 356.19 162.089 337.711 162.089 337.711L168.716 309.472C168.716 309.472 186.052 322.569 199.921 321.686C208.993 321.119 212.228 313.738 211.903 308.514C210.536 286.921 175.102 288.185 172.862 252.695C170.985 222.811 190.57 192.554 233.803 189.821C250.46 188.762 258.993 193.028 258.993 193.028" fill="white"/>
 </svg>`;
 
+// THE SHARED HALF OF inbound.verify.
+//
+// A vendor whose scheme is "hash the raw body with a shared secret and compare,
+// constant-time, against a header" declares that shape as `inbound.signature`
+// data on its manifest (algorithm, encoding, the env var naming the secret) and
+// wires this straight in as its hook — Shopify does exactly that.
+//
+// A vendor whose scheme is not that shape — Twilio signs the REGISTERED URL
+// rather than the body, a JWT-bodied vendor verifies against a JWKS — writes its
+// own inbound.verify instead. That is why verify is a hook and not config: this
+// file covers the common case, not the contract.
+const verifySignature = ({ body, descriptor, headers }) => {
+
+	const provided = headers[ descriptor.headers.signature ];
+
+	if( ! provided ){
+
+		throw Object.assign( new Error( 'Missing webhook signature' ), { status : 401 });
+
+	}
+
+	const digest = createHmac( descriptor.signature.algorithm, process.env[ descriptor.signature.secret ] )
+		.update( body )
+		.digest( descriptor.signature.encoding );
+
+	// Buffers of different lengths crash timingSafeEqual rather than compare
+	// false — decided here, before the length itself becomes a timing signal.
+	const digestBuffer = Buffer.from( digest, descriptor.signature.encoding );
+	const providedBuffer = Buffer.from( provided, descriptor.signature.encoding );
+
+	if(
+		digestBuffer.length !== providedBuffer.length ||
+		! timingSafeEqual( digestBuffer, providedBuffer )
+	){
+
+		throw Object.assign( new Error( 'Invalid webhook signature' ), { status : 401 });
+
+	}
+
+	// The proof and the parse happen together on purpose. Nothing downstream of
+	// inbound.verify ever sees the raw bytes, which is what makes acting on
+	// unverified data impossible rather than merely discouraged.
+	return JSON.parse( body.toString() );
+
+};
+
+// THE SHARED HALF OF inbound.event, for a vendor that puts it in a header.
+const readEventHeader = ({ descriptor, headers }) => headers[ descriptor.headers.event ];
+
+// WHERE THIS VENDOR PUTS THINGS ON AN INBOUND REQUEST. Header names are facts
+// about someone else's product, so they belong beside the rest of the vendor
+// rather than as string literals in a route — which is where they were, and is
+// why a second inbound vendor meant a second route file.
+//
+// Pulled out to a const (rather than written inline under `inbound:` below) so
+// the hooks further down can reference the SAME object the manifest publishes,
+// instead of a second copy that could drift from it.
+//
+// `signature` describes an HMAC scheme the shared verifier can run: hash the
+// raw body with the named secret and compare, constant-time, against the
+// header. Vendors whose scheme is not that shape declare no signature block and
+// implement inbound.verify themselves — a JWT-bodied vendor (Kinde) verifies
+// against a JWKS and returns the decoded claims, and Twilio signs the
+// registered URL rather than the body. That is why verify is a hook and not
+// config.
+const inbound = {
+	headers : {
+		event : 'x-shopify-topic',
+		id : 'x-shopify-webhook-id',
+		shop : 'x-shopify-shop-domain',
+		signature : 'x-shopify-hmac-sha256'
+	},
+	signature : {
+		algorithm : 'sha256',
+		encoding : 'base64',
+		secret : 'SHOPIFY_API_SECRET'
+	}
+};
+
+// Shopify's own GDPR deadline, not ours — these three are the only topics
+// registered under `compliance_topics` in the app toml, and Shopify expects an
+// answer even for a shop that has already uninstalled. Anything else on this
+// action is refused here rather than buffered, the same way a bad signature is:
+// it is a request that should never have arrived.
+const COMPLIANCE_TOPICS = new Set([
+	'customers/data_request',
+	'customers/redact',
+	'shop/redact'
+]);
+
 // Shopify — installed from the App Store, never connected with keys.
 var shopify = {
 	// INSTALL, not oauth. The grant is an OAuth grant, but the merchant never
@@ -427,30 +554,38 @@ var shopify = {
 		}
 	],
 	group : 'ecommerce',
-	// WHERE THIS VENDOR PUTS THINGS ON AN INBOUND REQUEST. Header names are facts
-	// about someone else's product, so they belong beside the rest of the vendor
-	// rather than as string literals in a route — which is where they were, and
-	// is why a second inbound vendor meant a second route file.
-	//
-	// `signature` describes an HMAC scheme the shared verifier can run: hash the
-	// raw body with the named secret and compare, constant-time, against the
-	// header. Vendors whose scheme is not that shape — Stripe signs a timestamped
-	// payload — declare no signature block and implement inbound.verify instead.
-	// That is why verify is a hook and not config.
-	inbound : {
-		headers : {
-			id : 'x-shopify-webhook-id',
-			shop : 'x-shopify-shop-domain',
-			signature : 'x-shopify-hmac-sha256',
-			topic : 'x-shopify-topic'
+	// verify and event lean entirely on the shared HMAC helper — Shopify's scheme
+	// is exactly the shape it covers, so there is nothing vendor-specific to
+	// write for either. receive is the one hook that genuinely differs by
+	// action: /events buffers whatever arrives with the shop domain stamped on;
+	// /compliance enforces the topic allowlist above, because answering one late
+	// is a legal deadline rather than a retry.
+	hooks : {
+		'inbound.event' : ( args ) => readEventHeader({ ...args, descriptor : inbound }),
+		'inbound.receive' : ({ action, event, headers, payload }) => {
+
+			if( action === 'compliance' && ! COMPLIANCE_TOPICS.has( event ) ){
+
+				throw Object.assign( new Error( 'Unrecognized compliance topic: ' + event ), { status : 401 });
+
+			}
+
+			return {
+				// Compliance payloads already carry shop_domain in the body — Shopify's
+				// own GDPR shape. The app-level event stream does not; that domain
+				// lives only in the header, so it is stamped on here rather than left
+				// for drawbridge-sync to reach into headers nobody hands it.
+				data : action === 'compliance'
+					? payload
+					: { ...payload, shop_domain : headers[ inbound.headers.shop ] || null },
+				provider : { id : headers[ inbound.headers.id ] || null }
+			};
+
 		},
-		signature : {
-			algorithm : 'sha256',
-			encoding : 'base64',
-			secret : 'SHOPIFY_API_SECRET'
-		}
+		'inbound.verify' : ( args ) => verifySignature({ ...args, descriptor : inbound })
 	},
 	icon: icon$1,
+	inbound,
 	label : 'shopify',
 	// A pre-launch integration: it only surfaces once the App Store listing
 	// exists and the app is fully configured. Requiring all four means it can
@@ -479,8 +614,9 @@ var shopify = {
 		'catalog.prices' : false,
 		'catalog.products' : true,
 		'catalog.promotions' : true,
-		'inbound.handle' : true,
-		'inbound.topic' : true,
+		'inbound.event' : true,
+		'inbound.process' : true,
+		'inbound.receive' : true,
 		'inbound.verify' : true,
 		'lifecycle.cleanup' : true,
 		'lifecycle.register' : true,
@@ -647,8 +783,9 @@ var webhook = {
 		'catalog.prices' : false,
 		'catalog.products' : false,
 		'catalog.promotions' : false,
-		'inbound.handle' : false,
-		'inbound.topic' : false,
+		'inbound.event' : false,
+		'inbound.process' : false,
+		'inbound.receive' : false,
 		'inbound.verify' : false,
 		'lifecycle.cleanup' : false,
 		'lifecycle.register' : false,
@@ -835,9 +972,9 @@ const build = ( manifest ) => {
 	// A vendor that receives from the outside must say where it puts the event
 	// name. Without it the receiver has nothing to dispatch on, and the failure
 	// is a request accepted and dropped rather than an error.
-	if( manifest.supports?.[ 'inbound.topic' ] && ! manifest.inbound?.headers?.topic ){
+	if( manifest.supports?.[ 'inbound.event' ] && ! manifest.inbound?.headers?.event ){
 
-		throw new Error( manifest.slug + ' supports inbound.topic but declares no inbound.headers.topic' );
+		throw new Error( manifest.slug + ' supports inbound.event but declares no inbound.headers.event' );
 
 	}
 
@@ -1090,7 +1227,11 @@ const runHook = async ( slug, name, args = {} ) => {
 
 	} catch ( error ) {
 
-		return { error : error?.message || 'failed', outcome : OUTCOMES.failed };
+		// A hook throws to REJECT, not just to report failure — inbound.verify
+		// on a forged signature, inbound.receive on a topic outside the vendor's
+		// declared set. The status rides along so a caller can answer 401 rather
+		// than always folding a hook's own rejection into a 500.
+		return { error : error?.message || 'failed', outcome : OUTCOMES.failed, status : error?.status || null };
 
 	}
 
@@ -1216,7 +1357,7 @@ const resolveConnection = ( item, data ) => {
 
 	return Object.fromEntries(
 		Object.entries( item )
-			.filter( ( [ key ] ) => ! [ 'auth', 'enabled', 'fields', 'inbound', 'requires', 'steps', 'supports' ].includes( key ) )
+			.filter( ( [ key ] ) => ! [ 'auth', 'enabled', 'fields', 'hooks', 'inbound', 'requires', 'steps', 'supports' ].includes( key ) )
 			.map( ( [ key, value ] ) => [
 				key,
 				( typeof value === 'function' ? value( data ) : value )

package/dist/connections/index.js

@@ -26,14 +26,49 @@ var HOOKS = Object.freeze({
     "cleanup"
   ]),
   // Receiving from the vendor.
+  //
+  // Split across TWO SERVICES, and the split is the point. `verify` and `event`
+  // and `receive` run in drawbridge-webhooks against the vendor's open
+  // connection, where the budget is whatever that vendor's timeout is —
+  // Shopify's is about five seconds, and missing it means they retry and the
+  // delivery is buffered twice. `process` runs in drawbridge-sync off the
+  // buffer, where it can take as long as it needs and retry without the vendor
+  // ever knowing.
+  //
+  // One hook spanning that seam would hide it, and the thing it hides is the
+  // one most likely to bite: slow work written on the receiving side turns
+  // into duplicate deliveries.
   inbound: Object.freeze([
-    // Prove the request came from the vendor. Signature schemes differ per
-    // vendor, which is exactly why this is a hook and not one shared function.
+    // Prove the request came from the vendor, AND return the payload it
+    // carries. One hook rather than two because for some vendors they are
+    // genuinely one operation: a JWT-bodied webhook (Kinde) cannot be decoded
+    // into anything trustworthy without verifying it first, and a decode that
+    // runs before the signature check is exactly the bug this shape prevents.
+    //
+    // So the raw bytes stop here. Everything downstream receives the payload
+    // this returned, which means nothing downstream can act on unverified
+    // data even by mistake.
+    //
+    // It is also where a request gets refused for any other reason — an event
+    // outside the allowlist, a connection in the wrong state. Anything that
+    // can reject belongs here, so the route holds no rules of its own.
     "verify",
-    // Name the event, from wherever this vendor puts it.
-    "topic",
-    // Do the work the event implies.
-    "handle"
+    // Name the event, from wherever this vendor puts it. A header for
+    // Shopify, the route itself for Twilio, a claim in the payload for a
+    // JWT-bodied vendor.
+    "event",
+    // What to buffer and what to answer RIGHT NOW, while the vendor waits.
+    // Thin by obligation. Most vendors only shape a buffer doc here; one that
+    // must reply with content (Twilio answers HELP inline with TwiML, which
+    // carriers require) returns that too.
+    "receive",
+    // Do the work the event implies. Runs in drawbridge-sync, off the buffer.
+    //
+    // DECLARED here, IMPLEMENTED there — the same split as the step handlers,
+    // and for the same reason: this half needs controllers, queues and vendor
+    // SDKs, and putting those behind a published package makes every consumer
+    // carry them. The declaration is what proves the implementation exists.
+    "process"
   ]),
   // Vendor data a campaign draws on. Named for what every store platform has,
   // not for what Shopify calls it: Shopify says discounts, Stripe says coupons
@@ -259,8 +294,9 @@ var klaviyo_default2 = {
     "catalog.prices": false,
     "catalog.products": false,
     "catalog.promotions": false,
-    "inbound.handle": false,
-    "inbound.topic": false,
+    "inbound.event": false,
+    "inbound.process": false,
+    "inbound.receive": false,
     "inbound.verify": false,
     "lifecycle.cleanup": false,
     "lifecycle.register": false,
@@ -330,8 +366,9 @@ var mailchimp_default2 = {
     "catalog.prices": false,
     "catalog.products": false,
     "catalog.promotions": false,
-    "inbound.handle": false,
-    "inbound.topic": false,
+    "inbound.event": false,
+    "inbound.process": false,
+    "inbound.receive": false,
     "inbound.verify": false,
     "lifecycle.cleanup": false,
     "lifecycle.register": false,
@@ -365,7 +402,42 @@ var shopify_default = `<svg width="500" height="500" viewBox="0 0 500 500" fill=
 <path d="M258.993 193.019L249.103 230.052C249.103 230.052 238.079 225.023 225 225.85C205.833 227.059 205.628 239.171 205.824 242.21C206.865 258.756 250.376 262.381 252.821 301.171C254.745 331.688 236.656 352.574 210.592 354.21C179.313 356.19 162.089 337.711 162.089 337.711L168.716 309.472C168.716 309.472 186.052 322.569 199.921 321.686C208.993 321.119 212.228 313.738 211.903 308.514C210.536 286.921 175.102 288.185 172.862 252.695C170.985 222.811 190.57 192.554 233.803 189.821C250.46 188.762 258.993 193.028 258.993 193.028" fill="white"/>
 </svg>`;
 
+// lib/connections/inbound.js
+import { createHmac, timingSafeEqual } from "crypto";
+var verifySignature = ({ body, descriptor, headers }) => {
+  const provided = headers[descriptor.headers.signature];
+  if (!provided) {
+    throw Object.assign(new Error("Missing webhook signature"), { status: 401 });
+  }
+  const digest = createHmac(descriptor.signature.algorithm, process.env[descriptor.signature.secret]).update(body).digest(descriptor.signature.encoding);
+  const digestBuffer = Buffer.from(digest, descriptor.signature.encoding);
+  const providedBuffer = Buffer.from(provided, descriptor.signature.encoding);
+  if (digestBuffer.length !== providedBuffer.length || !timingSafeEqual(digestBuffer, providedBuffer)) {
+    throw Object.assign(new Error("Invalid webhook signature"), { status: 401 });
+  }
+  return JSON.parse(body.toString());
+};
+var readEventHeader = ({ descriptor, headers }) => headers[descriptor.headers.event];
+
 // lib/connections/shopify.js
+var inbound = {
+  headers: {
+    event: "x-shopify-topic",
+    id: "x-shopify-webhook-id",
+    shop: "x-shopify-shop-domain",
+    signature: "x-shopify-hmac-sha256"
+  },
+  signature: {
+    algorithm: "sha256",
+    encoding: "base64",
+    secret: "SHOPIFY_API_SECRET"
+  }
+};
+var COMPLIANCE_TOPICS = /* @__PURE__ */ new Set([
+  "customers/data_request",
+  "customers/redact",
+  "shop/redact"
+]);
 var shopify_default2 = {
   // INSTALL, not oauth. The grant is an OAuth grant, but the merchant never
   // sees a consent screen we sent them to -- they start at the App Store, and
@@ -410,30 +482,31 @@ var shopify_default2 = {
     }
   ],
   group: "ecommerce",
-  // WHERE THIS VENDOR PUTS THINGS ON AN INBOUND REQUEST. Header names are facts
-  // about someone else's product, so they belong beside the rest of the vendor
-  // rather than as string literals in a route — which is where they were, and
-  // is why a second inbound vendor meant a second route file.
-  //
-  // `signature` describes an HMAC scheme the shared verifier can run: hash the
-  // raw body with the named secret and compare, constant-time, against the
-  // header. Vendors whose scheme is not that shape — Stripe signs a timestamped
-  // payload — declare no signature block and implement inbound.verify instead.
-  // That is why verify is a hook and not config.
-  inbound: {
-    headers: {
-      id: "x-shopify-webhook-id",
-      shop: "x-shopify-shop-domain",
-      signature: "x-shopify-hmac-sha256",
-      topic: "x-shopify-topic"
+  // verify and event lean entirely on the shared HMAC helper — Shopify's scheme
+  // is exactly the shape it covers, so there is nothing vendor-specific to
+  // write for either. receive is the one hook that genuinely differs by
+  // action: /events buffers whatever arrives with the shop domain stamped on;
+  // /compliance enforces the topic allowlist above, because answering one late
+  // is a legal deadline rather than a retry.
+  hooks: {
+    "inbound.event": (args) => readEventHeader({ ...args, descriptor: inbound }),
+    "inbound.receive": ({ action, event, headers, payload }) => {
+      if (action === "compliance" && !COMPLIANCE_TOPICS.has(event)) {
+        throw Object.assign(new Error("Unrecognized compliance topic: " + event), { status: 401 });
+      }
+      return {
+        // Compliance payloads already carry shop_domain in the body — Shopify's
+        // own GDPR shape. The app-level event stream does not; that domain
+        // lives only in the header, so it is stamped on here rather than left
+        // for drawbridge-sync to reach into headers nobody hands it.
+        data: action === "compliance" ? payload : { ...payload, shop_domain: headers[inbound.headers.shop] || null },
+        provider: { id: headers[inbound.headers.id] || null }
+      };
     },
-    signature: {
-      algorithm: "sha256",
-      encoding: "base64",
-      secret: "SHOPIFY_API_SECRET"
-    }
+    "inbound.verify": (args) => verifySignature({ ...args, descriptor: inbound })
   },
   icon: shopify_default,
+  inbound,
   label: "shopify",
   // A pre-launch integration: it only surfaces once the App Store listing
   // exists and the app is fully configured. Requiring all four means it can
@@ -462,8 +535,9 @@ var shopify_default2 = {
     "catalog.prices": false,
     "catalog.products": true,
     "catalog.promotions": true,
-    "inbound.handle": true,
-    "inbound.topic": true,
+    "inbound.event": true,
+    "inbound.process": true,
+    "inbound.receive": true,
     "inbound.verify": true,
     "lifecycle.cleanup": true,
     "lifecycle.register": true,
@@ -623,8 +697,9 @@ var webhook_default = {
     "catalog.prices": false,
     "catalog.products": false,
     "catalog.promotions": false,
-    "inbound.handle": false,
-    "inbound.topic": false,
+    "inbound.event": false,
+    "inbound.process": false,
+    "inbound.receive": false,
     "inbound.verify": false,
     "lifecycle.cleanup": false,
     "lifecycle.register": false,
@@ -714,8 +789,8 @@ var build = (manifest) => {
       }
     }
   }
-  if (((_d = manifest.supports) == null ? void 0 : _d["inbound.topic"]) && !((_f = (_e = manifest.inbound) == null ? void 0 : _e.headers) == null ? void 0 : _f.topic)) {
-    throw new Error(manifest.slug + " supports inbound.topic but declares no inbound.headers.topic");
+  if (((_d = manifest.supports) == null ? void 0 : _d["inbound.event"]) && !((_f = (_e = manifest.inbound) == null ? void 0 : _e.headers) == null ? void 0 : _f.event)) {
+    throw new Error(manifest.slug + " supports inbound.event but declares no inbound.headers.event");
   }
   if (((_g = manifest.supports) == null ? void 0 : _g["inbound.verify"]) && !((_i = (_h = manifest.inbound) == null ? void 0 : _h.headers) == null ? void 0 : _i.signature)) {
     throw new Error(manifest.slug + " supports inbound.verify but declares no inbound.headers.signature");
@@ -830,7 +905,7 @@ var runHook = async (slug, name, args = {}) => {
   try {
     return { outcome: OUTCOMES.answered, result: await hook(args) };
   } catch (error) {
-    return { error: (error == null ? void 0 : error.message) || "failed", outcome: OUTCOMES.failed };
+    return { error: (error == null ? void 0 : error.message) || "failed", outcome: OUTCOMES.failed, status: (error == null ? void 0 : error.status) || null };
   }
 };
 var stepQueues = (env = {}) => Object.fromEntries(
@@ -896,7 +971,7 @@ var projectConnection = (record) => {
 var resolveConnection = (item, data) => {
   if (!item) return item;
   return Object.fromEntries(
-    Object.entries(item).filter(([key]) => !["auth", "enabled", "fields", "inbound", "requires", "steps", "supports"].includes(key)).map(([key, value]) => [
+    Object.entries(item).filter(([key]) => !["auth", "enabled", "fields", "hooks", "inbound", "requires", "steps", "supports"].includes(key)).map(([key, value]) => [
       key,
       typeof value === "function" ? value(data) : value
     ])

package/package.json

@@ -200,5 +200,5 @@
     "test": ". \"$HOME/.nvm/nvm.sh\" && nvm use && node --test"
   },
   "types": "dist/index.d.ts",
-  "version": "0.0.107"
+  "version": "0.0.108"
 }