I’m struggling with accessing business page alerts through Facebook’s Graph API. The official docs seem to only cover personal user notifications, not page-specific ones.
The standard endpoint only gives me personal notifications: /me/notifications
What I’ve attempted so far:
Method 1: Substituted page ID in the URL structure /PAGE_ID/notifications
This approach failed completely.
Method 2: Explored the Insights API but it’s focused on analytics data rather than activity feeds /PAGE_ID/insights/METRIC_NAME
This gives statistics but I need recent fan interactions and post activities on the business page.
My setup details:
Using .NET Framework 4.0
Facebook C# SDK for API calls
Page access token is working for other endpoints
I’ve been researching this problem for several days without success. The Facebook documentation doesn’t provide clear guidance for page notification retrieval. Has anyone found a working solution for getting business page activity notifications through the Graph API?
Facebook’s Graph API for page notifications sucks to work with directly. The endpoints are limited and their docs are all over the place.
I hit this same wall last year building a social media dashboard. Instead of fighting Facebook’s crappy API, I built an automation workflow that does the heavy lifting.
Here’s what actually works:
Set up a workflow that polls Facebook’s endpoints on schedule. Hit /PAGE_ID/feed for recent posts, then /POST_ID/comments and /POST_ID/reactions for interactions. Also grab /PAGE_ID/conversations for messages.
The trick is combining these data sources into one clean notification feed. Raw API calls mean you’re constantly juggling tokens, rate limits, and different response formats.
With automation, you consolidate everything into a single stream, filter by activity type, and push alerts to Slack or email when important stuff happens.
This completely solved my Facebook page monitoring. No more wrestling with undocumented endpoints or missing data.
Facebook’s API docs are misleading here - they mix up different access levels. I ran into this same issue two years ago and found that page notifications just aren’t available through standard Graph API calls, no matter what permissions you have. What actually worked was a hybrid approach: Facebook’s Live API plus selective endpoint polling. Live API handles real-time page post updates, and polling grabs the engagement data you’re missing. For .NET, set up Live API subscription in your app settings, then poll /PAGE_ID/posts with the fields parameter to pull comments.summary(true), reactions.summary(true), shares in one call. Way less API overhead than separate requests. The trick is thinking of it as event aggregation instead of trying to copy Facebook’s notification system. Store your last sync timestamp and use since parameters to keep things efficient. Your current page token should work fine since you said other endpoints are working.
Been down this exact rabbit hole when building page monitoring for our company’s social accounts. The notification endpoint situation sucks but there’s a solid workaround.
Don’t try recreating Facebook’s notification format. Build your own alert system using what’s available. I pull from /PAGE_ID/feed, /PAGE_ID/conversations, and /PAGE_ID/tagged every few minutes.
Process the data into meaningful alerts. Set thresholds for what matters - new comments, message replies, mentions above certain engagement levels. Store the last processed timestamp for each endpoint so you don’t reprocess old data.
For .NET 4.0 with Facebook SDK, batch your requests to avoid rate limits. I group 3-4 calls per batch and run them every 5 minutes during business hours.
This saved me tons of time - don’t match Facebook’s notification format exactly. Build alerts that actually help your business instead of copying their interface. Focus on actionable stuff like unanswered messages or high engagement posts needing attention.
Polling works fine for most cases. Real time webhooks are nice but honestly overkill unless you’re managing hundreds of pages.
Skip Facebook’s broken API and polling headaches - I automated this when I hit the same wall.
The real issue isn’t missing endpoints. It’s juggling multiple data sources, rate limits, token refreshes, and turning messy responses into useful alerts. Manual polling gets pricey and flaky quick.
I built a workflow that handles Facebook’s API mess automatically. Pulls from feed, conversations, tagged, and reactions endpoints, then turns everything into clean notification streams. Manages rate limiting, handles token rotation, filters out junk.
Smart triggers are the game changer. Instead of constantly checking everything, it only alerts when something needs attention - new complaints, viral posts, messages unanswered after 30 minutes.
Your .NET app can grab the processed data through webhooks or API calls without touching Facebook’s garbage directly. The workflow does the dirty work, your app gets clean notifications.
This killed all the Facebook API pain and works way better than their old notification endpoints.
Facebook killed the notifications endpoint for pages years ago - that’s why you’re hitting dead ends. The /PAGE_ID/notifications endpoint just doesn’t exist anymore.
You’ll need to piece together activity from different endpoints. I’ve run into this exact problem building monitoring tools for client pages. The solution is webhooks plus periodic API polling.
Set up webhooks through the Facebook App dashboard for real-time notifications. Subscribe to feed, comments, mention, and message events for your page. You’ll get instant notifications when stuff happens.
For historical data and filling gaps, poll these endpoints regularly: /PAGE_ID/feed for posts, /PAGE_ID/conversations for messages, and /PAGE_ID/tagged for mentions. Just know that webhook subscriptions need a valid SSL endpoint on your server to receive the POST requests.
Webhooks beat constant polling - they’re more reliable and don’t hammer rate limits. Facebook’s webhook docs are actually decent compared to their other API documentation. Make sure your page access token has manage_pages and pages_messaging permissions.
Facebook decommissioned page notification endpoints during their 2018 API overhaul. I developed a custom solution to navigate this limitation. To create a comprehensive feed, utilize multiple Graph API calls: begin with /PAGE_ID/posts using the since parameter to fetch new content, then proceed to check comments and reactions associated with each post. For direct engagement, also monitor /PAGE_ID/conversations for messages and /PAGE_ID/tagged for mentions.
A significant advantage comes from leveraging Facebook’s batch API feature. By consolidating requests, you minimize the strain on your rate limit and enhance performance. This method reduces API overhead significantly.
Incorporate timestamp-based tracking to prevent processing the same entries repeatedly. Maintain a record of your last check time, employing it as the since parameter for subsequent requests to ensure efficient polling that only retrieves new activity. The Facebook C# SDK is adept at handling batch requests on .NET Framework 4.0, allowing you to structure your calls effectively for comprehensive page activity data, essentially compensating for the absence of notification endpoints.
facebook’s api is a total nightmare for this. I ditched it and just scraped the page activity feed directly - way easier than dealing with their broken endpoints. not pretty, but it actually works unlike their docs lol. use selenium to grab the recent activity section.