There are two primary event delivery mechanics for this style of event. These are outlined below.

HTTP Post

HTTP Post is the most appropriate delivery mechanic for almost all use cases for these events. It provides a scalable framework for data transfer.

Authentication

HTTP POST events can be configured with statically defined HTTP headers that contain the required access key for the downstream system.

It's advised that clients whitelist the AIR outgoing IP addresses.

Response Codes

The response code provided by the receiving application should be an indication that the message has been delivered. AIR requires either a 200 or 201 response code.

It is not an indication that the message has been retrieved and processed. As the data flowing can reach significant volumes, it is important that the receiving application can handle scale.

It is recommended to place a queuing mechanism behind the HTTP endpoint and place the message to be processed into a queue to be handled asynchronously. This will allow the endpoint to process data in volume.

SFTP

Message files can be delivered to an SFTP server. This mechanism is only suitable for very low-volume applications for testing environments. SFTP servers suffer from port exhaustion and file quantity issues when significant volume is pushed.

In a test environment, it is useful for events to be delivered to this way so the data can be examined manually.

The SFTP server in use can either be one provided by a third party or the AIR SFTP servers. When a third party's SFTP host is being used, the AIR outgoing IP Addresses need to be whitelisted to allow connectivity.

❗️

NOT FOR PRODUCTION

SFTP events must not be used in production environments.

Authentication

SFTP events require a username/password to be available to connect/deliver the notifications

Filtering

These events offer a limited filtering capability. The supported filters are:

• Campaign Tag
  • Only deliver an Account Transaction event if the associated campaign has the configured tag on.
• Campaign ID
  • Only events for a single campaign will be delivered. It is advised to use campaign tags rather than campaign IDs to allow the configuration to remain static even if the campaign needs to change.
• Issuer Safe Name
  • Events will only be sent if the account was issued by a given Issuance Partner unit
• Event Type
  • If only redemption events are required, a filter can be added to only allow this event type to be sent. Other event types will be ignored
• Object Type
  • If only actions on eCoupons are required and not Stored Value, a filter can be added on the type