The primary API interaction is with our Events endpoint.
All events are created via POST requests from your app's front-end / backend, a 3rd party integration, or Zapier. Assuming a 200 Response, Event parameters are added to a live data feed and viewable within the Fomo dashboard. You can also Retrieve all events with the API.
This feed of Events is displayed to end-users on your website as animated notifications, based on the Application Settings you provide for a given Fomo Application.
Below are a couple Fomo notifications from Matchaeologist and Growth Marketing Conference:
Matchaeologist sends purchase orders -- Growth Marketing Conference sends ticket sales.
As you can see, the ability to sync Fomo with your branding spans as deeply as your CSS chops. :)
Understanding Events vs Templates
Fomo is built for scale, with modularity and separation of concerns top-of-mind.
For this reason, Fomo delineates Event parameters (ie: first_name, city, product_name) from a notification's message structure, ie:
"{{ first_name}} from {{ city }} just bought {{ product_name }}!"
Thus, whenever you POST an Event object hash to the Events endpoint, you'll need to include an Event Type ID, which is the Primary Key ID attribute of a Template.
This tells Fomo how to arrange the parameters you've sent, for display to end-users browsing your website.
Creating Templates
While you can CRUD EventTypes with the Fomo API, we recommend using the application UI instead -- just log in and click the Templates tab.
Pro Tip - Developer Happiness
Many of our users maintain separate Fomo app instances for their dev, staging, and production environments.
If you do this, feel free to reference the
event_type_tagin your Event POST requests (vsevent_type_id) to reduce the number of dynamic environment variables needed in your application. This merely requires giving Templates the same name during setup.