curl -X PUT https://portaly.ai/api/creator-email/templates/welcome_free \
  -H "Authorization: Bearer ${PORTALY_API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{ "enabled": false }'

{ "enabled": true }

Avoiding double emails. If the vibe coder has their own welcome / upgrade / cancellation flow, disable the matching template before wiring

syncToPortaly

(see

portaly-user

) or the payment callback handler (see

portaly-payment

). Otherwise every existing user the first bulk sync touches gets one Portaly

welcome_free

, and every successful checkout gets one Portaly

welcome_paid

on top of the vibe coder's own message.

Portaly Vibe sends invitation emails on behalf of creators. The CTA in those emails goes through Portaly for click tracking, then redirects to a waitlist landing page. You have two options:

• A. Hosted (recommended for fastest launch) — Use Portaly's hosted waitlist page. No server-side work. The page is generic but functional. Best when you don't have a brand reason to host it yourself.
• B. Self-hosted (recommended for brand consistency) — Host

  /waitlist/[creatorSlug]

  on your own domain. Full control over UI, copy, and post-signup flow. Requires implementing the page and registering your

  appBaseUrl

  with Portaly.

Which would you like? You can switch later.

references/hosted-cta.md

1. Confirm

   appBaseUrl

   is empty (it is by default). If the merchant previously enabled Mode B, clear it:
   • Vibe MCP (preferred): call

     vibe_update_brand

     with

     { "appBaseUrl": "" }

     — no API key needed.
   • REST fallback:

     PUT /api/creator-subscription/config

     with

     { "appBaseUrl": "" }

     .
2. Find the creator's slug —

   GET /api/creator-subscription/config

   returns the merchant config. The slug also appears in the Portaly Vibe Dashboard.
3. Embed the CTA URL in the vibe coder's app, email signature, social bio, etc.:

   https://portaly.ai/waitlist/{creatorSlug}

4. No server-side implementation needed. Portaly serves the page, accepts the signup form, and stores the waitlist row.

vibe_update_brand

{ "appBaseUrl": "https://your-app.example.com" }

PORTALY_API_KEY

curl -X PUT https://portaly.ai/api/creator-subscription/config \
  -H "Authorization: Bearer ${PORTALY_API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{ "appBaseUrl": "https://your-app.example.com" }'

• Must be HTTPS
• Max 255 characters
• Trailing slashes are stripped automatically
• Empty string clears the field (= switches back to Mode A)

/waitlist/{creatorSlug}

ref

utm_source

invitation

utm_campaign

utm_content

• GET https://portaly.ai/api/waitlist/{creatorSlug}

  — returns

  { data: { creator: { slug, merchantName }, count } }

  . Use it to render the headline (

  Join {merchantName}'s waitlist

  ) and signup count.

• POST https://portaly.ai/api/waitlist/{creatorSlug}

  — body

  { email, name?, source?, ref? }

  . Returns

  { data: { joined, alreadyOnList, creator } }

  .

429

1. From the creator's dashboard, send a test invitation email to your own inbox.
2. Click the CTA link in the email.
3. The browser should redirect through

   portaly.ai/r/...

   and land on

   https://your-app.example.com/waitlist/{slug}?ref=...&utm_source=invitation&...

   .
4. Submit the form; check the Portaly Dashboard's waitlist tab to confirm the row.
5. If

   syncToPortaly

   is wired, the user should also appear in the Dashboard's user list.

1. Confirm intent with the creator — what's the campaign for? Is there an existing draft, or starting fresh? Call

   vibe_list_campaigns

   to check.
2. Create the draft with

   vibe_create_campaign

   . Pass any context the creator gives (campaign angle, tone, must-mention deadline) into

   aiContext

   . The campaign starts empty — no subject, no body, no recipients.
3. Hand recipient import to the dashboard. Tell the creator:

   Recipient import is in the Vibe dashboard's Email → Outreach tab. Open your campaign there, upload a CSV / Google Sheet / paste addresses, then come back and tell me when you're done. Recipient management is intentionally not exposed via MCP — column-mapping a CSV in chat is fragile and the dashboard already has a preview UI.

4. Draft

   subject

   +

   bodyHtml

   with the creator. Constraints:
   • Subject ≤ 255 chars.
   • Body is HTML, ≤ 100,000 chars.
   • Must include

     {inviteUrl}

     somewhere in the body — that's the tracked invitation link the recipient clicks. Without it, you've shipped a CTA-less email.
   • Always-available placeholders:

     {customerName}

     ,

     {merchantName}

     ,

     {inviteUrl}

     . Any extra column the creator imported is exposed as

     {slug}

     — confirm those slugs with the creator before referencing them.
5. Confirm with the creator before sending. Sending is irreversible and burns from their monthly quota + purchased credits. Show the subject, the rendered body (or a preview link), the recipient count.
6. Call

   vibe_send_campaign

   with

   campaignId

   ,

   subject

   ,

   bodyHtml

   . Switch on the

   outcome

   :

enqueued

vibe_get_campaign_analytics

campaign_not_found

vibe_list_campaigns

no_recipients

quota_exceeded

remainingQuota

needed

1. Read analytics with

   vibe_get_campaign_analytics(campaignId)

   once delivery has had time to register (a few minutes). The funnel goes

   imported → enqueued → delivered → opened → clicked → bounced → complained → signedUp → converted

   .

   signedUp

   only populates if the recipient hits the waitlist landing page (Mode A or B above);

   converted

   only fills if they later subscribe via

   portaly-payment

   .

• Always include

  {inviteUrl}

  . The whole point of the campaign is the click — without the placeholder, recipients see a wall of text with no CTA.
• Confirm the recipient count before sending. A misplaced 0 in a CSV column or a stale draft can lead to mass-emailing the wrong list. Read it back to the creator: "About to send to N people imported on <date>. Proceed?"
• Do not call

  vibe_send_campaign

  repeatedly to "retry" a

  quota_exceeded

  . That's a soft fail — the creator must top up first. Retrying without action just churns calls.
• Subject lines for follower outreach matter more than for transactional email. Push back if the creator gives a generic "Update from {merchantName}" — suggest something tied to the campaign's angle.

• HTTPS only for

  appBaseUrl

  .

  http://

  is rejected by Portaly.

  localhost

  cannot be used in production — for local dev use ngrok / Cloudflare Tunnel.
• Path is fixed:

  /waitlist/{creatorSlug}

  exactly. Do not alias to

  /signup

  ,

  /join

  , etc. — Portaly redirects to the literal

  /waitlist/{slug}

  path.
• Click tracking always runs through Portaly. Do not try to point the email CTA directly at your own domain to "skip"

  /r/{code}

  — you'll lose click analytics and rate limiting.
• Preserve UTM and

  ref

  query params on the POST body in Mode B. Dropping them breaks campaign attribution on Portaly's side.
• Do not skip user sync. A signup that's only stored on Portaly's waitlist row but missing from the creator's user list creates support pain when the creator wonders why a known follower doesn't show up in their dashboard.

• Always confirm Mode A vs Mode B with the human user before doing setup work.
• For Mode A, prefer one short paragraph + the CTA URL. No code templates needed.
• For Mode B, lean on

  references/self-hosted-waitlist.md

  instead of inlining all the code.
• Keep secrets (API keys) out of chat — write

  .env

  instructions instead.

• references/hosted-cta.md

  — Mode A snippets and CTA placement examples.

• references/self-hosted-waitlist.md

  — Mode B implementation templates for Next.js, React SPA, and plain HTML.

• references/sending-campaigns.md

  — End-to-end campaign send via Vibe MCP, with body templates and outcome handling.