Read, star, move and trash

Change an email in the user’s mailbox.

Changes are made at the provider, so the user sees them in Gmail or their email app too.

Mark as read, star, move

curl -X PATCH "$EE_URL/api/v1/emails/email_94a0d77db739407e932c3b97fef44aac" \
  -H "X-API-KEY: $EE_KEY" -H "Content-Type: application/json" \
  -d '{ "unread": false, "starred": true, "folder": "ARCHIVE" }'

Send only what you want to change.

unread · boolean

false marks it read, true unread.

starred · boolean

Flag (IMAP) or star (Gmail).

folder · string

Move to a folder: its fld_… id, provider id, or a role such as ARCHIVE, INBOX, SPAM. For Gmail (IMAP), moving to a label folder adds that label and removes the one it came from; Gmail has no ARCHIVE folder over IMAP.

The response is the updated email object. The email keeps its id when it moves. An email.update event follows, with the updated email.

Move to trash

curl -X DELETE "$EE_URL/api/v1/emails/email_94a0d77db739407e932c3b97fef44aac" -H "X-API-KEY: $EE_KEY"

Response

{ "object": "EmailDeleted", "id": "email_94a0d77db739407e932c3b97fef44aac" }

The email goes to the mailbox’s Trash: its role becomes TRASH, and an email.update event follows. The email stays in the API while it’s in Trash. The provider empties the trash on its own schedule (Gmail after 30 days). When it’s gone for good, you receive email.delete.

Changes made elsewhere

When the user reads, stars, moves or deletes an email in their own email app, the engine picks it up on the next sync and sends the same events: email.update for a change or a move, email.delete when it’s deleted for good.