Review requests

Members prepare an email draft, SMS text or manual review link from a CRM contact. Preparation does not send anything. A person reviews the copy and sends through the existing reviewed channel, then records Mark sent. API keys and user tokens can prepare drafts but cannot mark sent. Suppression applies to the contact and addresses; archived/merged contacts, missing channel addresses and requests inside the configured cooldown are refused. The cooldown conflict names the existing request.

Reputation shows destinations, request templates, status-filtered requests, details with private feedback and an overview. Destinations require HTTPS, support Google/Facebook/Yelp/custom, and can be reordered or deactivated without losing click history. Templates accept {{review_link}} plus existing firstName, lastName, fullName, email, orgName and dealTitle merge fields with optional fallback syntax. Contact preparation has no deal context. Unknown imported tags remain visible and block preparation until corrected.

A request progresses from prepared to sent or clicked, then feedback_received; cancellation disables its token. Marking an already clicked request sent preserves clicked/feedback status. Times and the preparing/sending/cancelling member are retained. Click rate is distinct requests ever clicked divided by all requests, including cancelled and imported history. Counts are mutually exclusive current statuses; average rating covers non-null private feedback ratings. Repeat feedback is retained as separate submissions.

Tracked links use rr1.<request-id-base64url>.<HMAC-SHA256>, a domain-separated key derived from the existing outreach secret. The database stores a unique SHA-256 token hash; rendered draft copy necessarily contains the link. Rotate the secret only with a migration plan because existing links will stop verifying. Tokens have no expiry and become invalid on cancellation or deletion. Public responses are no-store, no-referrer, noindex and strict CSP; malformed/forged/unknown/cancelled links return the app's own not-found error. Route rate limits apply per client. Tokens are censored by the proposed shared log scrubber.

One active destination redirects immediately and records a click. With zero or several, a no-JavaScript page offers every active public destination with the same markup plus a private feedback form. Each destination link records its destination and redirects only to the stored HTTPS URL; query parameters cannot override it. Feedback is optional rating 1–5 plus a comment of at most 4000 characters and is visible only to authorized org CRM readers. A click records interest, not a completed public review.

No review gating: public destinations never depend on sentiment, rating, feedback or whether the contact submitted feedback. Google's current Maps contribution policy prohibits discouraging negative reviews or selectively soliciting positive reviews (verified 2026-10-22). This requirement applies across every destination.

HighLevel's request messaging settings describe balanced/custom review links, SMS/email templates, contact actions and workflow requests (modified 2026-08-25; read 2026-10-22). The fixture here is a GoodQA synthetic export shape, not an invented HighLevel API. The mapper translates known contact/location/review-link tags, preserves and flags unknown tags, imports one destination per platform for balanced settings and imports historical requests as sent at their original timestamps. Re-import deduplicates source identities and creates no timeline drafts or outbound messages.

REST: /v1/orgs/:orgId/reputation/{destinations,settings,requests,overview}; request detail and sent/cancel actions under requests/:id. MCP reads list, overview, detail, settings and destinations; reputation_prepare drafts only. Org CRM permissions and credential resource scopes apply. Workflow action request_review {channel,ownerUserId} drafts only; events review_link_clicked and review_feedback_received publish IDs without private feedback through the existing transaction bus. Dry runs record would_apply.

Integration is supplied as exact literal registration hunks and additive SQL in the registration proposal. No provider is called, no public reviews are fetched, and no reply is posted. Paul's real reputation export and a provider decision for Google review ingestion remain MANUAL-PENDING.

Implementation references checked against official Fastify redirect documentation, route rate limits and Drizzle upserts.