Member personal contact list
The member's own address book — people saved from event badge scans plus manual adds. Person-scoped (follows the member across organizations, never the org's CRM); add is idempotent per email; remove is owner-authorized soft delete. External ids are opaque public_identifiers.
If you are building a front end
Your front end calls this over the same-origin `/api/v1` proxy — no backend code to write, no schema to design. Endpoints: GET/POST /api/v1/member/contacts, DELETE /api/v1/member/contacts/:contactPublicIdentifier.
Bring any front end — hand-written, or generated with Lovable, v0, Bolt, Claude, or Cursor. You get auth, a multi-tenant database, payments through your own Stripe, and email/SMS without writing or hosting a backend.
- How to turn it on
- On by default in the member portal; hide via the portal capability map key 'contacts'.
- Who can use it
- member session (genesis_member_session); FE capability key 'contacts'.
- The API behind it
GET/POST /api/v1/member/contacts, DELETE /api/v1/member/contacts/:contactPublicIdentifier- Where it lives
- /m/[portalSlug]/contacts
See it in context
CRM & pipeline — the full walkthrough, step by step: Every lead, contact, and deal — one live system your website feeds directly.
Machine-readable
This page is generated from our published capability catalog. Point your AI assistant at /features.json (or /llms.txt) and it can read every feature, how to enable it, and the endpoints behind it — then build against them.