SQS Message Queue vs. REST API

The Fathom API designs the data to be programmatically extracted from the system in two ways. Depending on the user application, you benefit from the "push" SQS messaging service or the "poll" Fathom web service API. 


With AWS SQS, messages can be processed asynchronously. The messaging queue decouples the producer and the consumer of the messages in that they do not have to be online at the same time to function. Once the SQS queue is set up, event processor code can write each event’s or batch of events (ie. in JSON) to the SQS queue for the organization that owns the Fathom Hub doing the upload. The organization has full flexibility in developing the method in which external applications read from the SQS queue.

Amazon AWS Reference: Amazon AWS SQS

Through Fathom Control, user can "push" SQS messages to the queue. In this "push" mechanism, events that are ingested by Fathom Hub are always streamed to the queue ready for applications to consume.

SQS support is specifically enabled on a venue by venue basis when a customer adds the SQS queue to the venue configuration.  There are pre-requisites - a customer first needs to create the SQS queue. When support is configured, all events which are generated within Fathom will be forwarded to the SQS queue. 

    • In the step-by-step flow, I’d include the SQS configuration link as the first step instead of having it at the end.

The steps to enable SQS for a venue is as such:

  1. Log into Fathom Control. https://control.fathom.xyz
  2. Navigate to the “Edit Venue” screen.
  3. Enable the “Event Stream” toggle and paste in the queue’s URL.
  4. Press the “Test SQS URL” button to ensure the SQS queue is writable.  If you have something reading from the queue you should receive a test message via the SQS queue or you can view the test message via the AWS Management Console.
  5. Save your changes and future events received for your venue will be streamed to your SQS queue.

On how to setup Fathom SQS Queue: Fathom SQS Queue



Fathom API is an open and synchronous approach to extract the data. External application/system is to initiate and "poll" the data using the RESTful interface which is underpinned by the HTTPS protocol. Information and metadata are to be requested in a REST API call by the consumer and in turn the producer return the requested data in a response message (ie. JSON or comma-separated values). RESTful interface is more flexible in terms of client server compatibility, in which case your user application is not reliant on the Fathom's platform and infrastructure.

Fathom offers the HTTPS API. cURL is one of the tools to interact with API. It is also common for user to bind API calls in scripting languages including PHP, Python, R, Ruby, and Java. 

For API documentation: Fathom APIdocs


Push Poll
Asynchronous Synchronous
Compatibility: Amazon SQS protocol Compatibility: Open REST standard
High-performing between server systems Ease-of-use between server/client systems


Limitation: No guarantee on message delivery; data processing and ordering mechanism upon receive are required                                                                     


Limitation: Server and client concurrent connection  Error (based on HTTP error code) requires client-side handling                                                                                        


Upon request: Sample code to consume SQS event stream. 

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request


Please sign in to leave a comment.