I want to retrieve data regarding insights of my Facebook posts. I am able to retrieve all this information under graph API explorer but keep on getting errors the moment I put it into a graph URL.
Here is the URL :
https://graph.facebook.com/v15.0/{page_id}/posts?fields=insights.metric(post_engaged_users,page_posts_impressions_unique)&token_access=ACCESS_TOKEN
(I removed the page_id and ACCESS_TOKEN for privacy.)
I end up getting this error:
{
"error": {
"message": "(#200) Provide valid app ID",
"type": "OAuthException",
"code": 200,
"fbtrace_id": "AuaCwwoNGZW_U4Ivay4Xi1f"
}
}
Can someone guide me on what to do in this case? I guess I have to include my app_ID into the Graph API URL, but where exactly?
Thank you.
I searched for a solution from the Facebook developer community but could not get any solutions.
Related
Which one is best for Rest API response ?
In here I return some meta information with actual data. Although I am not sure they need to use those meta information or not.
{
"version": "1.0.0",
"isError": false,
"statusCode": 200,
"message": "Permission Object",
"data": {
"id": 1,
"name": "user create",
"created_at": "2022-11-30T10:18:20.000000Z"
}
}
In second example I am returning only the relevant data.
{
"id": 1,
"name": "user create",
"created_at": "2022-11-30T10:18:20.000000Z"
}
Give me suggestion if there are other better way.
I noticed you've used the tag REST, so I assume you are thinking about a RESTful API implementation and have some knowledge about RESTful API design.
If you need some best practices, a couple of them I think are useful. here and here.
Looking at your examples, I would prefer the second option, the reasons are:
IsError can be determined by the HTTP response, e.g. 400, 500, 200, 201, so it's redundant.
Status and Message are also redundant when the response is successful but could be useful in an error state, like in ASP.NET, you can use the ProblemDetails response (you can customize the way you want).
{
"type": "https://tools.ietf.org/html/rfc7231#section-6.5.1",
"title": "Unable to create a new user due to missing name",
"status": 400,
"traceId": "00-0aa7d64ad154a1e1853c413a0def982d-195d3558c90f7876-00"
}
version is an interesting one. Usually, it can be included in the request header or URL. If the API cannot handle the version requested, then it should return an error in the problem details.
Thus, I prefer the second option and send a problem details response when there is an error.
An open source CRM with more than 18K start on github uses Laravel-default api resource
Project Link
Code Example link
Pay attention to status codes
Reference
This one is super important. If there's one thing you need to remember from this article, this is probably it:
The worst thing your API could do is return an error response with a
200 OK status code.
It's simply bad semantics. Instead, return a meaningful status code that correctly describes the type of error.
Still, you might wonder, "But I'm sending error details in the response body as you recommended, so what's wrong with that?"
Let me tell you a story.
I once had to use an API that returned 200 OK for every response and indicated whether the request had succeeded via a status field:
{
"status": "success",
"data": {}
}
So even though the status was 200 OK, I could not be absolutely sure it didn't fail to process my request.
This kind of design is a real no-no because it breaks the trust between the API and their users. You come to fear that the API could be lying to you.
All of this is extremely un-RESTful. What should you do instead?
Make use of the status code and only use the response body to provide error details.
HTTP/1.1 400 Bad Request
Content-Type: application/json
{
"error": "Expected at least two items in list."
}
JSON API is a format that works with HTTP. It delineates how clients should request or edit data from a server, and how the server should respond to said requests.
I am attempting to use the GoCardless API sandbox to create a customer but only get a 403 forbidden error
{"error": {
"message": "Forbidden request",
"errors": [ {
"reason": "forbidden",
"message": "Forbidden request"
}],
"documentation_url": "https://developer.gocardless.com/api-reference#forbidden",
"type": "invalid_api_usage",
"request_id": "8b870491-e8ca-436c-a602-bb613bba7d96",
"code": 403
}}
I have used OAuth to get a bearer token which I am using for my post to the sandbox url
https://api-sandbox.gocardless.com/customers
Using this url and the bearer token i can get customers and update a customer that i created manually via the sandbox client portal. If i purposefully make the token an invalid value i get a 401 error instead so I am sure the token is correct.
The documentation for the error type "invalid_api_usage" is as follows
This is an error with the request you made. It could be an invalid
URL, the authentication header could be missing, invalid, or grant
insufficient permissions, you may have reached your rate limit, or the
syntax of your request could be incorrect. The errors will give more
detail of the specific issue.
The fact i can update a customer i believe crosses most of those potential issues of that list.
I am now using the exact post body content of the GoCardless API example for creating customer to verify the syntax should be correct.
{
"customers": {
"email": "user#example.com",
"given_name": "Frank",
"family_name": "Osborne",
"address_line1": "27 Acer Road",
"address_line2": "Apt 2",
"city": "London",
"postal_code": "E8 3GX",
"country_code": "GB",
"metadata": {
"salesforce_id": "ABCD1234"
}
}
}
I am running these requests from SoapUI instead of my application so I can be sure I am sending exactly what i am expecting to send.
From the API documentation I understand my application must have approved payment pages to create customers in the live environment however this is prefixed by a statement that this is not restricted in the sandbox environment.
Restrictions
Whilst the entire GoCardless API is accessible in the sandbox
environment, the following restrictions exist in live.
Payment page restrictions
Unless your payment pages have been approved as scheme rules compliant
by our sponsor bank you must use the Redirect Flow API to create
customers, bank accounts and mandates.
The following endpoints are therefore restricted:
Customers: Create
Customer bank accounts: Create
Mandate: Create, Reinstate
Javascript flow: All endpoints
It seems to me the 403 forbidden response is exactly what i would be getting if Create Customer was restricted in the sandbox environment however the API documentation explicitly states that this is not the case.
My question is basically what could I be doing wrong? Maybe somebody can spot something I have forgotten or am misunderstanding.
The answer is that the sandbox is restricted in the same way as the live environment.
The API documentation appears to be worded in a way that suggest the sandbox is unrestricted however this is not the case.
To remove the restriction in the sandbox environment you need to contact GoCardless support and request it.
I am developing a c# application to upload videos to Vimeo throough the Vimeo API. Everything's gone fine so far, but I cannot find a way to check the progress of video uploading to Vimeo when using automatic pull uploads. I don't want percentage values (which we can derive in regular uploads), but just a success or failure response would suffice. Is there any way I can do this through an API call?
The response of your inital POST request to /me/videos is the full clip representation. On that representation is a status field, that will contain one of the following values:
uploading
transcoding
uploading_error
transcoding_error
available
quota_exceeded
The uri of that representation is an API endpoint that you can store, and call again in the future to receive an updated status.
eg:
POST https://api.vimeo.com/me/videos
type=streaming&link=http://example.com/my/video/mp4
{
"uri": "/videos/12345",
.....truncated.....
"status": "uploading"
}
[some time later]
GET https://api.vimeo.com/videos/12345
{
"uri": "/videos/12345",
.....truncated.....
"status": "available"
}
Could someone help me to understand what a specific example of an API link would look like for the following API?
https://engradesandbox.com/docs/
They show examples in the documentation about what the JSON result/return of an API, but not an actual example of what a call would look like.
I've noticed this with most API's, they show the possible result data, but not the default url syntax. It's so frustrating, because looking through existing restful tutorials isn't very fruitful on the subject either.
How do you know what the actual API call should look like?
That actually does tell you you what to do.
All "calls" will be HTTP POST to the URL specified.
If you click on one of them, it takes you to a page that explains the input data for that method.
For example, see the class-behavior-add function. To call that function, you'd post to the URL they specify (https://api.engradesandbox.com/ as of this posting), and the content of your post would be XML or JSON that contains the fields specified here.
Example post data as JSON:
{
"apitask": "class-behavior-add",
"apikey": "your_api_key",
"ses": "session token id",
"clid": 1234567890,
"stuid": "student ID",
"date": 123456789,
"mark": 12,
"points": 123
}
Example post data as XML:
<engrade>
<apitask>class-behavior-add</apitask>
<apikey>your_api_key</apikey>
<ses>session token id</ses>
<clid>1234567890</clid>
<stuid>student ID</stuid>
<date>123456789</date>
<mark>12</mark>
<points>123</points>
</engrade>
My final aim is to allow user to upload some content on to a google drive word document in their individual account.
I am using the PHP example provided on https://developers.google.com/drive/v2/reference/files/insert#examples. When uploading a simple text file, it works fine.
Then (after wasting almost 8 hours with mimetype application/msword. Not sure why the docs don't make it easier to find such common details.) I changed the mimetype to application/vnd.google-apps.document with empty data, and it worked absolutely fine.
Then, I created a doc file on google drive web interface and then exported it to my machine. It was saved as docx. Then in the example, this file is used as the source for data, I keep getting Error calling POST https://www.googleapis.com/upload/drive/v2/files?uploadType=multipart: (400) Bad Request error.
The error message does not even provide any more details as to what is wrong with the request.
[responseBody:protected] => {
"error": {
"errors": [
{
"domain": "global",
"reason": "badRequest",
"message": "Bad Request"
}
],
"code": 400,
"message": "Bad Request"
}
}
You probably have to put the Word file's content as a string into the $request['content']
If it's .DOCX the proper MIME-type is a:
application/vnd.openxmlformats-officedocument.wordprocessingml.document
Reference: MSDN Library
Well, how shall one tell what's wrong by the response, but not the request which produces it?
You probably could have just written "HTTP400 - the crap is not working" instead,
which would provide about an equal amount of information.
HTTP Response-Code #400 in general means,
That the HTTP request was malformed (e.g. is missing parameters, wasn't properly escaped, etc).
^ ...and this is certainly the correct answer - according to the sample response.
And this is exactly the reason why the information provided isn't sufficient to provide you with a straight answer. I'd also wish the API to have a little more details in the responses (especially on occasional file validation errors) - because sometimes one can only guess what's wrong "on the other side".
Best practice is to start from a very simple working version and add some complexity then.
If you'd wish to have the issue reviewed/resolved, you should add a sample request.
Doesn't even matter how the code looks like - when the request is obviously malformed.
Ordinary I offer web-scripting as a service, just currently kinda out-of-resources.