# 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:

```ts
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`:

```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.