You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I want to review which hosts I have opted out of, stop future invitations from a host, or reverse an earlier opt-out without blocking that person or removing our shared Partiful history.
Problem
Partiful has an invitation-specific Opt-Out List, but the CLI cannot read or manage it. This is a distinct relationship from blocking, declining one event, notification settings, or unsubscribing from all Partiful communications.
Verified product behavior
The current Partiful app displays Opt-Out List in account settings. Its empty state reads:
😁 All parties welcome
You haven't opted out of any invites
Partiful's current Help Center says:
A user can open a host's profile, use the three-dot menu, and choose Opt out of invites.
A user can open an invitation, use the menu near the date and time, and choose Opt out of all invites.
A user can reply X to an invitation notification text.
After opting out, the user will no longer receive invitations from that host.
Partiful separately describes this as opting out of invitations from a Mutual or blocking them.
This establishes that list entries represent invitation opt-outs associated with a host or Mutual. It is not a second Block List.
CLI source contains no opt-out implementation. The inspected current-user response did not expose an opt-out collection. Bundle and route searches have not yet recovered a verified list or mutation contract. No opt-out mutation was attempted during this audit.
Proposed experience
Keep this under an invitation-specific account namespace:
Exact selectors and commands should follow the verified API contract. If Partiful exposes the action only from a host or event context, mirror that model instead of forcing this sketch.
Normal JSON should return safe display data such as the host's name and profile image when available. Raw account identifiers, phone numbers, contact details, and auth metadata must stay out of normal output.
Scope boundaries
Invitation opt-outs are separate from account blocks, one-event RSVP responses, event removal, notification-channel settings, SMS subscription status, and legal messaging preferences.
Do not claim an opt-out prevents event-link access, profile visibility, existing-event updates, or non-invitation communication unless verified.
Do not claim that restoring an entry causes missed invitations to be resent.
Do not treat replying X as a general SMS unsubscribe without first proving the exact server behavior.
Do not expose private relationship state in unrelated profile, contact, guest, or Mutual output.
Add and remove mutations require confirmation, --dry-run, and read-back.
Discovery needed
Capture a controlled, consented opt-out flow and identify the canonical list, add, and remove operations. Establish the stored entity shape, whether entries are keyed by host or inviting user, pagination, duplicate behavior, reversal semantics, visibility effects, SMS X behavior, and what happens to pending or future invitations.
A controlled test must use two accounts where the inviter expects the opt-out. Do not test against an unsuspecting Mutual.
Acceptance criteria
account invite-opt-outs list returns structured, privacy-safe JSON.
Empty state is deterministic and consistent with “You haven't opted out of any invites.”
Add and remove use the canonical server operations discovered from the current product.
Mutations support --dry-run, explicit confirmation, and post-mutation read-back.
Duplicate add, absent remove, unauthorized, rate-limit, and read-back mismatch cases produce structured errors.
Normal output omits phone numbers, contact details, raw internal IDs, and auth metadata.
Tests cover list, empty state, add, remove, duplicate/idempotent behavior, privacy redaction, and failure responses using sanitized fixtures.
One controlled two-account integration test verifies that opting out prevents a later direct invitation from that host, then verifies the documented reversal behavior.
Help text clearly distinguishes invitation opt-outs from Block List and global communication preferences.
Related work
#103 covers explicit account blocking. #76 covers Mutual discovery. This issue covers only the host-specific future-invitation opt-out relationship.
User scenario
I want to review which hosts I have opted out of, stop future invitations from a host, or reverse an earlier opt-out without blocking that person or removing our shared Partiful history.
Problem
Partiful has an invitation-specific Opt-Out List, but the CLI cannot read or manage it. This is a distinct relationship from blocking, declining one event, notification settings, or unsubscribing from all Partiful communications.
Verified product behavior
The current Partiful app displays Opt-Out List in account settings. Its empty state reads:
Partiful's current Help Center says:
Xto an invitation notification text.This establishes that list entries represent invitation opt-outs associated with a host or Mutual. It is not a second Block List.
Sources:
Current CLI gap
CLI source contains no opt-out implementation. The inspected current-user response did not expose an opt-out collection. Bundle and route searches have not yet recovered a verified list or mutation contract. No opt-out mutation was attempted during this audit.
Proposed experience
Keep this under an invitation-specific account namespace:
Exact selectors and commands should follow the verified API contract. If Partiful exposes the action only from a host or event context, mirror that model instead of forcing this sketch.
Normal JSON should return safe display data such as the host's name and profile image when available. Raw account identifiers, phone numbers, contact details, and auth metadata must stay out of normal output.
Scope boundaries
Xas a general SMS unsubscribe without first proving the exact server behavior.--dry-run, and read-back.Discovery needed
Capture a controlled, consented opt-out flow and identify the canonical list, add, and remove operations. Establish the stored entity shape, whether entries are keyed by host or inviting user, pagination, duplicate behavior, reversal semantics, visibility effects, SMS
Xbehavior, and what happens to pending or future invitations.A controlled test must use two accounts where the inviter expects the opt-out. Do not test against an unsuspecting Mutual.
Acceptance criteria
account invite-opt-outs listreturns structured, privacy-safe JSON.--dry-run, explicit confirmation, and post-mutation read-back.Related work
#103 covers explicit account blocking. #76 covers Mutual discovery. This issue covers only the host-specific future-invitation opt-out relationship.