Email as a Personal API

Home » Blog » Ideas » Email as a Personal API

Some time ago I came across a concept by Marc Bevand advocating email as a Decentralized API to Personal Information. In this post he outlines the idea that – email being such a pervasive tool to the extent that nearly everyone uses it – a personal, distributed and decentralized API layer could be built on top of it.

The basic idea is this: Email could be used as a protocol for transactions and automatically exchanging information. Take these use cases for example:

  1. Automatically setting up email encryption with public key encryption tools such as GPG. Exchanging public keys today still is a largely manual, cumbersome and error-prone process. This is the most important reason for the still poor adoption rate for encryption tools.
  2. If I send an email to I automatically get a reply with John Doe’s business card as a vCard file containing just the contact data John would like to be publically available.
  3. If I send the same email from an email address that ends in I receive more complete contact information for use by John’s colleagues.
  4. A request to could return John’s public CV. Just like the business card data this information could be filtered according to the sender’s address, email headers or basically any other rule that’s already possible with today’s email clients’ filtering features.
  5. Social network interactions. Being used by almost everyone on the Internet email is by far the largest social network eclipsing even Facebook, plus it’s decentralized meaning there’s no central entity that sells your data, decides which content is good for you or shares your private messages with the government (given you take care of proper encryption, see #1)
  6. Transactional email. All that tedious to and fro with registering for a new service, verifying your email address, sending password reset emails, subscribing to newsletter could to a large extent be automated by rule-driven processes. Combined with services such as 1Password Watchtower it’d even be possible to swiftly and automatically act on security issues.

The possibilities are almost limitless though there are some limitations imposed by the common protocols used for email: Currently, with POP3, IMAP and SMTP alone it’s not possible to verify the sender of an email. Email address spoofing is rampant in the spam ‘industry’. Not being able to verify the sender of an email effectively prohibits use cases involving potentially sensitive data such as #3 and #4

Public key encryption could be used for circumventing these shortcomings but admittedly und very much unfortunately we’re not there yet in terms of both adoption and integration with existing email clients.

Anyway, the concept of using email as a decentralized API for personal data is very intriguing, both from a UX perspective but even more so because decentralization of data and distributed computing in my opinion simply is the right approach for the future.

The author has set up some demo rules and canned responses. You can try it out by sending an email with one of the following subjects to

  • autoresponder:online_identity returns information typically needed by a web forum: avatar image, language, etc
  • autoresponder:fullname returns a full name
  • autoresponder:phone returns a phone number

Leave a Comment

* Checkbox GDPR is required


I agree

By continuing to browse the site you agree to our use of cookies. Privacy Policy

Privacy Preference Center

Strictly necessary

These cookies are necessary for the site to function.

PHPSESSID: Preserves user session state across page requests.

__cfduid: Used by the content network, Cloudflare, to identify trusted web traffic.



Remembers the user's submitted data when a comment is submitted in a blog post. The purpose is to aut o-populate form fields for subsequent comments, in order to save time for the user.



Statistic cookies help us to understand how visitors interact with our websites by collecting and reporting information anonymously.

_ga: Registers a unique ID that is used to generate statistical data on how the visitor uses the website.

_gat: Used by Google Analytics to throttle request rate.

_gid: Registers a unique ID that is used to generate statistical data on how the visitor uses the website.

collect: Used to send data to Google Analytics about the visitor's device and behaviour. Tracks the visitor across d evices and marketing channels.



We use Wordfence to secure our website against hacking attempts:


Close your account?

Your account will be closed and all data will be permanently deleted and cannot be recovered. Are you sure?