Spoonity Apps
Last updated
Last updated
Our stronger focus on requires us to provide a robust point of integration between our services and external development partners.
The adoption of an model provides us with a perfect entrypoint for us to document and package added functionality.
Both first-party and third-party functional components will be packaged as "Spoonity Apps". Each "Spoonity App" package will contain at least one of three possible components:
an event trigger
a logical filter
an action
Users will be able to register their "Spoonity Apps" within the dashboard, and then configure their components.
When another user installs a "Spoonity App", all of that app's functional components (event, filters, and actions), are added to the library of components already exposed by the platform.
A suite of basic event triggers, filters, and actions will be included by default with every user's Spoonity account. "Spoonity Apps" allow our users to expand on that functionality.
As an example, let's pretend that Spoonity would not support tiers:
A vendor wants to implement a tier structure for the Loyalty program. A third-party developer could package a "Spoonity App" that contains custom filters to choose when a user is eligible to move tiers, and an action that sets a tier value as a user_metadata value.
In a case where Spoonity does support tiers, the third-party developer may instead simply package a new app that just contains additional filters that Spoonity does not support.
By default, Spoonity will include its own list of supported events that it makes available to be listened for.
Examples of these events may be things like order processed, password changed, or user registered. Vendors can then configure actions to occur when those events occur.
Very often however, our clients want to respond to events that we don't support, like social media interaction, survey responses, or visiting a store a number of times within a specific number of days.
It's impossible for us to anticipate or keep pace with these requests, so allowing third parties to provide this functionality through "Spoonity Apps" is vital.
When a third-party developer registers a new application with us, they will be provided with a special URL which will act as their event_url. The backend of their application would be responsible for sending requests to that event_url. Spoonity would interpret those requests as that event "firing", and then automatically trigger any configured "listeners" for the vendor.
When a "listener" catches an event firing, it must then decide whether an attached action should be executed.
This determination is made by any filters that are included as part of the "listener".
A filter is responsible for evaluating a single scalar criteria using data provided by the event.
Examples of filters include: number of visits in a time period, current balance, whether or not a specific metadata value exists, and more.
"Spoonity Apps" can include new filters, which are then made available to vendors to use in their listeners.
Filters are an excellent way to handle things like tier upgrades, promotion eligibility, etc.
The final step of a "listener" is to perform an action.
Common actions that we use today include: sending an email, updating a metadata value, or adding value to a customer's balance.
"Spoonity Apps" can add additional functions as actions that can meet a vendor's specific needs like: saving data to another place, pushing data to another API service, and more.
Any dashboard user will be able to register any number of new "Spoonity Apps" to their account. Once registered and configured, those apps can then be distributed through a Spoonity-hosted app library within the dashboard.
Other users can browse the library and install any apps that they think they will use or need.
No decisions have been made regarding app pricing rules or monetization behaviours.
Developers will be given the opportunity to distribute their app publicly or privately.
Public apps will appear inside the app library within the dashboard for anyone to see and install.
Private apps will require the app developer to manually add specific vendors to a list of accepted clients. Only vendors in that list will be able to see that app in the library.
Each developer will be able to brand their app. Developer information will be presented as part of the app library.