Forum Discussion
Activity Feed Notifications Fail Due to WebUrl Length Limit
The documentation does not provide a specific limit for the length of the webUrl used in the sendActivityNotification Graph API. However, it's important to note that URLs in general have a length limit. Most web browsers can handle URLs up to 2048 characters, but some systems and servers have lower limits.
If you're encountering issues with larger payloads, it might be due to exceeding these general URL length limits. You may need to consider reducing the size of your payload or using a different method to pass the data to your Teams Personal Tab app.If the payload is essential and cannot be reduced,
you could follow this :
Shorten the URL: You could use a URL shortening service to reduce the length of your webUrl. This would allow you to include larger payloads without hitting the character limit.
Store the Payload Elsewhere: Instead of including the entire payload in the webUrl, you could store the payload data on a server and include a unique identifier in the webUrl. When the user opens the link, your app could use this identifier to retrieve the payload data from the server.
Reduce the Payload Size: If possible, you could try to reduce the size of your payload. This could involve removing unnecessary data, using shorter keys, or compressing the data.
MicrosoftThe documentation does not provide a specific limit for the length of the webUrl used in the sendActivityNotification Graph API. However, it's important to note that URLs in general have a length limit. Most web browsers can handle URLs up to 2048 characters, but some systems and servers have lower limits.
If you're encountering issues with larger payloads, it might be due to exceeding these general URL length limits. You may need to consider reducing the size of your payload or using a different method to pass the data to your Teams Personal Tab app.
If the payload is essential and cannot be reduced,
you could follow this :
Shorten the URL: You could use a URL shortening service to reduce the length of your webUrl. This would allow you to include larger payloads without hitting the character limit.
Store the Payload Elsewhere: Instead of including the entire payload in the webUrl, you could store the payload data on a server and include a unique identifier in the webUrl. When the user opens the link, your app could use this identifier to retrieve the payload data from the server.
Reduce the Payload Size: If possible, you could try to reduce the size of your payload. This could involve removing unnecessary data, using shorter keys, or compressing the data.
Thank you for your response and suggestions.
We have explored the three alternatives you have mentioned. Looks like reducing the payload size is the best option for us.
Nevertheless, it would be better if the API documentation could clearly define and mention such limits.
