@drawbridge/drawbridge-utils 0.0.104 → 0.0.106

package/dist/features.cjs

@@ -99,11 +99,6 @@ var connection = {
     error: "Plan does not include Mailchimp connection",
     feature: "Mailchimp connection"
   },
-  sender: {
-    key: "organization:connection:sender",
-    error: "Plan does not include a verified sending domain",
-    feature: "Sending domain connection"
-  },
   sendgrid: {
     key: "organization:connection:sendgrid",
     error: "Plan does not include SendGrid connection",
@@ -168,6 +163,19 @@ var organization = {
     error: "Your plan does not include brands",
     feature: "Organization brands management"
   },
+  // Gates the Networking section as a whole — a verified sending domain today,
+  // the SMS number and a custom page domain as they land. One key rather than
+  // one per type: they are the same capability to a merchant, and splitting
+  // them would mean a plan could grant half a section.
+  //
+  // It replaces `connection.sender`, which named a connection this stopped
+  // being. Free organizations cannot send lead-facing email at all, so a
+  // sending identity there is one they could never send from.
+  networking: {
+    key: "organization:networking",
+    error: "Your plan does not include a custom sending identity",
+    feature: "Organization networking"
+  },
   members: {
     key: "organization:members",
     error: "Your plan does not include team members",

package/dist/features.d.cts

@@ -73,11 +73,6 @@ const connection = {
 		error : 'Plan does not include Mailchimp connection',
 		feature : 'Mailchimp connection'
 	},
-	sender : {
-		key : 'organization:connection:sender',
-		error : 'Plan does not include a verified sending domain',
-		feature : 'Sending domain connection'
-	},
 	sendgrid : {
 		key : 'organization:connection:sendgrid',
 		error : 'Plan does not include SendGrid connection',
@@ -144,6 +139,19 @@ const organization = {
 		error : 'Your plan does not include brands',
 		feature : 'Organization brands management',
 	},
+	// Gates the Networking section as a whole — a verified sending domain today,
+	// the SMS number and a custom page domain as they land. One key rather than
+	// one per type: they are the same capability to a merchant, and splitting
+	// them would mean a plan could grant half a section.
+	//
+	// It replaces `connection.sender`, which named a connection this stopped
+	// being. Free organizations cannot send lead-facing email at all, so a
+	// sending identity there is one they could never send from.
+	networking : {
+		key : 'organization:networking',
+		error : 'Your plan does not include a custom sending identity',
+		feature : 'Organization networking'
+	},
 	members : {
 		key : 'organization:members',
 		error : 'Your plan does not include team members',

package/dist/features.d.ts

@@ -73,11 +73,6 @@ const connection = {
 		error : 'Plan does not include Mailchimp connection',
 		feature : 'Mailchimp connection'
 	},
-	sender : {
-		key : 'organization:connection:sender',
-		error : 'Plan does not include a verified sending domain',
-		feature : 'Sending domain connection'
-	},
 	sendgrid : {
 		key : 'organization:connection:sendgrid',
 		error : 'Plan does not include SendGrid connection',
@@ -144,6 +139,19 @@ const organization = {
 		error : 'Your plan does not include brands',
 		feature : 'Organization brands management',
 	},
+	// Gates the Networking section as a whole — a verified sending domain today,
+	// the SMS number and a custom page domain as they land. One key rather than
+	// one per type: they are the same capability to a merchant, and splitting
+	// them would mean a plan could grant half a section.
+	//
+	// It replaces `connection.sender`, which named a connection this stopped
+	// being. Free organizations cannot send lead-facing email at all, so a
+	// sending identity there is one they could never send from.
+	networking : {
+		key : 'organization:networking',
+		error : 'Your plan does not include a custom sending identity',
+		feature : 'Organization networking'
+	},
 	members : {
 		key : 'organization:members',
 		error : 'Your plan does not include team members',

package/dist/features.js

@@ -71,11 +71,6 @@ var connection = {
     error: "Plan does not include Mailchimp connection",
     feature: "Mailchimp connection"
   },
-  sender: {
-    key: "organization:connection:sender",
-    error: "Plan does not include a verified sending domain",
-    feature: "Sending domain connection"
-  },
   sendgrid: {
     key: "organization:connection:sendgrid",
     error: "Plan does not include SendGrid connection",
@@ -140,6 +135,19 @@ var organization = {
     error: "Your plan does not include brands",
     feature: "Organization brands management"
   },
+  // Gates the Networking section as a whole — a verified sending domain today,
+  // the SMS number and a custom page domain as they land. One key rather than
+  // one per type: they are the same capability to a merchant, and splitting
+  // them would mean a plan could grant half a section.
+  //
+  // It replaces `connection.sender`, which named a connection this stopped
+  // being. Free organizations cannot send lead-facing email at all, so a
+  // sending identity there is one they could never send from.
+  networking: {
+    key: "organization:networking",
+    error: "Your plan does not include a custom sending identity",
+    feature: "Organization networking"
+  },
   members: {
     key: "organization:members",
     error: "Your plan does not include team members",

package/dist/plans.cjs

@@ -110,11 +110,6 @@ var connection = {
     error: "Plan does not include Mailchimp connection",
     feature: "Mailchimp connection"
   },
-  sender: {
-    key: "organization:connection:sender",
-    error: "Plan does not include a verified sending domain",
-    feature: "Sending domain connection"
-  },
   sendgrid: {
     key: "organization:connection:sendgrid",
     error: "Plan does not include SendGrid connection",
@@ -157,6 +152,19 @@ var organization = {
     error: "Your plan does not include brands",
     feature: "Organization brands management"
   },
+  // Gates the Networking section as a whole — a verified sending domain today,
+  // the SMS number and a custom page domain as they land. One key rather than
+  // one per type: they are the same capability to a merchant, and splitting
+  // them would mean a plan could grant half a section.
+  //
+  // It replaces `connection.sender`, which named a connection this stopped
+  // being. Free organizations cannot send lead-facing email at all, so a
+  // sending identity there is one they could never send from.
+  networking: {
+    key: "organization:networking",
+    error: "Your plan does not include a custom sending identity",
+    feature: "Organization networking"
+  },
   members: {
     key: "organization:members",
     error: "Your plan does not include team members",
@@ -341,7 +349,7 @@ var plans = {
     // lead-facing email at all (the send path gates on an active
     // subscription), so granting it there would offer a domain that can
     // never send from.
-    features: all.features([connection.sender.key, organization.members.key]),
+    features: all.features([organization.networking.key, organization.members.key]),
     limits: all.limits({ actions: 5e3, members: 3, storage: gigabyte * 10 }),
     marketing: {
       description: "Tools to fine-tune campaigns and improve lead quality.",
@@ -362,7 +370,7 @@ var plans = {
   },
   DB00003: {
     features: all.features([
-      connection.sender.key,
+      organization.networking.key,
       organization.advertisements.key,
       organization.analytics.key,
       organization.members.key,
@@ -393,7 +401,7 @@ var plans = {
   },
   DB00004: {
     features: all.features([
-      connection.sender.key,
+      organization.networking.key,
       organization.advertisements.key,
       organization.analytics.key,
       organization.members.key,
@@ -424,7 +432,7 @@ var plans = {
   },
   DB00005: {
     features: all.features([
-      connection.sender.key,
+      organization.networking.key,
       organization.advertisements.key,
       organization.analytics.key,
       organization.members.key,
@@ -469,7 +477,7 @@ var resolvePlan = (subscription) => {
     // baseline whether or not the deal thought to name it. Today that is the
     // sending domain: every catalog paid tier grants it, and a custom plan
     // silently lacking it would be a support ticket, not a pricing decision.
-    features: all.features([connection.sender.key, ...((_a = custom.features) == null ? void 0 : _a.granted) || []]),
+    features: all.features([organization.networking.key, ...((_a = custom.features) == null ? void 0 : _a.granted) || []]),
     limits: all.limits(((_b = custom.limits) == null ? void 0 : _b.organization) || {}),
     // A custom plan stores its overage BARE on `custom.overages` — a different
     // shape from the catalog's nested one. Number() so a deal stored as a string

package/dist/plans.d.cts

@@ -1,4 +1,4 @@
-import { connection, organization, page, fields, field } from './features.cjs';
+import { organization, page, connection, fields, field } from './features.cjs';
 import { infinite, gigabyte } from './index.cjs';
 import 'currency-codes';
 import 'nanoid';
@@ -131,7 +131,7 @@ const plans = {
 		// lead-facing email at all (the send path gates on an active
 		// subscription), so granting it there would offer a domain that can
 		// never send from.
-		features : all.features([ connection.sender.key, organization.members.key ]),
+		features : all.features([ organization.networking.key, organization.members.key ]),
 		limits : all.limits({ actions : 5000, members : 3, storage : gigabyte * 10 }),
 		marketing : {
 			description : 'Tools to fine-tune campaigns and improve lead quality.',
@@ -152,7 +152,7 @@ const plans = {
 	},
 	DB00003 : {
 		features : all.features([
-			connection.sender.key,
+			organization.networking.key,
 			organization.advertisements.key,
 			organization.analytics.key,
 			organization.members.key,
@@ -183,7 +183,7 @@ const plans = {
 	},
 	DB00004 : {
 		features : all.features([
-			connection.sender.key,
+			organization.networking.key,
 			organization.advertisements.key,
 			organization.analytics.key,
 			organization.members.key,
@@ -214,7 +214,7 @@ const plans = {
 	},
 	DB00005 : {
 		features : all.features([
-			connection.sender.key,
+			organization.networking.key,
 			organization.advertisements.key,
 			organization.analytics.key,
 			organization.members.key,
@@ -275,7 +275,7 @@ const resolvePlan = ( subscription ) => {
 		// baseline whether or not the deal thought to name it. Today that is the
 		// sending domain: every catalog paid tier grants it, and a custom plan
 		// silently lacking it would be a support ticket, not a pricing decision.
-		features : all.features([ connection.sender.key, ...( custom.features?.granted || [] ) ]),
+		features : all.features([ organization.networking.key, ...( custom.features?.granted || [] ) ]),
 		limits : all.limits( custom.limits?.organization || {} ),
 		// A custom plan stores its overage BARE on `custom.overages` — a different
 		// shape from the catalog's nested one. Number() so a deal stored as a string

package/dist/plans.d.ts

@@ -1,4 +1,4 @@
-import { connection, organization, page, fields, field } from './features.js';
+import { organization, page, connection, fields, field } from './features.js';
 import { infinite, gigabyte } from './index.js';
 import 'currency-codes';
 import 'nanoid';
@@ -131,7 +131,7 @@ const plans = {
 		// lead-facing email at all (the send path gates on an active
 		// subscription), so granting it there would offer a domain that can
 		// never send from.
-		features : all.features([ connection.sender.key, organization.members.key ]),
+		features : all.features([ organization.networking.key, organization.members.key ]),
 		limits : all.limits({ actions : 5000, members : 3, storage : gigabyte * 10 }),
 		marketing : {
 			description : 'Tools to fine-tune campaigns and improve lead quality.',
@@ -152,7 +152,7 @@ const plans = {
 	},
 	DB00003 : {
 		features : all.features([
-			connection.sender.key,
+			organization.networking.key,
 			organization.advertisements.key,
 			organization.analytics.key,
 			organization.members.key,
@@ -183,7 +183,7 @@ const plans = {
 	},
 	DB00004 : {
 		features : all.features([
-			connection.sender.key,
+			organization.networking.key,
 			organization.advertisements.key,
 			organization.analytics.key,
 			organization.members.key,
@@ -214,7 +214,7 @@ const plans = {
 	},
 	DB00005 : {
 		features : all.features([
-			connection.sender.key,
+			organization.networking.key,
 			organization.advertisements.key,
 			organization.analytics.key,
 			organization.members.key,
@@ -275,7 +275,7 @@ const resolvePlan = ( subscription ) => {
 		// baseline whether or not the deal thought to name it. Today that is the
 		// sending domain: every catalog paid tier grants it, and a custom plan
 		// silently lacking it would be a support ticket, not a pricing decision.
-		features : all.features([ connection.sender.key, ...( custom.features?.granted || [] ) ]),
+		features : all.features([ organization.networking.key, ...( custom.features?.granted || [] ) ]),
 		limits : all.limits( custom.limits?.organization || {} ),
 		// A custom plan stores its overage BARE on `custom.overages` — a different
 		// shape from the catalog's nested one. Number() so a deal stored as a string

package/dist/plans.js

@@ -71,11 +71,6 @@ var connection = {
     error: "Plan does not include Mailchimp connection",
     feature: "Mailchimp connection"
   },
-  sender: {
-    key: "organization:connection:sender",
-    error: "Plan does not include a verified sending domain",
-    feature: "Sending domain connection"
-  },
   sendgrid: {
     key: "organization:connection:sendgrid",
     error: "Plan does not include SendGrid connection",
@@ -118,6 +113,19 @@ var organization = {
     error: "Your plan does not include brands",
     feature: "Organization brands management"
   },
+  // Gates the Networking section as a whole — a verified sending domain today,
+  // the SMS number and a custom page domain as they land. One key rather than
+  // one per type: they are the same capability to a merchant, and splitting
+  // them would mean a plan could grant half a section.
+  //
+  // It replaces `connection.sender`, which named a connection this stopped
+  // being. Free organizations cannot send lead-facing email at all, so a
+  // sending identity there is one they could never send from.
+  networking: {
+    key: "organization:networking",
+    error: "Your plan does not include a custom sending identity",
+    feature: "Organization networking"
+  },
   members: {
     key: "organization:members",
     error: "Your plan does not include team members",
@@ -302,7 +310,7 @@ var plans = {
     // lead-facing email at all (the send path gates on an active
     // subscription), so granting it there would offer a domain that can
     // never send from.
-    features: all.features([connection.sender.key, organization.members.key]),
+    features: all.features([organization.networking.key, organization.members.key]),
     limits: all.limits({ actions: 5e3, members: 3, storage: gigabyte * 10 }),
     marketing: {
       description: "Tools to fine-tune campaigns and improve lead quality.",
@@ -323,7 +331,7 @@ var plans = {
   },
   DB00003: {
     features: all.features([
-      connection.sender.key,
+      organization.networking.key,
       organization.advertisements.key,
       organization.analytics.key,
       organization.members.key,
@@ -354,7 +362,7 @@ var plans = {
   },
   DB00004: {
     features: all.features([
-      connection.sender.key,
+      organization.networking.key,
       organization.advertisements.key,
       organization.analytics.key,
       organization.members.key,
@@ -385,7 +393,7 @@ var plans = {
   },
   DB00005: {
     features: all.features([
-      connection.sender.key,
+      organization.networking.key,
       organization.advertisements.key,
       organization.analytics.key,
       organization.members.key,
@@ -430,7 +438,7 @@ var resolvePlan = (subscription) => {
     // baseline whether or not the deal thought to name it. Today that is the
     // sending domain: every catalog paid tier grants it, and a custom plan
     // silently lacking it would be a support ticket, not a pricing decision.
-    features: all.features([connection.sender.key, ...((_a = custom.features) == null ? void 0 : _a.granted) || []]),
+    features: all.features([organization.networking.key, ...((_a = custom.features) == null ? void 0 : _a.granted) || []]),
     limits: all.limits(((_b = custom.limits) == null ? void 0 : _b.organization) || {}),
     // A custom plan stores its overage BARE on `custom.overages` — a different
     // shape from the catalog's nested one. Number() so a deal stored as a string

package/dist/pricing.cjs

@@ -43,6 +43,7 @@ __export(pricing_exports, {
   plans: () => plans,
   resolvePlan: () => resolvePlan,
   scrape: () => scrape,
+  sending: () => sending,
   unitAmountDecimal: () => unitAmountDecimal
 });
 module.exports = __toCommonJS(pricing_exports);
@@ -120,11 +121,6 @@ var connection = {
     error: "Plan does not include Mailchimp connection",
     feature: "Mailchimp connection"
   },
-  sender: {
-    key: "organization:connection:sender",
-    error: "Plan does not include a verified sending domain",
-    feature: "Sending domain connection"
-  },
   sendgrid: {
     key: "organization:connection:sendgrid",
     error: "Plan does not include SendGrid connection",
@@ -167,6 +163,19 @@ var organization = {
     error: "Your plan does not include brands",
     feature: "Organization brands management"
   },
+  // Gates the Networking section as a whole — a verified sending domain today,
+  // the SMS number and a custom page domain as they land. One key rather than
+  // one per type: they are the same capability to a merchant, and splitting
+  // them would mean a plan could grant half a section.
+  //
+  // It replaces `connection.sender`, which named a connection this stopped
+  // being. Free organizations cannot send lead-facing email at all, so a
+  // sending identity there is one they could never send from.
+  networking: {
+    key: "organization:networking",
+    error: "Your plan does not include a custom sending identity",
+    feature: "Organization networking"
+  },
   members: {
     key: "organization:members",
     error: "Your plan does not include team members",
@@ -351,7 +360,7 @@ var plans = {
     // lead-facing email at all (the send path gates on an active
     // subscription), so granting it there would offer a domain that can
     // never send from.
-    features: all.features([connection.sender.key, organization.members.key]),
+    features: all.features([organization.networking.key, organization.members.key]),
     limits: all.limits({ actions: 5e3, members: 3, storage: gigabyte * 10 }),
     marketing: {
       description: "Tools to fine-tune campaigns and improve lead quality.",
@@ -372,7 +381,7 @@ var plans = {
   },
   DB00003: {
     features: all.features([
-      connection.sender.key,
+      organization.networking.key,
       organization.advertisements.key,
       organization.analytics.key,
       organization.members.key,
@@ -403,7 +412,7 @@ var plans = {
   },
   DB00004: {
     features: all.features([
-      connection.sender.key,
+      organization.networking.key,
       organization.advertisements.key,
       organization.analytics.key,
       organization.members.key,
@@ -434,7 +443,7 @@ var plans = {
   },
   DB00005: {
     features: all.features([
-      connection.sender.key,
+      organization.networking.key,
       organization.advertisements.key,
       organization.analytics.key,
       organization.members.key,
@@ -479,7 +488,7 @@ var resolvePlan = (subscription) => {
     // baseline whether or not the deal thought to name it. Today that is the
     // sending domain: every catalog paid tier grants it, and a custom plan
     // silently lacking it would be a support ticket, not a pricing decision.
-    features: all.features([connection.sender.key, ...((_a = custom.features) == null ? void 0 : _a.granted) || []]),
+    features: all.features([organization.networking.key, ...((_a = custom.features) == null ? void 0 : _a.granted) || []]),
     limits: all.limits(((_b = custom.limits) == null ? void 0 : _b.organization) || {}),
     // A custom plan stores its overage BARE on `custom.overages` — a different
     // shape from the catalog's nested one. Number() so a deal stored as a string
@@ -774,6 +783,76 @@ var scrape = {
 };
 
 // lib/pricing.js
+var emailPlans = {
+  essentials50k: {
+    included: 5e4,
+    // The plan's own price is not shown in the console once you are on it —
+    // it reads "Your Current Plan" where the price would be. Left null rather
+    // than guessed; fill from an invoice. Nothing derives from it yet, and an
+    // invented figure would quietly become the basis of an upgrade decision.
+    monthly: null,
+    overageCents: 0.133,
+    title: "Essentials 50K"
+  },
+  essentials100k: {
+    included: 1e5,
+    monthly: 3495,
+    overageCents: 0.09,
+    title: "Essentials 100K"
+  },
+  pro100k: {
+    included: 1e5,
+    monthly: 8995,
+    overageCents: 0.11,
+    title: "Pro 100K"
+  },
+  pro300k: {
+    included: 3e5,
+    monthly: 24900,
+    overageCents: 0.091,
+    title: "Pro 300K"
+  },
+  pro700k: {
+    included: 7e5,
+    monthly: 49900,
+    overageCents: 0.078,
+    title: "Pro 700K"
+  },
+  pro1500k: {
+    included: 15e5,
+    monthly: 79900,
+    overageCents: 0.059,
+    title: "Pro 1.5 Million"
+  },
+  pro2500k: {
+    included: 25e5,
+    monthly: 109900,
+    overageCents: 0.047,
+    title: "Pro 2.5 Million"
+  }
+};
+var emailPlan = "essentials50k";
+var sending = {
+  email: {
+    // Fraction of the included volume that raises the alarm. Far enough ahead
+    // to act on, high enough not to fire on ordinary growth.
+    //
+    // Crossing it is NOT an outage. The provider bills overage rather than
+    // stopping sends, so the alarm is a COST signal: past the included volume
+    // every email is charged at overageCents, and at some run rate the next
+    // plan up is cheaper than the overage. That is the decision it exists to
+    // prompt, and it is why nobody should be woken by it.
+    alertThreshold: 0.8,
+    // Emails per calendar month included, PLATFORM-WIDE and across every send
+    // path: lead-facing mail, workflow steps, and the sign-in codes and
+    // account mail that no plan allowance meters.
+    monthlyCeiling: emailPlans[emailPlan].included,
+    overageCents: emailPlans[emailPlan].overageCents,
+    plan: emailPlan,
+    plans: emailPlans,
+    title: emailPlans[emailPlan].title
+  }
+};
 var channels = {
   email: {
     actionsPerSend: 1,
@@ -803,5 +882,6 @@ var channels = {
   plans,
   resolvePlan,
   scrape,
+  sending,
   unitAmountDecimal
 });

package/dist/pricing.d.cts

@@ -36,6 +36,11 @@ import '@drawbridge/drawbridge-telemetry';
 //   channels.sms.actionsPerSegment     ACTIONS per SMS segment.
 //   channels.*.includedInAllowance     whether the plan's included actions cover it.
 //
+// ─── Provider capacity (owned here) ───────────────────────────────────────────
+//   sending.email.monthlyCeiling   EMAILS per calendar month we have BOUGHT,
+//                                  platform-wide across every send path.
+//   sending.email.alertThreshold   FRACTION of that ceiling which alarms.
+//
 // ─── Scrape + AI (lib/billing.js) ─────────────────────────────────────────────
 //   MARKUP                 MULTIPLIER on provider cost (1.3 = 30% margin).
 //   STANDARD_RATE_PER_GB   DOLLARS per GB, BrightData Scraping Browser.
@@ -53,6 +58,121 @@ import '@drawbridge/drawbridge-telemetry';
 // consumer of this file.
 
 
+// What we have BOUGHT from the sending providers, against what the plans above
+// SELL. Here rather than in an env because it is a rate like every other number
+// in this file, and the whole point of this file is that you do not have to
+// know which environment to look in to find one. Changing it is a publish and a
+// pin bump, which is the right friction for a number that changes when a
+// contract changes.
+//
+// READ THIS BEFORE RAISING A PLAN ALLOWANCE. The ceiling is PLATFORM-WIDE while
+// every allowance above is PER ORGANIZATION, and an allowance can be spent
+// entirely on email — so the two are denominated against very different things:
+//
+//   Elite    100,000 = 200% of the whole platform's email ceiling
+//   Premium   40,000 =  80%
+//   Pro       15,000 =  30%
+//   Starter    5,000 =  10%
+//
+// As of 2026-08-30 we sell about 2x the email we buy, against real usage of
+// ~622 sends a month — so this is a shape to watch, not a fire.
+//
+// Exceeding the included volume does NOT stop sends. The provider bills
+// overage per email (see overageCents), so the consequence is a bill and the
+// question is only ever "is the next plan up cheaper than the overage yet".
+// Both halves stay comfortable: at 0.133c of overage against 1.5-2.5c of
+// action overage, email we send past the plan still earns more than ten times
+// what it costs.
+//
+// Raising a tier's allowance should still move the plan below, or the included
+// volume quietly becomes the number that decides the bill.
+// The provider's plan ladder, so the ceiling is DERIVED from which plan we are
+// on rather than being a loose number somebody has to remember to change. Read
+// from the SendGrid Email API Plans page 2026-08-30.
+//
+//   included       EMAILS per calendar month before overage starts.
+//   overageCents   CENTS per additional email. $0.00133 is 0.133 CENTS — the
+//                  decimal is the whole reason this is not stored in dollars.
+//   monthly        CENTS per month for the plan itself.
+//
+// Pro is not "cheaper email" — Pro 100K costs more per overage email than
+// Essentials 100K. What Pro buys is a dedicated IP, subusers, regional data
+// residency, and link branding. Move for those, not for the rate.
+const emailPlans = {
+	essentials50k : {
+		included : 50000,
+		// The plan's own price is not shown in the console once you are on it —
+		// it reads "Your Current Plan" where the price would be. Left null rather
+		// than guessed; fill from an invoice. Nothing derives from it yet, and an
+		// invented figure would quietly become the basis of an upgrade decision.
+		monthly : null,
+		overageCents : 0.133,
+		title : 'Essentials 50K'
+	},
+	essentials100k : {
+		included : 100000,
+		monthly : 3495,
+		overageCents : 0.09,
+		title : 'Essentials 100K'
+	},
+	pro100k : {
+		included : 100000,
+		monthly : 8995,
+		overageCents : 0.11,
+		title : 'Pro 100K'
+	},
+	pro300k : {
+		included : 300000,
+		monthly : 24900,
+		overageCents : 0.091,
+		title : 'Pro 300K'
+	},
+	pro700k : {
+		included : 700000,
+		monthly : 49900,
+		overageCents : 0.078,
+		title : 'Pro 700K'
+	},
+	pro1500k : {
+		included : 1500000,
+		monthly : 79900,
+		overageCents : 0.059,
+		title : 'Pro 1.5 Million'
+	},
+	pro2500k : {
+		included : 2500000,
+		monthly : 109900,
+		overageCents : 0.047,
+		title : 'Pro 2.5 Million'
+	}
+};
+
+// THE ONE FIELD TO CHANGE when the provider plan changes. Everything else here
+// follows from it.
+const emailPlan = 'essentials50k';
+
+const sending = {
+	email : {
+		// Fraction of the included volume that raises the alarm. Far enough ahead
+		// to act on, high enough not to fire on ordinary growth.
+		//
+		// Crossing it is NOT an outage. The provider bills overage rather than
+		// stopping sends, so the alarm is a COST signal: past the included volume
+		// every email is charged at overageCents, and at some run rate the next
+		// plan up is cheaper than the overage. That is the decision it exists to
+		// prompt, and it is why nobody should be woken by it.
+		alertThreshold : 0.8,
+		// Emails per calendar month included, PLATFORM-WIDE and across every send
+		// path: lead-facing mail, workflow steps, and the sign-in codes and
+		// account mail that no plan allowance meters.
+		monthlyCeiling : emailPlans[ emailPlan ].included,
+		overageCents : emailPlans[ emailPlan ].overageCents,
+		plan : emailPlan,
+		plans : emailPlans,
+		title : emailPlans[ emailPlan ].title
+	}
+};
+
 // Weighted actions: what one message of each channel costs against a plan.
 // Named per unit so a bare `2` can never be read as cents.
 const channels = {
@@ -69,4 +189,4 @@ const channels = {
 	}
 };
 
-export { channels };
+export { channels, sending };

package/dist/pricing.d.ts

@@ -36,6 +36,11 @@ import '@drawbridge/drawbridge-telemetry';
 //   channels.sms.actionsPerSegment     ACTIONS per SMS segment.
 //   channels.*.includedInAllowance     whether the plan's included actions cover it.
 //
+// ─── Provider capacity (owned here) ───────────────────────────────────────────
+//   sending.email.monthlyCeiling   EMAILS per calendar month we have BOUGHT,
+//                                  platform-wide across every send path.
+//   sending.email.alertThreshold   FRACTION of that ceiling which alarms.
+//
 // ─── Scrape + AI (lib/billing.js) ─────────────────────────────────────────────
 //   MARKUP                 MULTIPLIER on provider cost (1.3 = 30% margin).
 //   STANDARD_RATE_PER_GB   DOLLARS per GB, BrightData Scraping Browser.
@@ -53,6 +58,121 @@ import '@drawbridge/drawbridge-telemetry';
 // consumer of this file.
 
 
+// What we have BOUGHT from the sending providers, against what the plans above
+// SELL. Here rather than in an env because it is a rate like every other number
+// in this file, and the whole point of this file is that you do not have to
+// know which environment to look in to find one. Changing it is a publish and a
+// pin bump, which is the right friction for a number that changes when a
+// contract changes.
+//
+// READ THIS BEFORE RAISING A PLAN ALLOWANCE. The ceiling is PLATFORM-WIDE while
+// every allowance above is PER ORGANIZATION, and an allowance can be spent
+// entirely on email — so the two are denominated against very different things:
+//
+//   Elite    100,000 = 200% of the whole platform's email ceiling
+//   Premium   40,000 =  80%
+//   Pro       15,000 =  30%
+//   Starter    5,000 =  10%
+//
+// As of 2026-08-30 we sell about 2x the email we buy, against real usage of
+// ~622 sends a month — so this is a shape to watch, not a fire.
+//
+// Exceeding the included volume does NOT stop sends. The provider bills
+// overage per email (see overageCents), so the consequence is a bill and the
+// question is only ever "is the next plan up cheaper than the overage yet".
+// Both halves stay comfortable: at 0.133c of overage against 1.5-2.5c of
+// action overage, email we send past the plan still earns more than ten times
+// what it costs.
+//
+// Raising a tier's allowance should still move the plan below, or the included
+// volume quietly becomes the number that decides the bill.
+// The provider's plan ladder, so the ceiling is DERIVED from which plan we are
+// on rather than being a loose number somebody has to remember to change. Read
+// from the SendGrid Email API Plans page 2026-08-30.
+//
+//   included       EMAILS per calendar month before overage starts.
+//   overageCents   CENTS per additional email. $0.00133 is 0.133 CENTS — the
+//                  decimal is the whole reason this is not stored in dollars.
+//   monthly        CENTS per month for the plan itself.
+//
+// Pro is not "cheaper email" — Pro 100K costs more per overage email than
+// Essentials 100K. What Pro buys is a dedicated IP, subusers, regional data
+// residency, and link branding. Move for those, not for the rate.
+const emailPlans = {
+	essentials50k : {
+		included : 50000,
+		// The plan's own price is not shown in the console once you are on it —
+		// it reads "Your Current Plan" where the price would be. Left null rather
+		// than guessed; fill from an invoice. Nothing derives from it yet, and an
+		// invented figure would quietly become the basis of an upgrade decision.
+		monthly : null,
+		overageCents : 0.133,
+		title : 'Essentials 50K'
+	},
+	essentials100k : {
+		included : 100000,
+		monthly : 3495,
+		overageCents : 0.09,
+		title : 'Essentials 100K'
+	},
+	pro100k : {
+		included : 100000,
+		monthly : 8995,
+		overageCents : 0.11,
+		title : 'Pro 100K'
+	},
+	pro300k : {
+		included : 300000,
+		monthly : 24900,
+		overageCents : 0.091,
+		title : 'Pro 300K'
+	},
+	pro700k : {
+		included : 700000,
+		monthly : 49900,
+		overageCents : 0.078,
+		title : 'Pro 700K'
+	},
+	pro1500k : {
+		included : 1500000,
+		monthly : 79900,
+		overageCents : 0.059,
+		title : 'Pro 1.5 Million'
+	},
+	pro2500k : {
+		included : 2500000,
+		monthly : 109900,
+		overageCents : 0.047,
+		title : 'Pro 2.5 Million'
+	}
+};
+
+// THE ONE FIELD TO CHANGE when the provider plan changes. Everything else here
+// follows from it.
+const emailPlan = 'essentials50k';
+
+const sending = {
+	email : {
+		// Fraction of the included volume that raises the alarm. Far enough ahead
+		// to act on, high enough not to fire on ordinary growth.
+		//
+		// Crossing it is NOT an outage. The provider bills overage rather than
+		// stopping sends, so the alarm is a COST signal: past the included volume
+		// every email is charged at overageCents, and at some run rate the next
+		// plan up is cheaper than the overage. That is the decision it exists to
+		// prompt, and it is why nobody should be woken by it.
+		alertThreshold : 0.8,
+		// Emails per calendar month included, PLATFORM-WIDE and across every send
+		// path: lead-facing mail, workflow steps, and the sign-in codes and
+		// account mail that no plan allowance meters.
+		monthlyCeiling : emailPlans[ emailPlan ].included,
+		overageCents : emailPlans[ emailPlan ].overageCents,
+		plan : emailPlan,
+		plans : emailPlans,
+		title : emailPlans[ emailPlan ].title
+	}
+};
+
 // Weighted actions: what one message of each channel costs against a plan.
 // Named per unit so a bare `2` can never be read as cents.
 const channels = {
@@ -69,4 +189,4 @@ const channels = {
 	}
 };
 
-export { channels };
+export { channels, sending };

package/dist/pricing.js

@@ -71,11 +71,6 @@ var connection = {
     error: "Plan does not include Mailchimp connection",
     feature: "Mailchimp connection"
   },
-  sender: {
-    key: "organization:connection:sender",
-    error: "Plan does not include a verified sending domain",
-    feature: "Sending domain connection"
-  },
   sendgrid: {
     key: "organization:connection:sendgrid",
     error: "Plan does not include SendGrid connection",
@@ -118,6 +113,19 @@ var organization = {
     error: "Your plan does not include brands",
     feature: "Organization brands management"
   },
+  // Gates the Networking section as a whole — a verified sending domain today,
+  // the SMS number and a custom page domain as they land. One key rather than
+  // one per type: they are the same capability to a merchant, and splitting
+  // them would mean a plan could grant half a section.
+  //
+  // It replaces `connection.sender`, which named a connection this stopped
+  // being. Free organizations cannot send lead-facing email at all, so a
+  // sending identity there is one they could never send from.
+  networking: {
+    key: "organization:networking",
+    error: "Your plan does not include a custom sending identity",
+    feature: "Organization networking"
+  },
   members: {
     key: "organization:members",
     error: "Your plan does not include team members",
@@ -302,7 +310,7 @@ var plans = {
     // lead-facing email at all (the send path gates on an active
     // subscription), so granting it there would offer a domain that can
     // never send from.
-    features: all.features([connection.sender.key, organization.members.key]),
+    features: all.features([organization.networking.key, organization.members.key]),
     limits: all.limits({ actions: 5e3, members: 3, storage: gigabyte * 10 }),
     marketing: {
       description: "Tools to fine-tune campaigns and improve lead quality.",
@@ -323,7 +331,7 @@ var plans = {
   },
   DB00003: {
     features: all.features([
-      connection.sender.key,
+      organization.networking.key,
       organization.advertisements.key,
       organization.analytics.key,
       organization.members.key,
@@ -354,7 +362,7 @@ var plans = {
   },
   DB00004: {
     features: all.features([
-      connection.sender.key,
+      organization.networking.key,
       organization.advertisements.key,
       organization.analytics.key,
       organization.members.key,
@@ -385,7 +393,7 @@ var plans = {
   },
   DB00005: {
     features: all.features([
-      connection.sender.key,
+      organization.networking.key,
       organization.advertisements.key,
       organization.analytics.key,
       organization.members.key,
@@ -430,7 +438,7 @@ var resolvePlan = (subscription) => {
     // baseline whether or not the deal thought to name it. Today that is the
     // sending domain: every catalog paid tier grants it, and a custom plan
     // silently lacking it would be a support ticket, not a pricing decision.
-    features: all.features([connection.sender.key, ...((_a = custom.features) == null ? void 0 : _a.granted) || []]),
+    features: all.features([organization.networking.key, ...((_a = custom.features) == null ? void 0 : _a.granted) || []]),
     limits: all.limits(((_b = custom.limits) == null ? void 0 : _b.organization) || {}),
     // A custom plan stores its overage BARE on `custom.overages` — a different
     // shape from the catalog's nested one. Number() so a deal stored as a string
@@ -725,6 +733,76 @@ var scrape = {
 };
 
 // lib/pricing.js
+var emailPlans = {
+  essentials50k: {
+    included: 5e4,
+    // The plan's own price is not shown in the console once you are on it —
+    // it reads "Your Current Plan" where the price would be. Left null rather
+    // than guessed; fill from an invoice. Nothing derives from it yet, and an
+    // invented figure would quietly become the basis of an upgrade decision.
+    monthly: null,
+    overageCents: 0.133,
+    title: "Essentials 50K"
+  },
+  essentials100k: {
+    included: 1e5,
+    monthly: 3495,
+    overageCents: 0.09,
+    title: "Essentials 100K"
+  },
+  pro100k: {
+    included: 1e5,
+    monthly: 8995,
+    overageCents: 0.11,
+    title: "Pro 100K"
+  },
+  pro300k: {
+    included: 3e5,
+    monthly: 24900,
+    overageCents: 0.091,
+    title: "Pro 300K"
+  },
+  pro700k: {
+    included: 7e5,
+    monthly: 49900,
+    overageCents: 0.078,
+    title: "Pro 700K"
+  },
+  pro1500k: {
+    included: 15e5,
+    monthly: 79900,
+    overageCents: 0.059,
+    title: "Pro 1.5 Million"
+  },
+  pro2500k: {
+    included: 25e5,
+    monthly: 109900,
+    overageCents: 0.047,
+    title: "Pro 2.5 Million"
+  }
+};
+var emailPlan = "essentials50k";
+var sending = {
+  email: {
+    // Fraction of the included volume that raises the alarm. Far enough ahead
+    // to act on, high enough not to fire on ordinary growth.
+    //
+    // Crossing it is NOT an outage. The provider bills overage rather than
+    // stopping sends, so the alarm is a COST signal: past the included volume
+    // every email is charged at overageCents, and at some run rate the next
+    // plan up is cheaper than the overage. That is the decision it exists to
+    // prompt, and it is why nobody should be woken by it.
+    alertThreshold: 0.8,
+    // Emails per calendar month included, PLATFORM-WIDE and across every send
+    // path: lead-facing mail, workflow steps, and the sign-in codes and
+    // account mail that no plan allowance meters.
+    monthlyCeiling: emailPlans[emailPlan].included,
+    overageCents: emailPlans[emailPlan].overageCents,
+    plan: emailPlan,
+    plans: emailPlans,
+    title: emailPlans[emailPlan].title
+  }
+};
 var channels = {
   email: {
     actionsPerSend: 1,
@@ -753,5 +831,6 @@ export {
   plans,
   resolvePlan,
   scrape,
+  sending,
   unitAmountDecimal
 };

package/package.json

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