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_tag in your Event POST requests (vs event_type_id) to reduce the number of dynamic environment variables needed in your application. This merely requires giving Templates the same name during setup.