My app is having issues with getting facebook page data: "rating_count" & "overall_star_rating". The issue have been found about 20 hours ago, between 2 am UTC to 6 am UTC 12th of October, so probably it's on Facebook side.
For example, request to all graph versions older 2.8 would same response:
https://graph.facebook.com/v2.8/pageID?fields=overall_star_rating,rating_count&access_token=YourToken
{
"overall_star_rating": 0,
"rating_count": 0,
"id": "pageID"
}
Look at zero counts - blank for all the pages. It doesn't matter what token you're using - app/user/page one, response is the same.
Requesting newer API versions (v2.10 & v2.9) give similar, but worth (incomplete) response:
{
"rating_count": 0,
"id": "pageID"
}
Both counts, "overall_star_rating" & "rating_count" are valid according to documentation.
Did anyone experience the issue? How did you fix it?
BTW, if you request "ratings" along with counts, but you'll have to use Page Access Token for that, you'll get an array of reviews of the page, but zero stats. I'm thinking of counting reviews & calculating rating based on them, but this way is wrong for many reasons.
Related
I have a little experience dealing with Facebook Graph API. I need to get daily views for the video as oppose to lifetime views.
FB API docs don't show this to be an option (lifetime - only period param)
https://developers.facebook.com/docs/graph-api/reference/video/video_insights/
However, I've seen another post on SO answering this question, yet for some reasons it doesn't work for me
(Getting a video views with Facebook API).
This is my successful API call which returns lifetime stats as expected:
/{video_id}/video_insights/total_video_views/lifetime
This is what I thought I should be doing:
/{video_id}/video_insights/total_video_views/day
... but got this error:
{
"error": {
"message": "(#100) Invalid parameter",
"type": "OAuthException",
"code": 100,
"error_data": "Daily query is not supported for metric (total_video_views)"
}
}
Then, as the SO post suggested, I tried different period param:
/{video_id}/video_insights/total_video_views/month
... and got this:
{
"error": {
"message": "(#100) Invalid parameter",
"type": "OAuthException",
"code": 100,
"error_data": "Period should be either lifetime or day."
}
}
... which tells that day should be acceptable param just like lifetime
Eventually, just for fun, I thought I'll pass "wrong" param - Day:
/{video_id}/video_insights/total_video_views/Day
... and got this:
{
"error": {
"message": "(#100) For field 'video_insights': period must be one of the following values: day, week, days_28, month, lifetime",
"type": "OAuthException",
"code": 100
}
}
This states that all of these values are good (day, week, days_28, month, lifetime), yet they don't work.
I'm really confused here. I saw daily break down for a video views on FB webpage/insights and thought it should be possible to do the same through the API.
What am i doing wrong?
I encountered the same problem shortly after your post. All of my testing and research has led me to believe Facebook has removed the ability to retrieve anything other than lifetime. After reading all of the Change Log for the last few releases, I don't see any evidence of this change being documented by Facebook. This is obviously very disappointing.
The API responses clearly indicate "day" should be a valid period, which leads me to believe it was hastily removed.
Unfortunately I do not see a reliable workaround. One may be able to achieve an approximation of daily by retrieving lifetime every 24 hours and calculating the difference between the two. This would only be an approximation though since there could be data reconciliation issues for a given time period.
It is too bad this issue didn't get any traction because it is core to the Facebook Video Insights API.
Here is my solution (after running this through FB support)
basically,
1) i get list of all posts:
fields='object_id,type'
url="https://graph.facebook.com/v3.2/{}?access_token={}&fields={}&limit={}".format(resource_id,access_token,fields,limit)
while url:
rec=requests.request(method="GET",url=url)
content = json.loads(rec.content)
if "next" in content["paging"]:
url=content["paging"]["next"]
else:
url=False
break
2) then, i iterate through each of them (filtering those with videos) and retrieve data for the post which contains this video rather than video itself (which turned out to be not possible anymore with daily grouping)
insights=[]
video_post_id=page_id+"_"+video_id
metric="post_video_views"
url_insight=f"https://graph.facebook.com/v3.2/{video_post_id}/insights?metric={metric}&since={since}&until={until}&pretty=0&access_token={access_token}"
while url_insight:
rec=requests.request(method="GET",url=url_insight)
insight = json.loads(rec.content)
if "next" in insight["paging"]:
url_insight=insight["paging"]["next"]
else:
url_insight=False
break
this worked for me
I am struggling with matching the "active time" returned by Fit REST API with reality.
As an example - on 12/14 I had two walks, about 45 minutes each. The api returns one of them as type 7 ("walking" - right!) and another one as type 0 (in vehicle - wrong!). However, Fit app shows both as "walking", so it apparently uses a different data source.
I checked some other days and on these days, the session with type 0 is indeed a valid "in vehicle" session.
I tried all aggregated data sources that return com.google.activity.segment. Most of them are empty, I've found data only in merge_activity_segments and platform_activity_segments (and they seem to be identical).
Google's docs have a caveat about delay in data sync, but they never specified how long this delay is. The data I am looking at is about 24 hours old - if their sync is that slow, then this API is more or less unusable.
I am using the following POST to https://www.googleapis.com/fitness/v1/users/me/dataset:aggregate
{
"aggregateBy": [
{
"dataSourceId": "derived:com.google.activity.segment:com.google.android.gms:merge_activity_segments"
}
],
"endTimeMillis": "1481788800000",
"startTimeMillis": "1481702400000",
"bucketByTime": {
"period": {
"timeZoneId": "America/Los_Angeles",
"type": "day",
"value": 1
}
}
}
For reference - activity types: https://developers.google.com/fit/rest/v1/reference/activity-types
Has anyone been able to retrieve activity time from Fit's REST API that is correct? Any suggestions?
By the way, steps and calories seem to work fine - just aggregate the following datasets:derived:com.google.calories.expended:com.google.android.gms:merge_calories_expended and derived:com.google.step_count.delta:com.google.android.gms:estimated_steps
A side note - it is probably the worst documented API from a major company I have seen.
Prior to today, I used the following URL to get the Facebook share/like/comment count of a URL:
https://api.facebook.com/method/links.getStats?format=json&urls=http://stackoverflow.com/
Today, Facebook removed this feature. So now I'm using this:
https://graph.facebook.com/v2.7?emc=rss&fields=og_object{engagement},share&access_token=<ACCESS_TOKEN_GOES_HERE>&id=http://stackoverflow.com/
Which outputs:
{
"og_object": {
"engagement": {
"count": 45267,
"social_sentence": "45K people like this."
},
"id": "10150180465825637"
},
"share": {
"comment_count": 12,
"share_count": 45267
},
"id": "http://stackoverflow.com/"
}
The problem is, share_count is the total of likes + comments + shares (as far as I know).
Is there a way to get the number of likes, comments, and shares separately?
Looks like a bug in fb-api.
My solution:
receive the number of shares/comments as you describe in your question with
graph.facebook.com/?fields=og_object{id},share&id=https://stackoverflow.com/
save shares/comments count
save fb object-id of url
og_object->id
get likes count with (max limit is 1000, then you can use paging):
graph.facebook.com/OBJECT_ID/likes?access_token=ACCESS_TOKEN&pretty=1&limit=1000
UPD 2016-08-22
I found a solution that allows you to get the number of likes/reposts/comments in one step:
https://graph.facebook.com/?fields=og_object{likes.limit(0).summary(true)},share&ids=http://google.com,http://twitter.com
It is not currently possible.
Facebook is adding likes/shares/comments for URLs and returning them as shared_count.
Not possible to return correct number of individual likes/shares/comments, and that is not clear in the Graph API documentation. Not clear if it is a bug or a documentation error.
The old Rest API that provided this data was turned off on the 18th August.
There is a comment from a Facebook engineer explaining this in reply to a bug report, in the answer to this Stack Overflow question:
Getting Facebook Share, Like and Comment Counts for a Given URL with API Graph v2.6
You can also subscribe to this bug report at Facebook, but is a bit old with still no solution:
https://developers.facebook.com/bugs/748651458568287/
I am attempting to dynamically create a group category with in a course using the following service:
[/d2l/api/lp/(version)/(orgUnitId)/groupcategories/ \[POST\]][1]
The following is the GroupData (Group.GroupData in Create form) JSON block that I am sending to this service:
{
"Name": "New Group Category",
"Description": {
"Content": "",
"Type": "HTML"
},
"EnrollmentStyle": 0,
"EnrollmentQuantity": null,
"AutoEnroll": false,
"RandomizeEnrollments": false,
"NumberOfGroups": 5,
"MaxUsersPerGroup": null
}
I am making the call with the user context of a administrative "Utility" account. I have 2 test courses, both of which I have confirmed I am able create the category through the web interface using this utility account.
My problem is I am having mixed results depending on the course that I try to create the category in. In one course the course returns 200-OK, in the other it returns 403-Forbidden.
Here are the (simplified) requests :
Call 1
/d2l/api/lp/1.4/350110/groupcategories/
Result: 403-Forbidden
Call 2
/d2l/api/lp/1.4/19988/groupcategories/
Result: 200-OK
The only difference is the OrgUnitID. Version, JSON, and user context are all the same, yet I'm getting 2 different results. I have tried with several other courses and again, I have success in some but not all; always receiving a 403 as the error.
After some investigation, I believe I have found 2 distinct differences between courses that are successful and those that return 403.
Courses created just before April 2012 are successful, anything afterwards fail
Courses with a 5 digit Org Unit ID are successful, anything with 6 digits seems to fail.
So my thoughts are we either applied a patch late march / early April of 2012 which somehow changed how courses are flagged on creation, OR somehow only 5 digits (or less?) Org IDs are being accepted by the service.
I'm hoping someone could provide some insight or verify they have no issue with 6+ digit OUIDs and group category creation.
Further reviewing the documentation on API Responses - Disposition and error handling I realized that there are 3 possible cases for a 403 response:
Response body contains Timestamp out of range
Response body contains Invalid Token
application or calling user context does not have the permissions required for the attempted action
Given this, I took a closer look at the response header and realized the issue was actually #2 "Invalid Token", not #3 as I was assuming.
Investigating my code further it seems the user defined SHA256 function I was using was producing an incorrect HASH/Signature when the data being hashed was exactly 55 characters long (yes I realize how crazy this sounds). The temporary work around is to pad my OrgIDs with leading zeros, so my request would actually look something similar too:
/d2l/api/lp/1.4/00350110/groupcategories/
Thankfully, this seems to work, and is acceptable for the immediate future. Long term solution will be to replace my SHA256 function with something more reliable.
I am using Colfusion 7MX for my development, which does not have a native SHA256 Hash function, hence the use of the user defined function.
I am requesting this page to get the events with the keyword
"conference":https://graph.facebook.com/search?q=conference&type=event
This works fine.
The problem is the pagination returned:
"paging": {
"previous":"https://graph.facebook.com/search?q=conference&type=event&limit=25&since=2010-12-18T17%3A00%3A00%2B0000",
"next":"https://graph.facebook.com/search?q=conference&type=event&limit=25&until=2010-11-04T16%3A29%3A59%2B0000"
}
It seems to have more events with "conference", but requesting these 2 pagination URLS returns no data.
It's weird because it's the same for any requested keyword, and the pagination URLs returned by the Facebook API seems to always returns empty data.
Does anyone know what's the issue?
Thanks
I encountered similar confusion with a query against places. The "next" URL behaved exactly as you described it.
I could query location information using a url like this:
https://graph.facebook.com/search?access_token=INSERT_TOKEN&type=place¢er=55.8660,-4.2715&distance=150&limit=10
And got back JSON with the first 10 places plus the following fragment which suggests the existence of paging params:
"paging": {
"next": "https://graph.facebook.com/search?access_token=INSERT_TOKEN&type=place¢er=55.8660\u00252C-4.2715&distance=150&limit=10&offset=10"
Hitting that URL doesn't work. But I did figure out a combination of limit and offset params that gave me effective paging.
limit=10 & offset not defined => first 10 results
limit=20 & offset=10 => next 10 results
limit=30 & offset=20 => next 10 results
limit=40 & offset=30 => last 8 results (can stop here because less than 10 back)
limit=50 & offset=40 => confirmation that there are no more results
I realise that I've got "limit" and "offset" rather than the "limit" and "until" params that you get, but, hopefully you could apply the same technique i.e. keep incrementing the limit and inc the date/time to that of your last result?
I think this is a standard practice in Facebook Graph API. I think if your request resulted to a non empty JSON, they will always give you the next paging, even though it might be empty.
I am however not 100% sure, because Facebook Graph API does not seem to be very well documented... (for example they said we can modify this pagination thing but did not explain clearly how to do it).
Seems facebook has changed it recently.
Here's the fix:
For a datetime returned in next and previous as
"2011-01-18T08\u00253A42\u00253A35\u00252B0000",
replace all occurrences of "\u0025" with "%" and it should work fine.
If you notice the facebook's datetime format, it is
2011-01-18T08:42:35+0000
(date accepted by strtotime C function)