Issue getting emailAddress data for rich notification on contact resource

Question

I am trying to create a change notification that tracking changes on outlook contact.

However, when I decrypt the encryptedContent from the webhook, I just got this data:

{
	"displayName":"John Dow",
	"******@odata.type":"#Collection(String)",
	"homePhones":["+62 895-1234-63731"],
	"******@odata.type":"#Collection(String)",
	"businessPhones":["+62 895-4321-63732"],
	"emailAddresses":[{"@odata.type":"#microsoft.graph.emailAddress"}]
}

What am I doing wrong, and how can I resolve this issue?

Answer 1

Hi Syifa,

I've encountered a similar issue in the past beofre before when working with change notifications for Outlook contacts through the Microsoft Graph API. The problem you're experiencing, where the encryptedContent only reveals partial information for emailAddresses, is something I've navigated through.

The key issue seems to be not with the decryption process or the initial receipt of data but rather with how the emailAddresses field is being processed or the data that's being subscribed to. Here are the steps I took to troubleshoot and ultimately resolve the issue:

• Review the Subscription Request: Initially, I revisited the subscription request for change notifications to ensure it was explicitly asking for all the fields of interest, including the emailAddresses. It's crucial to specify in your subscription which properties you want to track for changes to make sure you're not missing out on any.
• Verify Permissions: Next, I checked the permissions granted to the app. For the Microsoft Graph API to provide complete contact details, including email addresses, the app needs adequate permissions. I made sure the app had Contacts.Read permission, which is essential for accessing detailed contact information. If permissions are lacking or incorrectly configured, the API might limit the data it returns.
• Examine Data Handling: I then looked into how the decrypted data was being processed. The presence of "@odata.type":"#microsoft.graph.emailAddress" without actual email data hinted at a potential serialization issue. It was important to ensure that the code handling the webhook payload was correctly parsing complex objects and collections, including nested properties.
• Implement Detailed Logging: To get to the root of the problem, I enhanced logging around the decryption and data processing steps. Detailed logs helped pinpoint whether the issue was with the data being sent by the API or if it was an internal processing error. This step was crucial in understanding the flow of data and where it might be getting lost or mishandled. Through these steps, I discovered that the issue was partly due to the subscription request not specifying all desired properties and partly due to how my code processed the webhook payload. Adjusting the subscription request and refining the data handling logic resolved the issue, allowing me to receive complete contact details, including email addresses. I hope this helps for you as well, if you have any questions please let me know.