Asynchronous subscription events

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, they return a JSON or XML response, as well as an HTTP response code. Usually this code is 200 (OK) or 201 (Created). AppDirect will recognize a code of 202 (Accepted) as a mechanism for the vendor to inform AppDirect that the event has been received and is being processed, and the vendor will notify AppDirect upon completion. The vendor can make an HTTP POST to the /api/integration/v1/events/ eventUrl/result endpoint to notify AppDirect of the result. The POST body is the same as it would be for a synchronous event response.

The subscription or assignment will remain in one of the following pending states:

• PENDING_USER_ACTIVATION
• PENDING_REMOTE_CREATION
• PENDING_REMOTE_CANCELLATION

in the AppDirect marketplace until AppDirect is notified of the result.

When a subscription or assignment is in the pending state, the user cannot act upon it.

Asynchronous event notification flow

All asynchronous event notifications follow the same general flow:

1. An event is triggered by a customer action for example purchasing an application, upgrading an existing subscription, canceling a subscription, or failing to pay an invoice.

2. AppDirect sends an event notification to the vendor. This event is uniquely identified by an eventUrl. More details about the notification URL are provided below.

3. Developers 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 Developer can read the eventUrl from the parameters and send an HTTP GET request for more information about the specific subscription event.

4. The AppDirect marketplace sends a JSON or XML response to the vendor.

5. The vendor then sends a POST request back to the AppDirect marketplace with the account information, status information, or both. This status information is used by AppDirect to provide feedback to the customer using the AppDirect user interface.

6. In an asynchronous event, the header in the vendor POST request contains a 202 (Accepted) HTTP code. AppDirect will recognize this code as a pending event.

7. Once the event is manually resolved (such as an account is provisioned), the vendor can POST a result to the eventUrl.