Problem
HEY's web UI lets you open a contact and change Deliver their emails to… directly between Imbox, The Feed, Paper Trail, and Screened Out.
The CLI does not currently expose the same contact-first workflow. The closest route is clearance-oriented:
- Find the contact or search
hey screener history.
- Extract the contact's clearance ID.
- Run
hey screener approve <clearance-id> --box "The Feed".
That is cumbersome for both people and agents, and requires callers to understand the distinction between contact IDs and clearance IDs for what is conceptually a contact preference.
Proposed behavior
Add a dedicated contact command that mirrors the web UI, for example:
hey contact deliver <contact-id> --to "The Feed"
hey contact deliver <contact-id> --to "Paper Trail"
hey contact deliver <contact-id> --to "Imbox"
hey contact deliver <contact-id> --to "Screened Out"
The exact command name could also be route, designate, or an extension to contact update. It would be especially useful if the target could be resolved by contact ID or email address.
Implementation context
The SDK already exposes contact/box primitives that appear intended for this workflow:
Designations().Create(boxID, contactID) designates a contact to a box.
Contacts().Screen(contactID, status) updates screening status by contact ID.
- Box names can already be resolved by existing CLI code used by
screener approve --box.
A dedicated command could resolve the destination internally and avoid leaking clearance IDs into the user-facing workflow. Returning the contact, destination, and reverse command in structured output would also fit the CLI's existing mutation conventions.
Expected outcome
An agent should be able to translate “send future mail from this contact to The Feed” into one direct command, matching the web UI's contact-level action without first searching Screener history.
Problem
HEY's web UI lets you open a contact and change Deliver their emails to… directly between Imbox, The Feed, Paper Trail, and Screened Out.
The CLI does not currently expose the same contact-first workflow. The closest route is clearance-oriented:
hey screener history.hey screener approve <clearance-id> --box "The Feed".That is cumbersome for both people and agents, and requires callers to understand the distinction between contact IDs and clearance IDs for what is conceptually a contact preference.
Proposed behavior
Add a dedicated contact command that mirrors the web UI, for example:
The exact command name could also be
route,designate, or an extension tocontact update. It would be especially useful if the target could be resolved by contact ID or email address.Implementation context
The SDK already exposes contact/box primitives that appear intended for this workflow:
Designations().Create(boxID, contactID)designates a contact to a box.Contacts().Screen(contactID, status)updates screening status by contact ID.screener approve --box.A dedicated command could resolve the destination internally and avoid leaking clearance IDs into the user-facing workflow. Returning the contact, destination, and reverse command in structured output would also fit the CLI's existing mutation conventions.
Expected outcome
An agent should be able to translate “send future mail from this contact to The Feed” into one direct command, matching the web UI's contact-level action without first searching Screener history.