Identify Extensibility Points
Making your platform extensible starts with identifying the places within the product that your customers will be able to extend or customize. If you are already using webhooks today, you can reuse your list of webhooks as a starting point.
Some examples of extensibility points in a hypothetical CRM system could be:
- a new lead has been created,
- account information was modified,
- an e-mail must be composed before it is sent,
- payment status must be verified.
Your first design decision is to choose which call patterns your extensibility points need to support. Is this a one-way, asynchronous notification or do you expect a synchronous response that may alter further processing within your product?
For example, creation of a new lead may generate a simple invocation of the extension that sends a Slack message or adjusts state of some external system. While this happens, processing within your product can continue since it does not depend on the outcome of the extension’s execution:
In contrast, an extension that formats an e-mail body must complete execution and return the result to your product before processing can continue:
Your second design decision is to choose the format and schema of your data. How will each of the extensibility points send and receive data? While any format may be used, a vast majority of extensibility cases will be well served with JSON format for both the request and response, and JSON will be assumed for the rest of this guide.