Microsoft App Source Webhook connector -- 2
Budget: €250 – €750 EUR
We need help to create a Webhook wih an URL to be used as an HTTP endpoint where Microsoft will notify us of events such as purchases and subscription changes in our Microsoft partner center to integrate our ISV transactional offer in the Microsoft Appsource Portal like https://appsource.microsoft.com/es-es/marketplace/apps?search=nanfor&page=1but , in this case is not a listed offer but a transactional offer.
Incoming Webhooks more information
Incoming Webhooks help in posting messages from apps to our landing page or other asset . If Incoming Webhooks are enabled for a team in any channel, it exposes the HTTPS endpoint, that accepts correctly formatted JSON and inserts the messages to that channel. For example, you can create an Incoming Webhook in your DevOps channel, configure your build, and simultaneously deploy and monitor services to send alerts.
In https://learn.microsoft.com/es-es/partner-center/marketplace/partner-center-portal/pc-saas-fulfillment-life-cycle there is more information about how to generate an API market place
In https://learn.microsoft.com/es-es/partner-center/marketplace/partner-center-portal/pc-saas-fulfillment-webhook there is more information
The publisher must implement a webhook in the SaaS service to keep the SaaS subscription status consistent with the Microsoft side. The SaaS service is required to call the Get Operation API to validate and authorize the webhook call and payload data before taking action based on the webhook notification. The publisher should return HTTP 200 to Microsoft as soon as the webhook call is processed. This value acknowledges that the webhook call has been received successfully by the publisher.
Important
The webhook URL service must be up and running 24 x 7, and ready to receive new calls from Microsoft at all times. Microsoft does have a retry policy for the webhook call (500 retries over eight hours), but if the publisher doesn't accept the call and return a response, the operation that webhook notifies about will eventually fail on the Microsoft side.
Important
ISVs should avoid strict deserialization of the Webhook schema. Microsoft reserves the right to expand the schema in future.
Important
ISVs must validate the Microsoft Entra Token (JWT Token) on their webhook endpoint from the request header. This is a standard bearer token and will give ISV details about who the caller is. Find out more about how to validate the token in this article. learn.microsoft.com/azure/active-directory/develop/access-tokens
Incoming Webhooks more information
Incoming Webhooks help in posting messages from apps to our landing page or other asset . If Incoming Webhooks are enabled for a team in any channel, it exposes the HTTPS endpoint, that accepts correctly formatted JSON and inserts the messages to that channel. For example, you can create an Incoming Webhook in your DevOps channel, configure your build, and simultaneously deploy and monitor services to send alerts.
In https://learn.microsoft.com/es-es/partner-center/marketplace/partner-center-portal/pc-saas-fulfillment-life-cycle there is more information about how to generate an API market place
In https://learn.microsoft.com/es-es/partner-center/marketplace/partner-center-portal/pc-saas-fulfillment-webhook there is more information
The publisher must implement a webhook in the SaaS service to keep the SaaS subscription status consistent with the Microsoft side. The SaaS service is required to call the Get Operation API to validate and authorize the webhook call and payload data before taking action based on the webhook notification. The publisher should return HTTP 200 to Microsoft as soon as the webhook call is processed. This value acknowledges that the webhook call has been received successfully by the publisher.
Important
The webhook URL service must be up and running 24 x 7, and ready to receive new calls from Microsoft at all times. Microsoft does have a retry policy for the webhook call (500 retries over eight hours), but if the publisher doesn't accept the call and return a response, the operation that webhook notifies about will eventually fail on the Microsoft side.
Important
ISVs should avoid strict deserialization of the Webhook schema. Microsoft reserves the right to expand the schema in future.
Important
ISVs must validate the Microsoft Entra Token (JWT Token) on their webhook endpoint from the request header. This is a standard bearer token and will give ISV details about who the caller is. Find out more about how to validate the token in this article. learn.microsoft.com/azure/active-directory/develop/access-tokens