Push API

overview the jomablue push api uses aws sns (simple notification service) to provide a means of pushing data out from jomablue (pub/sub), when certain types of data are added/modified currently it supports pushing out data about events, people, session attendance, and lead capture leads in jomablue the advantages of sns includes the ability for the consumer (your systems) to queue and control the rate of data flow from jomablue in addition to fanning out the data too many ingest systems which may be http endpoints, sqs queues and more there are several methods in jomablue that can trigger a sns publish these include but are not limited to creating or editing an event adding or editing categories creating or adding a person (which includes manually, via registration or via importing) sending a marketing campaign to a segment of the audience person attending a session a vendor capturing a lead faq's what is the push api? it's a modern event driven architecture and interface for customers to consume data (new and edits) from their in person and online events in realtime it allows customers to consume data where and how they desire, while giving the opportunity to dynamically react as things happen, such as trigger marketing emails or follow up calls these are managed through aws sns (simple notification service) as a pub/sub messaging service how is sns different from a traditional rest api? rest apis rely on a polling model , where customer systems must continuously request updates setting an appropriate polling frequency to suit business requirements can be tricky for events sns uses a push model , sending updates instantly as they occur why is it sent via sns? to provide flexibility and durability built into sns is automated retry logic, dead letter queues, and when coupled with services like sqs, updates can be queued and processed at speeds that suit you or fixed rate limits you have on your services it could even be used to create batches of data to insert additionally, allowing customers to subscribe puts the the control, like retry logic and control in the customers hands vs it being fixed settings set by jomablue these settings could be modified by the customer at any time lastly, as new payloads or changes are implemented they are all published through the same topic with a familiar structure, meaning there is minimal new effort to consume future data payloads that we may expose if you don't want certain data payloads, the built in filtering can exclude them from your processing where can the data end up after sns? aws sns supports the following protocols/destinations http/https (webhooks) send the payload to a web endpoint email send an email with the payload sms send an sms with the payload aws lambda functions do something with the payload aws sqs (simple queue service) queue the payload to be processed later how simple can a implementation be be? in its most basic form, customers can subscribe to our sns topic and point the destination at a http rest endpoint, so basically any payloads that we produce and publish and transformed and sent to your http endpoint a word of warning though, we send records very fast (up to hundreds per second), so you want to impose some limits in sns or sqs to not overwhelm your endpoint can i get access to historical data? sns is designed to push realtime updates, we recommend storing the data ingested via sns for your historical records