Using Graph API
Using Graph API
Giriş
Ödemeler
Reklamlar
Basics
Audience Network
We cover the basics of Graph API terminology and structure in our Graph API Quic
Insights reading this guide to learn more about the different operations that can be performe
Uygulama Geliştirme
SDKs
Reading
iOS SDK All nodes and edges in the Graph API can be read simply with an HTTP GET
endpoint. For example, if you wanted to retrieve information about the current user
Android SDK HTTP GET request as below:
JavaScript SDK
Unity SDK
Most API calls must be signed with an access token. You can determine which
this access token by looking at the Graph API reference for the node or edge that y
APIs can also use the Graph API Explorer to quickly generate tokens in order to play ab
discover how it works.
Grafik API'si
Quickstart The /me node is a special endpoint that translates to the user_id
page_id of the Facebook Page) whose access token is currently being u
Using the Graph API
API calls. If you had a user access token, you could retrieve all of a user's
Reference
Advanced
Reklam API
The response you receive will vary based on the node or edge that you are reading
following general form:
{
"fieldname": {field-value},
....
}
Choosing Fields
By default, not all the fields in a node or edge are returned when you make a query
fields (or edges) you want returned with the "fields" query parameter. This is really
API calls more efficient and fast.
For example, the following Graph API call will only return the id, name, and picture
GET graph.facebook.com
/bgolub?
fields=id,name,picture
URL Lookup
Most objects can be discovered using their IDs, but there are times where this is no
have is a URL to identify something.
You can use the URL node that was introduced in v2.1 to return the IDs of
to find data associated with an App Link URL.
Learn more about finding App Link data with the Index API in our documentation fo
Some API endpoints can be used with extra parameters that will modify the reques
these 'modifiers' do varies, so we have documented each of them separately in eac
docs where appropriate. Below are a list of the more common modifiers that can be
endpoints.
locale Used if your app needs the ability to retrieve localized Locale
content in the language of a particular locale (when
available).
date_format In the Graph API the datetime field type will return a PHP
ISO-8601 formatted string but this modifier can be date()
used to change the format of the returned date. string
The field expansion feature of the Graph API, allows you to effectively nest multiple graph queries into a
single call. Certain resources, including most of Ads API, are unable to utilize field expansion on some or
all connections.
For example, you can ask for the first N photos of the first K albums, in one call. The response maintains
data hierarchy so developers do not have to weave the data together on the client.
Batch Requests is a different feature which allow you to make multiple, potentially unrelated Graph API
calls in a single request.
GET graph.facebook.com
/{node-id}?
fields=<first-level>{<second-level>}
<first-level> in this case would be one or more (comma-separated) fields or edges from the parent
node. <second-level> would be one or more (comma-separated) fields or edges from the first-level
node.
There is no limitation to the amount of nesting of levels that can occur here. You can also use a
.limit(n) argument on each field or edge to restrict how many objects you want to get.
This is easier to understand by seeing it in action, so here's an example query that will retrieve up to five
albums created by someone, and the last five posts in their feed.
GET graph.facebook.com
/me?
We can then extend this a bit more and for each album object, also retrieve the first two photos, and
people tagged in each photo:
GET graph.facebook.com
/me?
fields=albums.limit(5){name, photos.limit(2)},posts.limit(5)
Now we can extend it again by retrieving the name of each photo, the picture URL, and the people
tagged:
GET graph.facebook.com
/me?
fields=albums.limit(5){name, photos.limit(2){name, picture, tags.limit(2)}},
You can see how field expansion can work across nodes, edges, and fields to return really complex data
in a single request.
When you make an API request to a node or edge, you will usually not receive all of the results of that
request in a single response. This is because some responses could contain thousands and thousands of
objects, and so most responses are paginated by default.
Cursor-based Pagination
Cursor-based pagination is the most efficient method of paging and should always be used where
possible - a cursor refers to a random string of characters which mark a specific item in a list of data.
Unless this item is deleted, the cursor will always point to the same part of the list, but it will be invalidated
if an item is removed. Therefore, your app shouldn't store any older cursors or assume that they will still
be valid.
When reading an edge that supports cursor pagination, you will see the following JSON response:
{
"data": [
... Endpoint data is here
],
"paging": {
"cursors": {
"after": "MTAxNTExOTQ1MjAwNzI5NDE=",
"before": "NDMyNzQyODI3OTQw"
},
"previous": "https://graph.facebook.com/me/albums?limit=25&before=NDMyNzQyODI3OT
"next": "https://graph.facebook.com/me/albums?limit=25&after=MTAxNTExOTQ1MjAwNzI
before : This is the cursor that points to the start of the page of data that has been returned.
after : This is the cursor that points to the end of the page of data that has been returned.
limit : This is the number of individual objects that are returned in each page. Note that this is an
upper limit, if there are not enough remaining objects in the list of data, then less than this number
will be returned. Some edges have an upper maximum on the limit value, for performance
reasons. We will return the correct pagination links if that happens.
next : The Graph API endpoint that will return the next page of data. If not included, this is the last
page of data. Due to how pagination works with visibility and privacy it is possible that a page may
be empty but contain a 'next' paging link - you should stop paging when the 'next' link no longer
appears.
previous : The Graph API endpoint that will return the previous page of data. If not included, this
is the first page of data.
Cursors can't be stored for long periods of time and expected to still work. They are meant to
paginate through the result set in a short period of time.
Time-based Pagination
Time pagination is used to navigate through results data using Unix timestamps which point to specific
times in a list of data.
When using an endpoint that uses time-based pagination, you will see the following JSON response:
{
"data": [
... Endpoint data is here
],
"paging": {
"previous": "https://graph.facebook.com/me/feed?limit=25&since=1364849754
"next": "https://graph.facebook.com/me/feed?limit=25&until=1364587774"
}
}
until : A Unix timestamp or strtotime data value that points to the end of the range of
time-based data.
since : A Unix timestamp or strtotime data value that points to the start of the range of
time-based data.
limit : This is the number of individual objects that are returned in each page. A limit of 0 will
return no results. Some edges have an upper maximum on the limit value, for performance
reasons. We will return the correct pagination links if that happens.
next : The Graph API endpoint that will return the next page of data.
Offset-based Pagination
Offset pagination can be used when you do not care about chronology and just want a specific number of
objects returned. This should only be used if the edge does not support cursor or time-based pagination.
offset : This offsets the start of each page by the number specified.
limit : This is the number of individual objects that are returned in each page. A limit of 0 will
return no results. Some edges have an upper maximum on the limit value, for performance
reasons. We will return the correct pagination links if that happens.
next : The Graph API endpoint that will return the next page of data. If not included, this is the last
page of data. Due to how pagination works with visibility and privacy it is possible that a page may
be empty but contain a 'next' paging link - you should stop paging when the 'next' link no longer
appears.
previous : The Graph API endpoint that will return the previous page of data. If not included, this
is the first page of data.
Note that if new objects are added to the list of items being paged, the contents of each offset-based
page will change.
Offset based pagination is not supported for all API calls. To get consistent results, we
recommend you to paginate using the previous/next links we return in the response.
The standard version of the Graph API is designed to make it really easy to get data for an individual
object and to browse connections between objects. It also includes a limited ability to retrieve data for a
few objects at the same time.
If your app needs the ability to access significant amounts of data in a single go - or you need to make
changes to several objects at once, it is often more efficient to batch your queries rather than make
multiple individual HTTP requests.
To enable this, the Graph API supports a number of functions, including multiple ID lookup, and batching.
Batch requests are explained in a separate guide but you can read more about multiple ID lookup below.
GET graph.facebook.com
/?ids=platform,me
GET graph.facebook.com
/me
{
"me": {
"id": "1234567890"
... // Other fields
},
"platform": {
"id": "19292868552"
... // Other fields
}
}
This can also work with edges, as long as all the requested IDs have the requested edge, for example:
GET graph.facebook.com
/photos?ids={user-id-a},{user-id-b}
GET graph.facebook.com
/{user-id-a}/photos
GET graph.facebook.com
/{user-id-b}/photos
{
"{user-id-a}": {
"data": [
{
"id": "12345",
"picture": "{photo-url}",
"created_time": "2014-07-15T15:11:25+0000"
}
... // More photos
]
Note that while field filtering, field expansion, and limiting will work with these multiple ID lookups, you will
get an error if one of the objects does not have any of the requested fields - for example, if you were to
lookup a Page and a User using this method, and then filter to fields=id,picture,gender the
request would fail because Pages do not have a gender field.
Introspection
The Graph API supports introspection of nodes, which enables you to see all of the edges a node has
without knowing its type ahead of time. To get this information, add metadata=1 to the Graph API
request:
GET graph.facebook.com
/{node-id}?
metadata=1
The resulting JSON will include a metadata property that lists all the supported edges for the given
node:
{
"name": {node-name},
"metadata": {
"connections": {
"feed": "http://graph.facebook.com/me/feed",
"picture": "https://graph.facebook.com/me/picture",
....
}
"fields": [
{
"name": "id",
"description": "The user's Facebook ID. No `access_token` required. `strin
},
....
],
Publishing
Most nodes in the Graph API have edges that can be published to (such as /{user-id}/feed or
/{album-id}/photos). All Graph API publishing is done simply with an HTTP POST request to the
relevant edge with any necessary parameters included. For example, if you wanted to publish a post on
behalf of someone, you would make an HTTP POST request as below:
POST graph.facebook.com
/{user-id}/feed?
message={message}&
access_token={access-token}
All publishing calls must be signed with an access token. You can determine which permissions are
needed in this access token by looking at the Graph API reference for the node that you wish to publish
to.
There are a large number of edges which can be published to, which you can find in the reference doc for
each node.
We have a guide covering Common Scenarios for Graph API which includes a few frequent publishing
situations.
Updating
All Graph API updating is done simply with an HTTP POST request to the relevant node with any updated
parameters included:
POST graph.facebook.com
/{node-id}?
{updated-field}={new-value}&
access_token={access-token}
Deleting
You can delete nodes from the graph by issuing HTTP DELETE requests to them:
DELETE graph.facebook.com
/{node-id}?
access_token=...
Generally speaking, only content originally created by an app can be deleted by that app, but check the
reference guide for the node or edge in question to see whether you can delete using that API.
To support clients that do not support all HTTP methods, you can alternatively issue a POST request to an
endpoint with the additional argument method=delete to override the HTTP method. For example, you
can delete a comment by issuing the following request:
POST graph.facebook.com
/{comment-id}?
method=delete
Searching
You can search over many public objects in the social graph with the /search endpoint. The format for
searches is:
GET graph.facebook.com
/search?
q={your-query}&
[type={object-type}](#searchtypes)
All Graph API search queries require an access token included in the request. The type of access token
you need depends on the type of search you're executing.
Searches across Page and Place objects requires an app access token.
All other endpoints require a user access token.
user Search for a person (if they allow their name to be searched for). Name.
place Search for a place. You can narrow your search to a specific Name.
location and distance by adding the center parameter (with
latitude and longitude) and an optional distance parameter:
GET graph.facebook.com
/search?
q=coffee&
type=place&
center=37.76,-122.427&
distance=1000
placetopic Returns a list of possible place Page topics and their IDs. Use with None.
topic_filter=all parameter to get the full list.
ad_* A collection of different search options that can be used to find See
targeting options. Targeting
Options
docs
Handling Errors
Requests made to our APIs can result in a number of different error responses, and there are a few basic
recovery tactics. The following topic describes the recovery tactics, and provides a list of error values with
a map to the most common recovery tactic to use.
{
"error": {
"message": "Message describing the error",
"type": "OAuthException",
"code": 190,
"error_subcode": 460,
"error_user_title": "A title",
"error_user_msg": "A message"
}
}
Error Codes
102 API Session Login status or access token has expired, been
revoked, or is otherwise invalid - Handle expired
access tokens (unless subcode is present)
4 API Too Many Calls Temporary issue due to throttling - retry the
operation after waiting and examine your API
request volume.
17 API User Too Many Calls Temporary issue due to throttling - retry the
operation after waiting and examine your API
request volume.
200-299 API Permission (Multiple Permission is either not granted or has been
values depending on removed - Handle the missing permissions
permission)
1609005 Error Posting Link There was a problem scraping data from the
provided link. Check the URL and try again.
458 App Not The user has not logged into your app, try logging them in again.
Installed
460 Password On iOS 6 and above, if the person logged in using the OS-integrated
Changed flow, they should be directed to Facebook OS settings on the device to
update their password. Otherwise they must login to the app again.
463 Expired Login status or access token has expired, been revoked, or is otherwise
invalid - Handle expired access tokens
467 Invalid access Access token has expired, been revoked, or is otherwise invalid -
token Handle expired access tokens.
without a version specified, the API version that responds may not be known to you.
The Graph API supplies a request header with any response called facebook-api-version that
indicates the exact version of the API that generated the response. For example, a Graph API call that
generates a request with v2.0 will have the following HTTP header:
facebook-api-version:v2.0
This facebook-api-version header will allow you to determine whether API calls are being returned
from the version that you expect, and can be an indicator if your app switches to using a different version
when an older version expires.