• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch application-submitted-webhook-event

Reviewing files that changed from the base of the PR and between 2cb20af and 792a53e.

• apps/web/lib/actions/partners/create-program-application.ts (8 hunks)
• apps/web/lib/integrations/common/ui/configure-webhook.tsx (4 hunks)
• apps/web/lib/integrations/slack/transform.ts (3 hunks)
• apps/web/lib/partners/complete-program-applications.ts (4 hunks)
• apps/web/lib/partners/format-application-form-data.ts (2 hunks)
• apps/web/lib/webhook/constants.ts (2 hunks)
• apps/web/lib/webhook/sample-events/partner-application-submitted.json (1 hunks)
• apps/web/lib/webhook/sample-events/partner-enrolled.json (2 hunks)
• apps/web/lib/webhook/sample-events/payload.ts (2 hunks)
• apps/web/lib/webhook/schemas.ts (2 hunks)
• apps/web/lib/webhook/types.ts (3 hunks)
• apps/web/lib/zod/schemas/program-application.ts (1 hunks)
• apps/web/lib/zod/schemas/programs.ts (1 hunks)
• apps/web/tests/webhooks/index.test.ts (2 hunks)
• apps/web/ui/webhooks/add-edit-webhook-form.tsx (4 hunks)

apps/web/lib/zod/schemas/program-application.ts (1)

5-41: LGTM!

The schema is well-structured and follows best practices:

• Properly composes partner data from existing schemas using .pick() and .merge()
• Nullable value in applicationFormData correctly handles optional form fields
• Uses standard zod import as per coding guidelines

Based on coding guidelines.

apps/web/tests/webhooks/index.test.ts (1)

17-17: LGTM!

The new webhook event schema is correctly registered in the test suite, following the established pattern for webhook event validation.

Also applies to: 84-84

apps/web/lib/webhook/sample-events/partner-enrolled.json (1)

2-2: LGTM!

The ID format update to use the pn_ prefix improves sample data consistency and aligns with partner entity naming conventions.

Also applies to: 11-11

apps/web/lib/webhook/sample-events/payload.ts (1)

10-10: LGTM!

The new sample event is correctly imported and mapped, following the established pattern for webhook sample payloads.

Also applies to: 22-22

apps/web/lib/webhook/sample-events/partner-application-submitted.json (1)

1-35: Previous critical issue has been resolved.

The sample payload now correctly matches the partnerApplicationWebhookSchema structure with all required fields present:

• ✓ Top-level id and createdAt
• ✓ Complete partner object with enrollment and social fields
• ✓ applicationFormData array with realistic form entries

The payload is now suitable for testing and documentation.

apps/web/lib/integrations/common/ui/configure-webhook.tsx (2)

8-8: LGTM!

The conditional inclusion of program-level webhook triggers based on defaultProgramId is correctly implemented. The spread operator safely handles the case when defaultProgramId is undefined, resulting in an empty array.

Also applies to: 29-29, 94-97

---

118-158: LGTM!

The UI correctly renders the extended trigger list while maintaining existing permission checks (canManageWebhook) and support filtering (supportedEvents).

apps/web/lib/integrations/slack/transform.ts (1)

12-12: LGTM!

The Slack notification template for partner applications is well-structured:

• Follows the established pattern from other webhook templates
• Properly typed with PartnerApplicationWebhookPayload
• Conditionally includes optional fields (company name)
• Constructs a valid deep link to the application view

Also applies to: 255-308, 544-544

apps/web/lib/zod/schemas/programs.ts (1)

88-88: Update schema to reflect complete migration or fix bulk import flow.

The TODO comment about updating groupId to required after migration has been removed, but the field remains .nullish().

The primary enrollment creation path (create-program-application.ts:235) always populates groupId from a valid group object. However, the bulk import path (complete-program-applications.ts:91) uses optional chaining (programApplication?.partnerGroup?.id), allowing null values to be persisted.

Since the learning confirms that default partner groups always exist when programs are created, verify:

1. Whether the bulk import path should also guarantee a groupId (e.g., by falling back to default group)
2. If yes, update the schema to z.string() (required) and fix complete-program-applications.ts
3. If no, restore the TODO comment explaining why null is valid

apps/web/ui/webhooks/add-edit-webhook-form.tsx (2)

124-136: Verify program is loaded before filtering program-level triggers.

When defaultProgramId exists but program is still loading, program?.payoutMode evaluates to undefined. The filter condition program?.payoutMode !== "internal" then evaluates to true, causing payout.confirmed to be included even when the program's payoutMode might actually be "internal" once loaded.

Consider adding a check for program loading state:

 const availableWebhookTriggers = useMemo(
   () => [
     ...WORKSPACE_LEVEL_WEBHOOK_TRIGGERS,
     ...(defaultProgramId
       ? PROGRAM_LEVEL_WEBHOOK_TRIGGERS.filter(
           (trigger) =>
             trigger !== "payout.confirmed" ||
-            program?.payoutMode !== "internal",
+            (program && program.payoutMode !== "internal"),
         )
       : []),
   ],
-  [defaultProgramId, program?.payoutMode],
+  [defaultProgramId, program],
 );

This ensures that if program is undefined, the condition evaluates to false and payout.confirmed is excluded until the program data is available.

---

216-216: LGTM!

The updated rendering logic correctly uses availableWebhookTriggers to display both workspace-level and program-level triggers when a program is available.

apps/web/lib/webhook/types.ts (1)

7-7: LGTM!

The new PartnerApplicationWebhookPayload type is correctly defined and properly integrated into the WebhookEventPayload union. The implementation follows the established pattern for other webhook payload types.

Also applies to: 22-24, 42-42

apps/web/lib/webhook/schemas.ts (1)

10-10: LGTM!

The new partner.application_submitted webhook event variant is well-structured and follows the established pattern for other webhook events in this file. The OpenAPI metadata is properly configured with appropriate ref and description.

Also applies to: 123-134

apps/web/lib/partners/complete-program-applications.ts (4)

104-121: LGTM!

The workspace fetching and mapping logic is well-implemented. Using a Map for quick lookup by defaultProgramId is efficient, and the subsequent conditional check ensures webhooks are only sent for programs that have associated workspaces.

---

132-160: LGTM!

The logic for computing missing social fields is correct. It properly identifies fields present in the application but absent in the partner profile, and the hasMissingSocialFields check efficiently determines whether any update is needed.

---

162-167: LGTM!

The applicationFormData formatting is well-structured. Using the helper function and converting empty strings to null provides a clean, consistent webhook payload format.

---

196-213: Webhook emission logic is well-structured, but note the status override.

The conditional webhook sending and payload construction are well-implemented. The check on line 197 ensures webhooks are only sent when a workspace exists.

Note that line 208 explicitly sets status: "pending", which overrides any status from programEnrollment. This appears intentional but ensure it aligns with the expected webhook payload for newly submitted applications.

apps/web/lib/webhook/constants.ts (2)

17-24: LGTM!

The introduction of PROGRAM_LEVEL_WEBHOOK_TRIGGERS is well-structured and properly integrated into the WEBHOOK_TRIGGERS array. The categorization clearly separates workspace-level, program-level, and link-level triggers.

Also applies to: 30-30

---

34-50: LGTM!

The typed WEBHOOK_TRIGGER_DESCRIPTIONS as a Record provides excellent type safety, ensuring all triggers have corresponding descriptions. The description for "partner.application_submitted" is clear and consistent with other trigger descriptions.

apps/web/lib/partners/format-application-form-data.ts (2)

4-11: LGTM! Good refactor to use a named interface.

The introduction of FormDataKeyValue improves type reusability and makes the return type clearer. The filter and cast on line 52 correctly removes the null values returned for "website-and-socials" field types.

---

55-72: LGTM! Clean extraction and normalization.

The new function correctly extracts website and social fields from the application form data and appropriately normalizes empty strings to null for downstream webhook payloads.

apps/web/lib/actions/partners/create-program-application.ts (5)

8-18: LGTM! Clean integration of webhook dependencies.

The new imports for formatting utilities and webhook publishing are appropriate, and the workspace selection correctly fetches only the fields needed for webhook dispatch (id and webhookEnabled).

Also applies to: 136-141

---

172-177: LGTM! Workspace threading is clean and type-safe.

The workspace parameter is correctly passed through to createApplicationAndEnrollment, and the use of Pick<Project, "id" | "webhookEnabled"> provides precise typing without exposing unnecessary fields.

Also applies to: 197-209

---

218-242: LGTM! Correctly captures programEnrollment for webhook payload.

Good change from discarding the enrollment result (_) to capturing it as programEnrollment, which is needed for constructing the webhook payload later.

---

246-251: LGTM! Data transformation is correct.

The mapping from title to label aligns with the webhook schema requirements, and empty string normalization to null is appropriate for the webhook payload.

---

272-287: The webhook payload structure is correct and safe.

Verification confirms the spread operator field merge order produces the expected payload structure. The partnerApplicationWebhookSchema uses .pick() to select only specific fields from each schema:

• EnrolledPartnerSchema.pick({id, name, companyName, email, image, description, country})
• ProgramEnrollmentSchema.pick({groupId, status})
• PartnerOnlinePresenceSchema.pick({website, youtube, twitter, linkedin, instagram, tiktok})

These picked fields are all distinct—there are no overlaps. The schema validation via .parse() enforces this subset constraint, ensuring the final webhook payload contains only the expected fields regardless of spread order. The formatWebsiteAndSocialsFields() function correctly returns fields matching the picked online presence schema fields.

The explicit id: partner.id assignment safely ensures the partner's ID is used, and any field overwrites from the spreads are intentional (e.g., form data overrides). The code is correct as-is.