Asynchronous user events

Almost all subscription events that involve a response can also be supported as asynchronous (delayed response) events. SUBSCRIPTION_NOTICE is the only subscription event that does not involve a response and therefore is only supported as a synchronous event.

When AppDirect calls a vendor with a notification URL, the vendor returns a JSON or XML response, as well as an HTTP response code. Usually, this code is 200 (OK) or 201 (Created). Additionally, AppDirect recognizes a code of 202 (Accepted) as an indication that the vendor received the event and is processing it, and will notify AppDirect after completion.

The vendor can make an HTTP POST to the /api/integration/v1/events/{eventUUID}/result endpoint to notify AppDirect of the result. The POST body is the same as it is for a synchronous event response. The subscription or assignment remains in a "pending" state (for example PENDING_USER_ACTIVATION, PENDING_REMOTE_CREATION, or PENDING_REMOTE_CANCELLATION) in the AppDirect marketplace until the vendor notifies AppDirect of the result. When a subscription or assignment is in the pending state, users cannot act upon it.

Asynchronous event notification flow

All asynchronous event notifications follow the same general flow:

1. A user action triggers an event for example, the customer purchases an application, upgrades a subscription, cancels a subscription, or fails to pay an invoice.
2. AppDirect sends an asynchronous event notification to the vendor. This event is uniquely identified by an eventUrl. More details about the notification URL are provided below.
3. Vendors must validate the request based on the authorization type configured for their product. See the following topics for more information on how to securely receive event notifications (select the topic based on whether you use shared or separate credentials):
   • Validate outbound event notifications (separate credentials)
   • Validate outbound event notifications (legacy) (shared credentials)
     Vendors can specify the format of the response they receive from AppDirect. They can add Accept: application/json in their HTTP GET request to receive the response from AppDirect in JSON format. They can add Accept: application/xml in their HTTP GET request to receive the response from AppDirect in XML format. If vendors do not specify the content type, an XML payload will be returned.
     After validation is complete, the vendor can read the eventUrl from the parameters to send an HTTP GET request for more information about the specific subscription event.
4. AppDirect sends a JSON or XML response to the vendor.
5. The vendor sends a POST request back to AppDirect with the account information, status information, or both. AppDirect uses the status information to provide information to the customer through the user interface.
   In asynchronous events, the header returns a 202 (Accepted) HTTP code. AppDirect recognizes this code as a pending event.
6. After the event is manually resolved by the Marketplace Manager (for example, an account is provisioned), the vendor can POST a result to the eventUrl.