We’ve talked about how the presence of webhooks as part of API operations is usually the first place platforms begin investing in event-driven API architecture. Another common pattern we are seeing as we continue to study the event-driven approach of API providers is a user events API, providing an API for accessing, webhooks for subscribing, and real-time API for accessing all the events that occur across a users account. Providing a single place to tune into all the meaningful events for a user, or potentially a group of users of a platform.
You can see an example of this in action over at the document storage API platform Box, with their events API endpoints which, “provides an API endpoint at /events that presents a stream of two different types of events, called user events and admin events. Admin events are those events that are retrieved when you request a stream_type of admin_logs. User events are all other events.” Here is a list of the events they are providing access to:
– ITEM_CREATE – A folder or File was created
– ITEM_UPLOAD – A folder or File was uploaded
– COMMENT_CREATE – A comment was created on a folder, file, or other comment
– COMMENT_DELETE – A comment was deleted on folder, file, or other comment
– ITEM_DOWNLOAD – A file or folder was downloaded
– ITEM_PREVIEW – A file was previewed
– ITEM_MOVE – A file or folder was moved
– ITEM_COPY – A file or folder was copied
– TASK_ASSIGNMENT_CREATE – A task was assigned
– TASK_CREATE – A task was created
– LOCK_CREATE – A file was locked
– LOCK_DESTROY – A file was unlocked. If a locked file is deleted, the source file will be null.
– ITEM_TRASH – A file or folder was marked as deleted
– ITEM_UNDELETE_VIA_TRASH – A file or folder was recovered out of the trash
– COLLAB_ADD_COLLABORATOR – A collaborator was added to a folder
– COLLAB_ROLE_CHANGE – A collaborator had their role changed
– COLLAB_INVITE_COLLABORATOR – A collaborator was invited on a folder
– COLLAB_REMOVE_COLLABORATOR – A collaborator was removed from a folder
– ITEM_SYNC – A folder was marked for sync
– ITEM_UNSYNC – A folder was un-marked for sync
– ITEM_RENAME – A file or folder was renamed
– ITEM_SHARED_CREATE – A file or folder was enabled for sharing
– ITEM_SHARED_UNSHARE – A file or folder was disabled for sharing
– ITEM_SHARED – A folder was shared
– ITEM_MAKE_CURRENT_VERSION – A previous version of a file was promoted to the current version
– TAG_ITEM_CREATE – A Tag was added to a file or folder
– ENABLE_TWO_FACTOR_AUTH – 2 factor authentication enabled by user.
– MASTER_INVITE_ACCEPT – Free user accepts invitation to become a managed user.
– MASTER_INVITE_REJECT – Free user rejects invitation to become a managed user.
– ACCESS_GRANTED – Granted Box access to account.
– ACCESS_REVOKED – Revoke Box access to account.
– GROUP_ADD_USER – Added user to group
– GROUP_REMOVE_USER – Removed user from group
Providing a rich list of document related events to tune into. We are working to aggregate and understand the list of event types available via a different platform, which usually accompanies webhook subscriptions. Now we’ll be tagging API providers who also offer a user event API, webhook, or real-time API in this way. It is a common pattern we are beginning to see emerge from API providers who are further along in their journey and beginning to invest more in their event-driven architecture. It is a healthy API pattern we’d like to see more of from the API providers we are working with, and something we’ll include in our storytelling, consulting, and workshops.
Many API platforms have a user resource, making a user events API, webhooks, and streams a potentially ubiquitous event-driven architectural pattern. Right now we are just seeing it with the API providers who are the most mature, but we are predicting in coming years that more API providers will be supporting it as a feature. It just makes sense for users to be able to tune into the most meaningful events that occur across their accounts, as well as allow system administrators and developers to tune into the events across the users they manage with their applications and systems. We’ll keep documenting API providers that we find who are implementing this approach, and eventually publish a white paper sharing what we’ve learned from studying the leaders in the event-driven API architecture evolution.
