Acoustic Exchange endpoints connect to and communicate with Acoustic Exchange through various RESTful APIs. The specific APIs that you call as an event provider or consumer depend on the type of endpoint you create.

You declare an endpoint type as part of the endpoint provisioning and review process when you define the Acoustic Exchange application on which to base your endpoint. After provisioning your endpoint, you can provide or consume event data through Acoustic Exchange by implementing various Acoustic Exchange APIs.

All API requests to Acoustic Exchange require that the request header include an authorization bearer that is a customer-supplied authentication key. Providing the authentication key verifies that you are calling the API on behalf of a specific Acoustic Exchange user account.

Event syndication as a PUSH OR PULL exchange

Acoustic Exchange requires that, as an event producer or consumer endpoint, you indicate whether the data exchange occurs as a push to Acoustic Exchange or the endpoint, or as a pull from Acoustic Exchange or the endpoint.

The distinction between event sharing as push or pull determines how the Acoustic Exchange APIs are called or implemented by the endpoint. The choice usually depends on whether the endpoint is a cloud-based (or SaaS) application, or an application that is installed in a physical network behind a firewall. Installed applications are often called On Premise applications.

All Acoustic Exchange endpoints publish event data to Acoustic Exchange as a PUSH-type event publisher.

An endpoint that receives event data that Acoustic Exchange sends as soon as it is available is considered a PUSH-type event consumer.

An endpoint that receives event data only when it specifically requests the data from Acoustic Exchange is considered a PULL-type event consumer.

As an endpoint provider, you must declare an endpoint type as part of the endpoint provisioning and review process when you use the Acoustic Exchange Integration Manager to define the Acoustic Exchange application on which to base your endpoint.

Event publisher: PUSH

Acoustic Exchange provides APIs that can be called by endpoints that produce events.

Event producers are also referred to as event publishers. As part of the endpoint provisioning process, you must identify the endpoint as an event producer and specify the events that you want to publish from the endpoint. Publishing events to Acoustic Exchange also requires an API call to Acoustic Exchange.

The following table identifies the actions you perform as an event producer by calling APIs that are hosted by Acoustic Exchange.

Event consumer: PUSH

Acoustic Exchange provides APIs that can be called by endpoints that consume events.

Event consumers are also referred to as event subscribers. As part of the endpoint provisioning process, you must identify the endpoint as an event destination.

The following table identifies the typical actions you perform as an event consumer.

Event consumer: PULL

Acoustic Exchange can temporarily store event data in a file. You can use the v1/eventfiles API to retrieve the file from Acoustic Exchange.

Acoustic Exchange supports business cases where Acoustic Exchange receives event data from an event publisher as an uploaded file. AlthoughAcoustic Exchange cannot be used as a file repository, it can store the uploaded events file temporarily.

You can make a series of calls to v1/eventfiles to find a file and move its contents to a directory that you maintain. In the series of API calls, you identify the files in Acoustic Exchange that contain event data, retrieve the contents of a specific file, and then clean up the file store after you receive all of the files. Acoustic Exchange stores event data in .event files and returns the file contents in the API response as a binary stream.

The following table identifies the series of calls you can make as a Pull-type event consumer.