pn-new-crm/docs/website-refactor.md

Website → CRM wiring refactor

The website/ subrepo (Nuxt) currently writes inquiry submissions to NocoDB. The new CRM exposes its own public ingestion endpoints, so the website needs to be re-pointed at the CRM and the website's local server-side helpers can eventually be retired.

This document describes what needs to change in the website repo. Nothing here applies to the CRM repo — that side is already done.

Endpoints the CRM now exposes

Both are unauthenticated, IP-rate-limited (5/hour), and require an explicit port id (query param ?portId=… or header X-Port-Id).

Form intent	New CRM endpoint	Old NocoDB target
Berth interest	POST /api/public/interests	Interests (NocoDB)
Residential interest	POST /api/public/residential-inquiries	Interests (Residences)

Notification emails (client confirmation + sales-team alert) are sent by the CRM itself when these endpoints succeed, so the website's sendRegistrationEmails helper (server/utils/email.ts) is no longer required for these flows.

Required changes in the website repo

1. New env vars

Add to .env and the deploy environment:

PN_CRM_BASE_URL=https://crm.portnimara.com
PN_CRM_PORT_ID=<uuid of the Port Nimara port row in CRM>

PN_CRM_BASE_URL defaults to the prod CRM. In dev it can point to the local tunnel (shoulder-contain-…trycloudflare.com) so submissions hit a dev DB.

2. Refactor server/api/register.ts

Today the file owns both the berth and residence branches and writes to NocoDB directly. After the refactor, both branches just relay to the CRM:

const baseUrl = process.env.PN_CRM_BASE_URL;
const portId = process.env.PN_CRM_PORT_ID;

if (category === 'Residences') {
  await $fetch(`${baseUrl}/api/public/residential-inquiries?portId=${portId}`, {
    method: 'POST',
    body: {
      firstName: body.first_name,
      lastName: body.last_name,
      email: body.email,
      phone: body.phone,
      placeOfResidence: body.address,
      preferredContactMethod: body.method_of_contact, // 'email' | 'phone'
      notes: body.notes,
      // preferences: collect via new optional textarea (see section 4)
    },
  });
  return { success: true };
}

// Berth branch
await $fetch(`${baseUrl}/api/public/interests?portId=${portId}`, {
  method: 'POST',
  body: {
    // map to the CRM's publicInterestSchema (see src/lib/validators/interests.ts)
    firstName: body.first_name,
    lastName: body.last_name,
    email: body.email,
    phone: body.phone,
    address: body.address,
    berthSize: body.berth_size,
    berthMinLength: body.berth_min_length,
    berthMinWidth: body.berth_min_width,
    berthMinDraught: body.berth_min_draught,
    yachtName: body.berth_yacht_name,
    preferredMethodOfContact: body.method_of_contact,
    specificBerthMooring: body.berth, // optional, links interest to a specific berth
  },
});
return { success: true };

The reCAPTCHA verification stays in the website handler — the CRM trusts the website to gate its public endpoints.

3. Retire dead code

After step 2, the following can be deleted from the website:

• server/utils/websiteInterests.ts
• server/utils/residentialInterests.ts
• server/utils/nocodb.ts
• The NocoDB-specific call sites in server/utils/email.ts (the CRM sends its own confirmation/alert emails)
• NocoDB env vars (NOCODB_*)

The Nuxt /api/berths route stays as-is — it reads from the directus_items.berths collection for the public site, not the CRM.

4. Form additions on pages/register.vue

The current residence branch only collects contact info. The CRM accepts an optional preferences field (free-text) and notes field. Add a "Preferences" textarea inside the residences block of components/pn/specific/website/register/form.vue:

<transition name="fade-down">
  <div v-show="interest === 'residences'">
    <vee-field
      as="textarea"
      class="form-input py-3 px-0 md:text-lg border-0 border-t border-davysgrey ..."
      placeholder="Tell us what you're looking for (unit type, budget, timeline)"
      name="residence_preferences"
      :disabled="loading"
    />
  </div>
</transition>

Append preferences: body.residence_preferences in the POST body in server/api/register.ts.

5. Stand up a residential-only residences.vue form (optional)

Today the residences interest is captured on register.vue via a radio. If the marketing team wants a dedicated CTA on residences.vue, add a small inline form using the same submit handler from step 2. No new endpoint — this is purely a UX addition.

Deployment order

1. CRM first: deploy this repo, ensure /api/public/interests and /api/public/residential-inquiries are reachable from the website host.
2. Verify in CRM: configure Inquiry Contact Email and (for residential) Residential Notification Recipients per port in admin → settings.
3. Smoke test from a dev tunnel (curl the public endpoints with a JSON payload). Confirm rows land in clients/residential_clients and notification emails are received.
4. Then deploy website changes (sections 1–3 above). The form submissions immediately start landing in the new CRM.
5. Cut-over note: once the website is pointed at the CRM, leave the NocoDB tables read-only as a historical archive. Don't delete them until prod data has been imported into the new CRM (see "Prod data import strategy" task #59 in the task list).

Open questions

• Port routing for multi-port deploys: today the website only knows about Port Nimara. If/when the website serves multiple ports, the portId resolution needs to happen per-domain or per-route, not a single env var.
• Brand/email domain: confirm whether residential confirmations should send from the same noreply@letsbe.solutions address as marina, or a dedicated residential mailbox. The CRM uses SMTP_FROM, which is global.