I'm working on a website that retrieves public videos from a YouTube channel to populate a video list on the site.
The published page is using the 2.0 version of the API with a base request URL of: http://gdata.youtube.com/feeds/api/users/z8xDwdqXrHVc-8b4ZsA0Sw/uploads?max-results=15
This URL successfully returns the 6 public videos available on the specified channel.
I'm in the process of migrating to the 3.0 API, and I've noticed a discrepancy in the results returned from the new request:
$searchResults = $youtube -> search -> listSearch( 'snippet', array(
'channelId' => 'UCz8xDwdqXrHVc-8b4ZsA0Sw',
'maxResults' => 15,
'type' => 'video'
) );
With this request, I would expect $searchResults to contain the same 6 videos as the old 2.0 API request, however, the 3.0 request returns a response with zero results.
I am reasonably certain that I have ruled out an error in my setup of the Google_Service_YouTube and Google_Client objects.
I replaced the channelId parameter above with the channel ID of my own personal YouTube channel (UC2qJ2qvc_fRp3xLtWKNPucw), and received a response with the 10 public videos I have on that channel.
What would cause this discrepancy?
EDIT
Since making this post, I have removed all videos from the channel in question. The videos were originally uploaded using the export feature available through twitch.tv. I downloaded the original files and resubmitted the videos directly through YouTube, and now all 6 videos appear in the API response as expected.
At this point, I've got the feed working and developed a plan for video upload management that should prevent this from resurfacing. However, I'd still like to understand what would cause the inconsistency. Why would videos uploaded to the channel via Twitch be excluded from the search results?
Related
I am trying to fetch the posts of an organization by using the https://api.linkedin.com/rest/posts endpoint which works fine. In the response I get media urn fields which i need to resolve via the https://api.linkedin.com/rest/images endpoint to get the URL of the images of the posts. Is there any way to get the image URL on the https://api.linkedin.com/rest/posts endpoint?
I assume this is possible via projection because of the following statement in the API documentation:
You can include the following types of content in a Post:
Images
Videos
Article
Carousels
MultiImage
Poll
Source: https://learn.microsoft.com/en-us/linkedin/marketing/integrations/community-management/shares/posts-api
I'm trying to upload an image as profile picture using WhatsApp Cloud API *.
After creating an application using WhatsApp Cloud API I'm not allowed to access neither using the regular application nor using Business Application. It says something like "try again in one hour". So I have to implement everything using the API.
After reading the docs and importing Postman Endpoints I found the one called Business Profiles > Update Business Profile
https://graph.facebook.com/{{Version}}/{{Phone-Number-ID}}/whatsapp_business_profile
It has a field "profile_picture_url"and I have tried POSTing media https://graph.facebook.com/{{Version}}/{{Phone-Number-ID}}/media and then with the given ID y used https://graph.facebook.com/{{Version}}/{{Media-ID}} to get the URL but it didn't work. The rest of the information is updated successfully
{
"messaging_product": "whatsapp",
"address": "",
"description": "Simple Bot",
"email": "...#gmail.com",
"websites": [
"https://..."
],
"profile_picture_url": "https://lookaside.fbsbx.com/..."
}
However if I try to send someone using the ID and the endpoint https://graph.facebook.com/{{Version}}/{{Phone-Number-ID}}/messages it works fine.
And if I use Download Media Content with the URL in Postman it works fine too.
I don't know if I have misunderstood something or if it can't be done using the API.
It is mentioned in the Cloud API Documentation:
profile_picture_url (Optional): URL of the profile picture generated from a call to the Resumable Upload API.
But, i got it working using profile_picture_handle instead of profile_picture_url. So how do we get the profile_picture_handle?
Prerequisite:
Graph API token here. Or use your WhatsApp Cloud API token.
App ID, go Apps > Your App > Settings (sidebar menu) > Basic
Update Photo Profile:
Call POST https://graph.facebook.com/v14.0/{{appId}}/uploads?access_token={{token}}&file_length={{fileSizeInByte}}&file_type=image/jpeg
Save the session id you got, upload:XXXXXX?sig=XXXXXX.
Call POST https://graph.facebook.com/v14.0/{{sessionId}}, with the headers: Authorization=OAuth {{token}}, file_offset=0, Host=graph.facebook.com, Connection=close, Content-Type=multipart/form-data, and include your image file in the request body with type binary. If you using Postman, see image below (This is what I missed for hours).
Save the handle result you got, 4::XXX==:XXXXXX.
Finally, call POST https://graph.facebook.com/{{Version}}/{{Phone-Number-ID}}/whatsapp_business_profile, with json request body: {"messaging_product": "whatsapp", "profile_picture_handle": "4::XXX==:XXXXXX"}
That's it, You can check the profile picture.
The last step you have to add your taken by selecting "Bearer" or else it will give you error. I had hard time on the last ones, do all the steps and then go to the following link and it should help.
https://web.postman.co/workspace/My-Workspace~a4ddb3b8-02a3-4132-8384-66e63e149b7b/request/22958165-506a0542-c845-41ac-b3fb-b8209fd6f53b
I'm trying to create a Sharepoint iOS app and using the rest api I get the error "Likes are not supported in this item." after doing a POST to https://tenant.sharepoint.com/News/_api/web/lists/getbytitle('pages')/items('1234')/like.
Anyone knows more about this kind of error?
The Rating settings seems to be set correctly on the Sharepoint server, because the like option works correctly on the website, and also in the app I can see the likesCount properties on the response for the Rest API call https://tenant.sharepoint.com/News/_api/web/lists/getbytitle('pages')/items('1234').
I don't think there is something wrong with the client app implementation, but it is something related to the Sharepoint configuration, although I haven't seen any more settings in regards to the Rating settings including the Sharepoint access for the mobile app.
The web seems to handle this using the Microsoft.Office.Server.ReputationModel.Reputation.setLike function which again works correctly on the web parts, but I couldn't find a way to do it from the mobile app.
To set Likes for the list item, we need use the API below with POST request.
https://tenant.sharepoint.com/News/_api/web/lists/getbytitle('pages')/items('1234')
And pass the data of the POST request as below.
var item = {
"__metadata": { "type": "SP.Data.PagesItem"},
"LikedByStringId": {"results": ["11"]},
"LikesCount": 2
};
Before set Likes for the item, we need get the "LikedByStringId" and "LikesCount" value of the list item using API below with GET request, then set the new one.
https://tenant.sharepoint.com/News/_api/web/lists/getbytitle('pages')/items('1234')
Check the article here: Demonstrates how to like/unlike resource via SharePoint REST API
I have a problem with the Soundcloud API when querying an authenticated user's tracks. I'm currently testing on iOS using NXOAuth2 to provide OAuth2 authentication. I am not using the now-deprecated Soundcloud iOS SDK.
If I make a GET request to https://api.soundcloud.com/me/tracks.json?limit=50&linked_partitioning=1, the returned JSON contains 50 tracks, and the string "https://api.soundcloud.com/me/tracks.json?limit=50&linked_partitioning=1&offset=50" for key "next_href". Making a GET request to this URL returns the next page of tracks. This works as expected.
If I make a GET request to https://api.soundcloud.com/me/favorites.json?limit=50&linked_partitioning=1, the returned JSON contains 50 tracks, and the string "https://api.soundcloud.com/me/favorites.json?before=1395763236&linked_partitioning=1&page_number=1&page_size=50" for key "next_href". Making a GET request to this URL returns a JSON with the same set of tracks as obtained with the original URL, and the same "next_href" string.
It looks like /me/tracks.json has not been updated with the new pagination style (still using offsets). However /me/favourites.json has, but does not work correctly for me. Can anyone else clarify similar behaviour? I am hoping there is something I have missed.
Many thanks in advance.
Using the blog/{blog-host}/post API call in the v2 oAuth API in order to post a photo, I have a problem with specifying the "source" for the image. The API dictates that this parameter should be the source to an image:
http://www.tumblr.com/docs/en/api/v2#posting
I am using an image on my server, such as this one. The Facebook and other APIs accept and process it correctly:
http://streamified.me/p/d4xh6o/
Unfortunately, I get the following response from Tumblr:
meta = {
msg = "Bad Request";
status = 400;
};
response = {
errors = (
"Error uploading photo."
);
};
Posting other status types works fine...
Well, it looks like I solved the problem. My server was serving the image (the above URL) via a PHP script. Even though the header data etc. was properly sent and the image showed fine in all browsers, the Tumblr API was not recognizing it as an image. Redirecting to a .jpg URL worked fine.
I'd consider this to be a bug in the Tumblr API, but the workaround is "good enough" for me.