Facebook developer blog

User login

Facebook Connect


Subscribe to our feed

Facebook news from across the web

Updated: 8 min 23 sec ago

Tue, 18/10/2011 - 10:00am

Many developers are now using HTML5 to build apps. It is easy to develop for and it works across a number of different platforms, with minimal or no code change. You can code in something as simple as Notepad, and instantly see it come to life in the browser on your desktop, phone, or tablet.

Today we are releasing three new HTML5 resources to help developers learn from our experience and the experience of other industry leaders building HTML5 apps:

  • helps you build, test, and deploy your web app.
  • covers a wide range of HTML5 topics written by Facebook and industry experts.
  • is the place for raising questions and sharing insights with fellow HTML5 developers.

What HTML5 Really Means

Technically, HTML5 is a World Wide Web Consortium (W3C) specification. In practice, it is the umbrella term for the set of open web technologies used to build modern web apps. These include HTML, of course, but also CSS, JavaScript, and a number of new APIs which, until recently, were only available to native apps (for example, offline capabilities). Combined, these new technologies enable you to build the next generation apps, using the web.

Cross-Platform, Cross-Device

Today almost every device, including phones, tablets, computers, and even TVs has a browser. Developers relying on HTML5 benefit from working with a single codebase that can run on all of these devices, so they build once and deploy everywhere within a minimal amount of changes for each device. Many developers, including Facebook, are using HTML5 in their mobile products, as it makes reaching users across many different devices simpler.

A practical example of this is the web app Words with Friends. Users can play this game just about anywhere. Zynga built it once using a single HTML5 codebase, allowing users to play it on their mobile phones, tablets, and desktop browsers. Check it out at http://m.zyn.ga/WWF.

Compatibility across platforms is only one part of the story. Getting your web app into the hands of users is the other.

Web apps can take advantage of existing social channels, including over 800 million Facebook users on desktop. Additionally, as of last week, mobile developers can reach over 350 million Facebook users on mobile.

Looking Ahead

The web already allows developers to create great apps and things are advancing rapidly. We hope these new HTML5 resources help accelerate the rate of innovation and improve the user experience of web apps.

Categories: Facebook

Fri, 14/10/2011 - 6:05pm

This week we , bringing all the social channels from Facebook on the Web to mobile apps. We also launched , and we posted a How-To for .

Finally, we announced the to help developers get hands-on experience building on technologies we launched at f8. The Roadshow will be coming to Seattle, New York, Chicago and Austin. It's already sold out in all cities except Chicago, where there are only a few seats remaining, so register now to reserve your place.

Graph API for Issuing FQL queries

One of the most common misconceptions we hear from developers is that will be deprecated with the . The reason for this misunderstanding is that, until now, you could only issue FQL queries using the or REST API methods. We'd like to reiterate that FQL is here to stay and will not be deprecated in the foreseeable future. In fact, today we are enabling developers to issue FQL queries using the . With this change, FQL is simply an extension of Graph API.

You can issue an HTTP GET request to https:///fql?q=QUERY to run an FQL query. The ‘q’ parameter can be a single FQL query or a multi-query. A multi-query is a JSON-encoded dictionary of queries.

Here is an example that shows how to issue a single FQL query as well as a multi-query with Graph API:

top.location.href='" . $dialog_url . "'"); } //get user access_token $token_url = '?client_id=' . $app_id . '&redirect_uri=' . urlencode($my_url) . '&client_secret=' . $app_secret . '&code=' . $code; $access_token = file_get_contents($token_url); // Run fql query $fql_query_url = 'https:///' . '/fql?q=SELECT+uid2+FROM+friend+WHERE+uid1=me()' . '&' . $access_token; $fql_query_result = file_get_contents($fql_query_url); $fql_query_obj = json_decode($fql_query_result, true); //display results of fql query echo '
'; print_r("query results:"); print_r($fql_query_obj); echo '
'; // Run fql multiquery $fql_multiquery_url = 'https:///' . 'fql?q={"all+friends":"SELECT+uid2+FROM+friend+WHERE+uid1=me()",' . '"my+name":"SELECT+name+FROM+user+WHERE+uid=me()"}' . '&' . $access_token; $fql_multiquery_result = file_get_contents($fql_multiquery_url); $fql_multiquery_obj = json_decode($fql_multiquery_result, true); //display results of fql multiquery echo '
'; print_r("multi query results:"); print_r($fql_multiquery_obj); echo '
'; ?>

For more information please see the . As part of this change, in the coming weeks, we will be moving all our FQL documentation into the Graph API documentation so that you can access all our reference APIs in one place.

Adding namespace property to application endpoint in Graph API

On the , we've added a property called namespace which returns the namespace for the app. The namespace is the canvas name of the app (e.g. https://apps./) and is used to scope objects and actions. Note that this property replaces the property previously called canvas_name.

Both namespace and canvas_name properties will be available for the next 90 days. We will be deprecating the canvas_name field in favor of namespace on February 1st 2012. We have updated the to reflect this change.

Detecting visibility of Flash objects in Canvas apps functionality not working

For Flash applications on using wmode=”window”, it is possible for the Flash objects to become hidden when popups occur, and then to be redisplayed when popups are dismissed. We recently the ability for apps to customize this behavior (e.g. show an image when this happens) by allowing them to pass in a callback function to the hideFlashCallback property passed in to .

We have discovered some bugs with the implementation and are still working through the issues; hence, this functionality is currently unavailable. We will post an update once these issues are resolved.

Breaking change reminder November 1st 2011

A friendly reminder about the coming on November 1st:

  • manage_notifications permission migration — To read or manipulate a user’s notifications, we will require you to get the manage_notifications permission.

activity for the past 7 days:

  • 745 total open bugs
  • 240 new bugs were reported
  • 23 bugs were reproducible and accepted (after duplicates removed)
  • 1 bugs was fixed
Facebook Stack Overflow Activity

Activity on facebook.stackoverflow.com this week:

  • 522 questions asked
  • 154 answered, 30% answered rate
  • 272 replied, 52% reply rate
Categories: Facebook

Fri, 14/10/2011 - 10:00am

At f8, we announced a redesigned Auth Dialog and a new authentication flow to give developers more control over people’s first experience with their apps. Today, we’re making these new tools available to all developers and their users.

Optimized Authentication Flow
We rebuilt the to make the authentication process easier for people to understand, so they’re more likely to install your app. In addition to uploading a logo, all developers can now display a headline and description of their app in the new dialog. User permissions are now more clearly presented and organized. And we’ve introduced an in-line privacy selector for apps that request publishing permissions to provide users with more control over activity from apps.

The new dialog also supports Open Graph aggregation previews. Developers can test this now, and once Open Graph is more widely available, users will be able to preview how their activity in an app will appear on their timeline. Learn more about for Open Graph integrations.

Extended Permissions
We believe that powerful permissions like ‘publish_checkins’ and ‘create_event’ are most effective when users understand the type of experience they can enable. With this redesign, extended permissions are always displayed in a second screen. We’ve also introduced an area on the extended permissions screen that lets you explain why you need extended permissions.

In the new Auth Dialog, users have the ability to grant access only to the extended permissions they’re comfortable with. You should make sure your app properly handles the cases when people remove permissions. You can visit the to see the permissions that are displayed on the second screen. We posted a earlier this week to help developers ensure that their apps don’t break when users revoke optional permissions.

We are making the new Auth Dialog available to all developers today. You can turn it on by going to the “Advanced Settings” page of the Dev App and manually enabling “Enhanced Auth Dialog.” Before you upgrade your app, we recommend that you customize your app’s Auth Dialog by visiting the “Auth Dialog Settings” page. We plan to migrate all apps to the new Auth Dialog before the end of the year, and we'll announce the specific timing in the next few weeks.

Authenticated Referrals, for a new class of social apps
After you upgrade to the new Auth Dialog, you can turn on , a new feature for apps and websites that are designed to be social from the ground up.

Authenticated Referrals streamlines the auth process for users and allows apps to receive a greater number of connected users. With the feature enabled, any link on Facebook to your app will prompt the user with an in-line Auth Dialog and ask them to authenticate before navigating to your app. The experience is fast, familiar, and happens while the user is still on Facebook. This way, apps that require Authenticated Referrals don’t need to redirect traffic to an separate login flow, and users can have a social experience the moment they arrive at your app.

By guaranteeing that all users navigating from Facebook to your app will be logged in, Authenticated Referrals allows you to build apps that are social by default. Authenticated Referrals is an option for developers, and we recommend that you turn it on it if you require people to connect to use your app. You can enable it on the “Auth Dialog Settings” page of the Dev App.

Insights Improvements
With these new products, we’re also working on improvements to Insights to help you optimize your auth flow. For both the new dialog and Authenticated Referrals, we will provide the number of dialog impressions and accepts, the sources of connected users, and the privacy settings that people are selecting for your content. You will also see a breakdown of your conversion rate for extended permissions and how frequently they’re revoked.

Updated user measurement methodology
We’ve traditionally measured and reported app usage based on the number of people who visit an app, similar to how many web analytics companies measure Internet traffic.

When we first built Facebook Platform, we designed it so that developers could choose when to ask users to authenticate with their app, similar to how registration flows vary across the web. Over time, we’ve found that more and more developers have standardized on asking users to authenticate before they can use the app at all.

Given that most apps work this way, we're changing our active user figures for Apps on Facebook to publicly report the number of users that authenticate with the app. We believe this shift from “visitors” to “authenticated users” more accurately reflects the usage of an application, and it brings our measurement methodology for apps into alignment with how we measure engagement on Facebook.

This change will have no impact on third party measurement tools like comScore and Omniture. Developers will be able to access both numbers (canvas visitors and authenticated active users) in Insights. While this change will result in a perceived decline in active users for some apps, the number of users actually engaging with an app or playing a game is unaffected by this change.

These new authentication tools are designed to help you get more connected users and build deeply social apps. We hope they increase your install rates, and we’ll continue iterating on them as we receive your feedback below.

Categories: Facebook

Wed, 12/10/2011 - 3:00pm

Join the Facebook Platform team as we travel throughout the United States to talk with developers about Open Graph and Timeline. This is a great opportunity to get hands-on experience with the new technologies we launched at f8 2011.

During this all-day program, we will host technical deep-dives, a Q&A with our Platform team, and an opportunity for you to work directly with Facebook engineers during "Office Hours".

If you want to learn more about the Open Graph and Timeline and what it means for your Facebook apps, this is the event to attend. Space is limited, so signup today.

CityDateRegistration ChicagoOctober 21http://fbf8chicago.eventbrite.com New YorkOctober 25http://fbf8ny.eventbrite.com SeattleOctober 27http://fbf8seattle.eventbrite.com AustinNovember 2http://fbf8austin.eventbrite.com
Categories: Facebook

Wed, 12/10/2011 - 1:00pm

A common question that developers ask is how to handle users that revoke optional permissions. Users are able to revoke permissions through their app settings on Facebook, and as a developer, it is important that you handle this situation to help drive the best user experience.

Below is an example that will help show how you can check if there are permissions that the app needs that are not granted by the user. The example renders three buttons:

  1. Login: Allows the user to authenticate the app with the permissions the app needs.
  2. Check Permissions: Checks to see if there are any permissions that the app needs but the user hasn’t authorized
  3. Remove Permission: Removes permissions that the app needs.

To use the example, you should first authenticate the app through the “Login” button. Next, click “Check Permissions” to make sure no new permissions are required. Now, click “Remove Permissions” to simulate a user removing the permissions. Finally, when you click “Check Permissions” again, you will be prompted for the missing permissions.

The functionality that checks to see if there are permissions the user has not granted occurs in the checkPermissions JavaScript function. To retrieve all user permissions granted to the app, the function issues an HTTP GET request to the following Graph API connection: https:///USER_ID/permissions

If there are any differences between the permissions the app needs and what the user has granted, the app should re-prompt the user for these missing permissions. To re-prompt the user for the missing permissions, the app can make a call to FB.login utilizing the scope parameter or one of the other authenication mechanism.

Categories: Facebook

Mon, 10/10/2011 - 1:00pm

Today, we are extending Facebook Platform on mobile, bringing all the social channels that have helped apps and games reach hundreds of millions of users on the Web to mobile apps and websites. You can now easily reach the 350 million people who use Facebook every month on a mobile device, including iPad, iPhone, iPod touch, and our mobile web site.

We are at the beginning of bringing Facebook Platform apps to mobile. The features we are launching today are still under development. They will evolve as we learn more about building richer social experiences on mobile devices. In addition, we will extend our native support for more mobile platforms such as Android in the near future. We are excited to see what you will build with these features today and look forward to working with you as we improve these features.

Social Channels on Mobile

like Bookmarks, Requests, and News Feed drive the discovery and distribution of apps using Facebook Platform. Until now, most of these social channels were only available to and on the desktop browser. Below highlights the changes we've made to bring social channels to mobile.


are one of the key re-engagement channels for Apps on Facebook. When a user engages with your app, a bookmark to your app is automatically added to a user’s main navigation on Facebook.

Now, people who use Facebook on the iPhone, the iPad, and the mobile web site (), will get bookmarks to the mobile versions of these apps. When users tap your app bookmark in our iPhone and iPad apps, we will launch it (if your native iOS app is installed). If your app is not installed, we will redirect the user to the App Store. On our mobile website () bookmarks will link to mobile web version of your app.


With the for mobile, users can invite their friends to your app. Friends can receive requests anywhere that your app is supported. For example, if a user plays a move in a game on , their friend can respond from her iPhone. As with bookmarks, users will tap the notification and land directly on the mobile version of your app, whether it is a native iOS app or a mobile web app.

News Feed

Users can already use the to share highlights from apps, but until now they have not been able to interact with those stories on their mobile devices. Now, people can see an interesting story on their mobile News Feed, tap the link, and land directly on the mobile version of your app, whether it is a native iOS app or a mobile web app.

Authenticated Referrals

is a new feature that ensures all referral traffic from Facebook to your app has users connected to Facebook. When users search and find a new app, or taps on a News Feed story or a Request from a mobile app they haven’t previously used, they will be prompted to log in before going to the app. This feature grants you the opportunity to build a deeply personalized experience as soon as users arrive at your app.

Facebook Credits

Today, we are also extending to support mobile web apps. Facebook Credits is a payment system that provides a safe, easy way for users to pay for virtual and digital goods. The for Apps on Facebook apply to mobile web apps, including the requirement to use Facebook Credits as their exclusive payment mechanism. Facebook Credits are not allowed in iOS apps or mobile web apps that are running within a Facebook iOS app.

Getting Started

Of the 350 million people who use Facebook from mobile devices every month, roughly half of those users access Facebook through the web and half use native apps. Social apps are all about interacting with your friends so the best social apps will be on both native iOS and web apps, and we encourage you to think about how to reach the total audience of Facebook users by building both.

If you already have a native iOS app, integration is as easy as implementing Single Sign-On using our . If you're building a mobile web app, you can leverage HTML5 to build an app that works across all modern devices, and get additional features by using technologies like PhoneGap for native distribution. See our for more information.

We have worked closely with some leading developers to create great new mobile web apps and we're just getting started. Today, you can enjoy apps from Audiovroom, Branchout, Flixster, Gilt Groupe, and Huffington Post, and games from EA, Moblyng, Storm8, Wooga, and Zynga. You can try out these apps by visiting fb.me/mobileappshowcase on your phone or tablet. Most of these apps are built using HTML5, providing an experience that seamlessly works across iOS, Android, and other mobile devices.

We will hold a Mobile Hack event in Silicon Valley on October 28th to help developers learn more about these features and build awesome apps. If you are interested in attending, sign up .

Please leave questions or feedback in the Comments below.

Categories: Facebook

Fri, 07/10/2011 - 4:19pm

This week, we published the and launched .

Getting and Setting App Restrictions using the Graph API

Some apps require demographic restrictions (i.e., location, age, age distribution, type). Now, you can restrict access to your app to a specific set of users by issuing an HTTP POST with an app access token to:

https:///APP_ID?restrictions={“RESTRICTION_TYPE:VALUE”, …}

Specify the RESTRICTION_TYPE and VALUE. If successful, the response will evaluate to true.

To retrieve your app restrictions, issue an HTTP GET with an app access token to:


Sample response:

{ "restrictions": { "location":"US" }, "id":"292980804060689" }

Full PHP example below that restricts an app to the US and reads back the restriction:

'; echo 'Set result: ' . $set_result . '
'; echo ''; // Get app restrictions list $restrictions_url = 'https:///' . $app_id . '?fields=restrictions&' . $app_access_token; $restrictions_result = file_get_contents($restrictions_url); $restrictions_obj = json_decode($restrictions_result, true); echo '
'; print_r($restrictions_obj); echo '
'; ?>

This information is also easily retrieved from the application FQL table:

SELECT restriction_info FROM application WHERE app_id=YOUR_APP_ID

Sample response:

[ { "restriction_info":{"location":"US"} } ]

For more information, please refer to documentation on the Graph API object and .

90-day migration due February 1, 2012: Use game:points instead of og:points

The Open Graph meta tag property og:points is being renamed to game:points to be more consistent with game.achievement og:type. Please migrate to use game:points instead of og:points. Both properties will continue to work until February 1st when og:points will stop working.

f8 comes to Asia, Europe, and more US locations

Post-f8, we began hosting developer events in Seoul and Singapore to help developers integrate with the Open Graph. Thank you to all who attended these events and made them successful. Our team will soon be visiting Tokyo, Europe, and other US locations later this month.


A couple of weeks ago, we a new . In the past week in the new bugs tools there were:

  • 239 bugs reported
  • 21 bugs accepted
  • 2 bugs fixed

Although no new bugs can be filed in Bugzilla, we will continue working on closing out the remaining open bugs in Bugzilla. The total number of open bugs in Bugzilla is now 1,260 (down 121 from last week).

Facebook Stack Overflow activity

Activity on facebook.stackoverflow.com this week:

  • 402 questions asked
  • 98 answered, 24% answered rate
  • 218 replied, 54% reply rate
Categories: Facebook

Thu, 06/10/2011 - 8:00pm

Today we are launching to help Page admins understand how their content resonates with users. Measure everything from the number of stories about a Page to how viral a specific post has become. These new metrics are available today via , and the . For a list of the new metrics see the .

Graph API Examples

Getting Page Insights

In order to obtain Page Insights via the Graph API, you must use a , and you must have the read_insights permission. Click on the link below to see this working in the Graph API Explorer.

In the Graph API Explorer, click the "Get Access Token" button to obtain the read_insights and manage_pages permissions (listed under "Extended Permissions"). Click "Submit" to retrieve the list of Pages that you admin now that you have a valid access token. Page access tokens for those Pages you administer should now be listed. Copy the Page access token for the Page for which you want to retrieve Insights for, and paste it into the Access Token field at the top of the Graph API Explorer. The following examples assume that you are using this Page access token to make requests.

Once you have a list of Page IDs and an access token, you can pull many of the new metrics with a single call:


Here's a snippet showing Page stories from the response:

{ ... "name": "page_stories", "period": "day", "values": [ { "value": 101, "end_time": "2011-10-02T07:00:00+0000" }, ... }

Reading Page posts

To see a list of your Page posts, issue an HTTP GET to:


The response will look something similar to the response below. Please note the post ID (in bold).

{ "data": [ { "id": "129228016794_271029229588214", "from": { "name": "U.S. Politics on Facebook", "category": "Website", "id": "129228016794" }, ... } ... ] }

You can now issue an HTTP GET to the [POST ID]/insights endpoints to get per post Insights:

https:///[POST ID]/insights

Here's a response for post_impressions_unique:

{ "data": [ { "id": "129228016794_271029229588214/insights/ post_impressions_unique/lifetime", "name": "post_impressions_unique", "period": "lifetime", "values": [ { "value": 1311 } ], "description": "Lifetime The number of people who saw your Page post. (Unique Users)" }, ... ] }

To make more efficient calls, you can limit the metrics you retrieve to a specific time range. For example, the following Graph API call retrieves the page_storytellers for the past 28 days:

{ "data": [ { "id": "129228016794/insights/page_storytellers/days_28", "name": "page_storytellers", "period": "days_28", "values": [ { "value": 8987, "end_time": "2011-07-18T07:00:00+0000" } ], "description": "28 Day The number of people sharing stories about your page. These stories include liking your Page, posting to your Page's Wall, liking, commenting on or sharing one of your Page posts, answering a Question you posted, RSVPing to one of your events, mentioning your Page, phototagging your Page or checking in at your Place. (Unique Users)." } ], ... } FQL Example

The examples above are also available via . To obtain unique post impressions, follow the example FQL query below. You will need to obtain the same permissions above: (read_insights and manage_pages).

SELECT metric, value FROM insights WHERE object_id=19292868552 AND metric='page_posts_impressions_unique' AND end_time=end_time_date('2011-07-18') AND period=period('days_28')

Snippet of response:

[ { "metric":"page_posts_impressions_unique", "value":2922074 } ]

For more information on all the Insights metrics, please visit our . Please let us know if you have any questions in the Comments below.

Categories: Facebook

Tue, 04/10/2011 - 5:30pm

As in May, all apps must support OAuth 2.0 for authentication and HTTPS (Canvas and Page Tab apps only) by . Now that this date has passed, we are moving forward with a plan to remove all non-OAuth endpoints and limit the distribution of Canvas and Page Tab apps that have not provided a Secure URL.

Enabling signed_request and encrypted access token Platform Migrations

Starting today, we are auto-enabling two migrations in the Dev App: signed_request for Canvas and Encrypted Access Token.

With the for Canvas migration enabled, will no longer work. For a guide for how to use signed_request, see our .

With the Encrypted Access Token migration enabled, the format of the access token has changed. The new access token format is completely opaque and you should not take any dependency on the format in your code. A varchar(255) field will be sufficient to store the new tokens.

Encouraging apps to provide a Secure URL

For Canvas or Page Tab apps that do not have a Secure Canvas or Page Tab URL configured, we will begin to show users the following interstitial if they have secure browsing enabled:

Once the Secure Canvas or Page Tab URL field is filled appropriately, this interstitial will be removed. You can do this with the DevApp by specify the Secure Canvas URL and Secure Page Tab URL as below:

We may announce other steps in the near future that will limit the distribution of Apps on Facebook that do not support Secure Canvas or Page Tab URLs.

Removing non-OAuth endpoints

On October 11th, apps using the old JavaScript Library (FeatureLoader.js) or the old iPhone SDK (facebook-iphone-sdk) for authentication will no longer be able to authenticate users until these apps switch to .

We are currently evaluating when we are going to remove the endpoints supporting the old PHP SDK (versions prior to v.3.1.1) as well as non-OAuth authentication in the current JavaScript SDK.

If are using an old version of the PHP SDK, please go to github to version 3.1.1. If you are using the JavaScript SDK, please opt-in to using OAuth 2.0. Enable this by specifying the and using FB.getAuthResponse to obtain the access token.

Please let us know if you have any questions in the comments below.

Categories: Facebook

Fri, 30/09/2011 - 6:00pm
f8 Videos Available

We had an awesome f8 conference in San Francisco last week. Thanks for everyone who attended or participated via one of the many viewing parties. Videos of all of the f8 sessions are now available online at .

Scraping OG Objects

We’re already hard at work improving the Open Graph since last week’s announcement. This week, to make updating Open Graph objects easier, we’ve released the ability to scrape objects at the same time as you publish actions. Just add scrape=true to the POST parameters when publishing the action:

https:///me/recipebox:cook? scrape=true& method=POST& recipe=http://www.example.com/pumpkinpie.html& access_token=YOUR_ACCESS_TOKEN

Note that you only need to scrape an object if the meta tags have changed. If we ever encounter an URL that we've never scraped, we will scrape it regardless of the absence (or presence) of the scrape parameter. We also automatically scrape objects approximately every seven days, though we will respect Expires: headers. See the Open Graph documentation on for the full details.

Reminder: Breaking Changes coming on Oct 1st

The following breaking changes are slated to go into effect on the 1st of October:

  1. OAuth 2.0 Migration

    All apps must migrate to OAuth 2.0 for authentication. The old SDKs, including the old JavaScript SDK (FeatureLoader.js) and old iOS SDK (facebook-iphone-sdk) will no longer work.

  2. Apps on Facebook authentication and security migration

    All Canvas and Page tab apps must convert to process signed_request (fb_sig will be removed) and obtain an SSL certificate for use in Secure Canvas URL and Secure Page Tab URL (unless you are in Sandbox mode).

  3. Auth 1.0 deprecation

    Auth.promotesession, auth.createtoken, auth.expiresession, auth.getsession will be removed on Oct 1st. Details on support for .

  4. manage_pages permission required to access user accounts (/me/accounts)

    We are modifying access to the FQL page_admin table and the /me/accounts endpoint. Previously, with basic permissions granted, an app could go to this endpoint or the FQL table to access the list of a users’ apps and Pages. We are going to require that apps have the manage_pages permission in order to obtain access to this information.

We will post an update on the rollout plan on Monday, Oct 3rd (the changes themselves will proceed as planned).

Canvas Ticker Flyouts

Last week, we launched flyouts for the Canvas ticker. These flyouts appear when a user hovers over or clicks on a ticker story. They provide richer information to users about what's going on with their friends, and often allow users to like and comment on the story.

For games, we have also launched “passing stories” in the Canvas ticker. These are stories in which gamers are informed when one friend gets a new high score which exceeds another friend's high score. This is most appropriate for arcade-style games where you get a score each time you play. To have these stories appear for your app, make sure to use the in the Graph API each time your user gets a new high score.

One important side effect of this change, for apps using Adobe Flash, is that it is more important than ever that your app use "opaque" mode for any flash objects occurring within the iframe. If you don't, your game will be hidden when a popup occurs. Please see for more information.

Support for Multiple Domains in the Developer App

We have heard from developers that only being able to set one App Domain in the Developer App is sometimes not enough. For example, if you are redirecting users for geographic distribution of load, you may want to redirect some users to a URL in the myapp.com domain, while redirecting others to a URL in the myapp.co.jp domain. Now, you can do this in the Developer App. Simply set multiple domains in the App Domain field:

Now, you can specify a redirect_uri in either domain. Your App’s URL (Website and/or Mobile Web URL) must be derived from one of the domains listed in the App Domain field.

Resources from “Making Fast Social Apps” talk at f8

After last week’s f8 conference, several people asked for references to the resources mentioned during this talk. Here are the links mentioned in the presentation:


A couple of weeks ago, we a new . In the past week in the new bugs tools there were:

  • 381 bugs reported
  • 22 bugs accepted
  • 7 bugs fixed

Although no new bugs can be filed in Bugzilla, we will continue working on closing out the remaining open bugs in Bugzilla. The total number of open bugs in Bugzilla is now 1,381 (up 56 from last week, due to re-opened bugs).

Facebook Stack Overflow activity

Activity on facebook.stackoverflow.com this week:

  • 574 questions asked
  • 178 answered, 31% answered rate
  • 316 replied, 55% reply rate
Categories: Facebook

Thu, 29/09/2011 - 5:30pm

Requests are an important for users to communicate with their friends from within apps. Coupled with the announced at f8 last week, Requests continue to be a core part of how people share app activity with friends.

As part of the , we will stop supporting our old request model and will no longer fix bugs on January 1, 2012. We highly encourage all developers to move to by this date. Today we're announcing several new features to to make the process of sending and receiving requests even more efficient for users and developers.

New features for Requests 2.0

We have heard repeated feedback from developers and users that requiring users to click ‘Send Request’ every time they wish to send requests to the same friends interferes with game play and limits sharing. To reduce this friction, we’re introducing frictionless Requests, which improves the experience for both users and developers.

Frictionless Requests enable users to send requests to specific friends from within an app without having to click on a pop-up confirmation dialog. Upon first sending a request to a friend from within an app, a user may authorize the app to send subsequent requests to the same friend without prompting for his permission. By default, the check box is checked. This removes a dialog from the flow and streamlines the process of sharing with friends.

To enable frictionless Requests you must initialize the JavaScript SDK with ‘frictionlessRequests:true’. You’ll send requests to users via the Requests Dialog just as before. As users share with friends, they may authorize the app to send future requests to specific friends on their behalf.

You can specify an array of user_ids in the ‘to’ field of the request dialog. Only if all of the user_ids are frictionless, the confirmation dialog will not display and the users will be notified of the request. If even one of the recipients is not frictionless, the confirmation dialog will be displayed and the user must press ‘Send Request’ for the requests to be sent.

Here’s a full JavaScript example for how to use frictionless requests.

Frictionless Request Example

Performance improvements

We have spent the past few months on rewriting the back-end for requests to make them faster to ensure users have the best experience with Requests 2.0. However in doing so, we ran into issues which require a breaking change to Requests 2.0 to make them more efficient.

To opt-into higher performance Requests 2.0 enable the migration “Requests 2.0 Efficient” in the developer app. This setting is available in the Advanced section of your app settings.

Setting the ‘Request 2.0 Efficient” in the app migration changes the format for request IDs in the JavaScript requests callback method.

Previously the response param that looked like:

{ request_ids: ‘request_id1, request_id2, …’ }

With the “Requests 2.0 Efficient” migration, the JavaScript request callback method now receives a response param like below to represent the changes to the request ids explained above:

{ request: ‘request_id’ to:[array of user_ids] }

A request now has a single ID representing the actual request object and is then concatenated with the user_id to create the full request ID which represents the request for the specific recipient.

This prevents a developer from having to make a second GET request back to the Graph API to identify the recipients once a request has been sent. To construct the request ID for a user you concatenate as follows: ‘_’. Thus the request IDs from the example above would be:

150785095008591_499802820 180646335344553_499802852

To delete a request, the developer must issue an HTTP DELETE request to:

DELETE https:///[_]?access_token=[USER or APP ACCESS TOKEN]

Note: You can concatenate the request_id and user_id without doing the migration so that you can verify everything works before actually migrating.

Here is a full PHP sample which shows you how to concatenate the request_id and user_id in order to delete the outstanding requests for a user.

'YOUR_APP_ID', 'secret' => 'YOUR_APP_SECRET', ); $facebook = new Facebook($config); ?> Deleting Requests Example getUser(); if ($user_id) { //Get the Request Ids $request_ids = explode(',', $_REQUEST['request_ids']); //Construct full Request_Id function build_full_request_id($request_id, $user_id) { return $request_id . '_' . $user_id; } //For each Request construct full Request_id and Delete foreach ($request_ids as $request_id) { echo ("reqeust_id=".$request_id."
"); $full_request_id = build_full_request_id($request_id,$user_id); echo ("full_reqeust_id=".$full_request_id."
"); try { $delete_success = $facebook->api("/$full_request_id",'DELETE'); if ($delete_success) { echo "Successfully deleted " . $full_request_id; } else { echo "Delete failed".$full_request_id; } } catch (FacebookApiException $e) { echo "error"; } } } //User TOS if user has not authenticated your App else if (!isset($_REQUEST['error'])){ $params = array( 'redirect_uri' => 'http://localhost/~namitag/requests.php' ); $loginUrl = $facebook->getLoginUrl($params); echo ''; } else { echo ("user denied permission"); } ?> Migrations and breaking changes

Starting today new apps will automatically be opted into and “Requests 2.0 Efficient" and these migrations will no longer be available in the app settings for new apps. This requires developers to use the new request_id format as detailed above. In addition when a user is directed to your app, by clicking a Request from the app, the games dashboard, or from a Request notification, you must delete the request after it has been accepted. These are not automatically deleted once they have been clicked, thus it is the developer’s responsibility to clear them once they have been consumed. See sample above for how you can delete these requests.

In 90 days - on January 1, 2012- existing apps will be opted into “Requests 2.0 Efficient” and "Upgrade to Requests 2.0" migrations and all developers must ensure that they are using the correct request_id format and deleting requests appropriately.

We look forward to improved requests experience with frictionless Requests and our performance improvements. For more information reference our documentation . Please provide feedback and thoughts in the comments below.

Categories: Facebook

Thu, 29/09/2011 - 5:00pm

When Platform launched in 2007, FBML was a key component for developers building on Facebook, with millions of apps successfully built using this technology. Over time, as Platform matured and embraced open standards, such as OAuth 2.0, HTML, and Javascript, the need for FBML has decreased. Last August, we announced our intent to move away from FBML. In , we removed the ability to create new FBML apps. Today, we are announcing the FBML deprecation schedule:

  • January 1, 2012: FBML will no longer be supported. We will not fix FBML bugs after this date with the exception of security and privacy issues
  • June 1, 2012: FBML apps will no longer work on Facebook. All FBML endpoints will be removed.

We realize that some of you may still be relying on FBML for your apps. We want to make sure that you have all the resources you need for an easy and speedy migration. Over the past few months, we’ve been working with developers to understand the remaining use cases for FBML. Based on these conversations, we identified two primary use cases remaining: Requests and Static FBML tabs on Pages.


We have already announced the new and improved which should make migrating from FBML Request much simpler. To upgrade to Requests 2.0, apps should send requests by using the . To learn more about Requests 2.0 and how to migrate from FBML Requests, see our documentation on .

Static FBML

Custom tabs on Pages are an important aspect of Facebook Platform. Many developers and Page admins rely on for hosting this content. With the deprecation of FBML, this content must be moved to an iFrame based solution. There are several free iFrame solutions available that allow easy migrate Static FBML content to HTML. The on Facebook is a great tool to find PDCs to help guide you through the upgrade process. In addition, we have worked with WildFire, one of these PDCs, to create a step by step tutorial to guide your migration. The tutorial is available here.

We are excited to move into a modern, standards based Platform. Please provide feedback and thoughts in the comments below.

Please Note: Our deprecation of FBML does not impact (eXtended Facebook Markup Language). XFBML is a set of XML elements that can be included in your HTML pages to display Social Plugins. When your page is loaded, any XFBML elements found in the document are processed by the JavaScript SDK, resulting in the appropriate plugin being rendered on your page. The JavaScript SDK will continue to support XFBML after the deprecation of FBML (save for the fb:serverFbml element which is used to execute FBML on our servers).
Categories: Facebook

Thu, 29/09/2011 - 10:15am

Many of you have received an email by . To help Canvas and Page Tab App developers more easily update their Secure URLs, we have pushed changes to that let you set your secure_callback_url and secure_page_tab_url programmatically. You can read the documentation for this API method . You will need to use an app access token and the secure_callback_url and secure_page_tab_url must be a fully qualified URL beginning with https:// and must point to a directory (i.e., end with a '/') or a dynamic page (i.e., have a '?' somewhere).

For example:

'; echo $app_token_url; echo ''; $app_access_token = file_get_contents($app_token_url); echo '

'; echo $app_access_token; echo '
'; // Set Secure URLs - modify to the appropriate URLs $set_url = 'https://api./method/admin.setAppProperties?' . 'properties={"secure_callback_url":"https://www.example.com/canvas/",' . '"secure_page_tab_url":"https://www.example.com/pagetab/"}&' . $app_access_token; echo $set_url; $set_result = file_get_contents($set_url); echo '
'; echo 'Set result: ' . $set_result . '
'; echo '
'; ?>

We will soon provide this functionality in the Graph API, but wanted to first provide this REST API to help developers meet the October 1st deadline.

FBML apps

We have heard that there is some confusion about whether FBML apps must support HTTPS. FBML developers still need to know whether users are browsing Facebook over a secure connection since they need to detect whether to serve iframe or video content over HTTPS. As a result, FBML apps must obtain SSL certificates in order to serve this type of content to users browsing over a secure connection. If you have an FBML app, please obtain an SSL certificate for your app to receive traffic from users browsing Facebook over a secure connection.

If you enable SSL for your FBML app, please make sure that your SSL certificate includes all intermediate certificates in the chain of trust as our SSL validation is strict. You can use third-party SSL analysis tools (e.g., https://www.ssllabs.com/index.html) to check your certificate status and fix any errors (and warnings). If your SSL certificate has problems, you may see "Empty response received" error when you load your FBML canvas app.

Please let us know if you have any questions in the comments below.

Categories: Facebook

Fri, 23/09/2011 - 4:00pm

This week we hosted f8 and announced several new, exciting features for Facebook Platform. You can catch up by the recorded videos from the f8 live stream, reading explaining the changes, or watching which will help get you started building on all the new features.

Renaming setAutoResize to setAutoGrow

There have been several bugs reported about how doesn’t set the height of the iframe correctly in some scenarios. We have been trying to fix this and and have pushed various fixes to ensure that it works correctly for the case when the iframe grows in height. We however came to the conclusion that it is hard for us to do this accurately when the iframe shrinks in height. As a result we are renaming this function to so that it accurately reflects its functionality. If your iframe is shrinking for whatever reason we recommend that you use FB.Canvas.setSize with a height parameter to set the iframe height explicitly.

As part of this change, you should be able to use FB.Canvas.setAutoGrow today. FB.Canvas.setAutoResize will work for the next 90 days and we will remove support for this method on January 1st, 2012. Here is some sample code to test the grow functionality.

FB.Canvas.setAutoGrow Example
Getting mutual friends in the Graph API

This week we added a connection for the that allows you to get the list of mutual friends between two users. To use it, just get an access token for the current user and issue a GET request to:


You will receive a JSON object containing an array of user names and IDs who are friends with both users. For example, to see if you and have any mutual friends, check out in the .

More fields available for the Application object in the Graph API

This week, in addition to the exisiting fields, we made it possible to access the following fields for the in the Graph API:

  • canvas_name
  • logo_url
  • icon_url
  • company
  • daily_active_users
  • weekly_active_users
  • monthly_active_users

You’ll receive a JSON object containing the properties mentioned above as well as the others outlined in the .

How apps are indexed in search

There has been some confusion in the past on what it takes for your app to show up in search. It’s now very simple. We have removed the “Submit to Search" link from the app settings page. Now, when your app reaches 10 monthly active users it will be queued to be indexed the next time we rebuild our index (we rebuild every 2-4 weeks). If you already have 10 monthly active users it will be added to the indexing queue immediately.

Reminder: Breaking Changes coming on Oct 1st

The following breaking changes are slated to go into effect on the 1st of October:

  1. OAuth 2.0 Migration

    All apps must migrate to OAuth 2.0 for authentication. The old SDKs, including the old JavaScript SDK (FeatureLoader.js) and old iOS SDK (facebook-iphone-sdk) will no longer work.

  2. Apps on Facebook authentication and security migration

    All Canvas and Page tab apps must convert to process signed_request (fb_sig will be removed) and obtain an SSL certificate for use in Secure Canvas URL and Secure Page Tab URL (unless you are in Sandbox mode).

  3. Auth 1.0 deprecation

    Auth.promotesession, auth.createtoken, auth.expiresession, auth.getsession will be removed on Oct 1st. Details on support for .

  4. manage_pages permission required to access user accounts (/me/accounts)

    We are modifying access to the FQL page_admin table and the /me/accounts endpoint. Previously, with basic permissions granted, an app could go to this endpoint or the FQL table to access the list of a users’ apps and Pages. We are going to require that apps have the manage_pages permission in order to obtain access to this information.


We have now finished updating all of the . This week we updated the following docs:

We have also now finished updating all of the . This week we updated the following docs:

All of the is also now up to date. This week we updated the following dialog docs:

Additionally we updated the , the , the , and the .


Last week we a new . In the past week in the new bugs tools there were:

  • 208 bugs reported
  • 27 bugs accepted
  • 5 bugs fixed

Although no new bugs can be filed in Bugzilla, we will continue working on closing out the remaining open bugs in Bugzilla. The total number of open bugs in Bugzilla is now 1,325 (down 145 from last week).

Facebook Stack Overflow activity

Activity on facebook.stackoverflow.com this week:

  • 507 questions asked
  • 135 answered, 27% answered rate
  • 256 replied, 50% reply rate
Categories: Facebook

Fri, 23/09/2011 - 9:30am

At Facebook's core is the social graph; people and the connections they have to everything they care about. Historically, Facebook has managed this graph and has expanded it over time as we launch new products (photos, places, etc.). In 2010, we extended the social graph, via the Open Graph protocol, to include websites and pages that people liked throughout the web. We are now extending the Open Graph to include other actions and objects created by apps and enabling these apps to integrate deeply into the Facebook experience.

This “How-To” video walks you through showing you step-by-step how to build an Open Graph app that allows users to publish stories about cooking recipes.

We are really excited about the new class of apps that are now made possible. The Open Graph Beta is available for you to try out and .

Please let us know if you have any questions or feedback in the comments below.

Categories: Facebook

Thu, 22/09/2011 - 11:30am

We are hosting our fourth today in San Francisco, where we’re introducing the the next evolution of Facebook Platform and the Open Graph. The is the most significant update to Platform since it launched in 2007, expanding the capabilities and opportunities for social apps, from music to TV to news to lifestyle apps such as cooking, fitness, and travel.

We launched the Like button at last year's f8, and it quickly became one of the most popular tools on the Internet. As we have continued to introduce more features on Facebook Platform, now more than 500 million people engage with Facebook across more than 7 million apps and websites every month. Compared to f8 last year, this is close to double the number of people and triple the apps and websites.

Introducing Timeline

As part of f8, today we announced . Timeline is a page on which you can put the events and activity that matter most to you. We provide some of the most important stuff that you'd want to put there, like photos and major life events -- but those types of content are really just the start. With the Open Graph, you, as Facebook developers, can enable people to truly make their Timelines their own.

All developers will have access to a pre-release version of Timeline for testing after is configured to use . We encourage you to take a tour and learn more about .

Timeline will launch to users in the coming weeks. People will be able to add apps to their Timeline to show friends what they love, seamlessly update Timeline with their activity as they go, and have an easy way to reengage with the app.

For example, I love to cook. I want an app that lets me add the recipes I cook on my profile, and at the same time, discover my friends' recipes. The opportunities are endless, such as building an app for runners to share their routes and achievements, photographers to feature the photos they take, and music lovers to share their playlists and top albums with friends. Develop Open Graph apps that will make Timeline the personal, expressive page we believe it can be.

App Discovery through friends

App discovery is an important part of the Open Graph philosophy. The structure of the Open Graph enables apps to grow more quickly based on usage. The more engaging your app is, the more people will discover it on Facebook.

As people add apps to their Timeline, friends will be able to easily discover and connect to your app in just a few clicks, as they see it on not only each other’s Timelines, but in News Feed, or the newly launched Ticker.

Distribution based on user activity and engagement

Distribution through News Feed, Ticker, and Timeline will be based on Graph Rank, the underlying system that manages discovery of Open Graph activity around Facebook. Graph Rank is designed to give more prominence to engaging activity. The transparency of the system should enable you to predictably measure your app’s performance.

Graph Rank is also personalized. We know people are friends with both their college roommates and their colleagues at work, and those relationships are different. Just because my mom is interested in the movies I am watching doesn't mean she is interested in my Github checkins. Graph Rank isn't a global score, but a personalized view of you and your friends' tastes.

New analytics

From the , you will be able to see for all the Open Graph activity published by your app. You will be able to optimize your app’s Graph Rank based on this information.

Any app can be social

As the Open Graph opens up Platform to more categories and verticals, many more types of apps will be successful on Facebook because Open Graph isn't just about sharing - it's about self-expression and serendipity. Whether you have a Website, App on Facebook or Mobile app, you can make it Open Graph-enabled so users can see their activity on Timeline.

New Opportunities

We are excited about the sites launching later today with Open Graph apps. Learn more about these sites on the .

The Open Graph Beta is now available to all Facebook developers. This beta gives you access to the you need to add Open Graph actions and objects to your app. Stay tuned for more information later today on and on the Developer Blog on how to get started with the new Open Graph features.

Categories: Facebook

Tue, 20/09/2011 - 10:00am

With just 2 days until f8, we are in the final stages of preparation! Whether you'll be attending in person on Thursday or will be watching on , our livestream channel, here's everything you need to know to stay connected with our developer conference.

Updated Information on Transforming Industries track

We are excited about the lineup of panelists we have confirmed for the session track. In this track, you will hear from seasoned engineers, entrepreneurs and VCs as they share strategies for building innovative social products that remake industries.

The Future of Digital Music:
The music landscape is evolving with new channels and innovative social experiences. Leaders in the industry will describe where things are headed.
Bob Pittman - Chairman, Clear Channel Media and Entertainment
Daniel Ek - CEO, Spotify
Troy Carter - Founder, Chairman and CEO, Atom Factory

Mobile + Social:
As mobile apps become ever more social, new opportunities are emerging. Listen to mobile developers discuss social and the future of mobile.
Paul Bettner - Vice President and General Manger, Zynga
Kristian Segerstrale - General Manager and Co-founder, Playfish
Alexa Andrzejewski - Co-Founder and CEO, Foodspotting
Billy Chasen - Co-Founder and CEO, Turntable.fm

The Rise of Social Gaming:
Social gaming is disrupting the traditional video game business. Top game executives will provide their views on the next big trends.
Barry Cottle - Executive Vice President, EA interactive, Electronic Arts
Kevin Chou - CEO, Kabam
John Pleasants - Co-President, Disney Interactive Media Group
David Chiang - Co-President of Games, Zynga

Investing in Social:
Hear leading venture capitalists discuss their views on the future of the social web.
David Sze - Partner, Greylock Partners
Matt Cohler - General Partner, Benchmark Capital
Kevin Efrusy - Partner, Accel Partners
Bing Gordon - Partner, Kleiner Perkins Caufield & Byers

Download our Mobile App If you are planning to attend f8, we’ve built an easy to use mobile app, powered by Guidebook, to help you plan your day and stay sync’ed at f8. To access the f8 mobile app, download the Guidebook app from the iPhone App Store or the Android Marketplace or visit http://guidebookapp.com/getit from your phone’s browser. Find the f8 2011 guide by searching 'f8 Developer Conference' from the guide download screen.

Keep up with announcements at f8 For those who can't make it to f8 in person, we're streaming the entire day including keynotes, sessions and interviews with partners, developers and Facebook product teams. We’ll have a full day of engaging content live from the Concourse on Thursday. Tune in to the Livestream on the or at . This will be your main hub for connecting to the event and interacting with the Facebook team and other developers from around the world.

Be sure to like the and follow regularly, including Thursday during the event. Join the f8 conversation by status tagging the in posts on Facebook, commenting in , and using the #f8 hashtag on Twitter. We'll be checking all of these channels throughout the day for your input.

We are counting down the hours and look forward to seeing you on Thursday!

Categories: Facebook

Fri, 16/09/2011 - 6:59pm

This week we announced the following:

  • A faster, more efficient way to report bugs with a .
  • : developers can directly start building an app in your choice of languages, including PHP, Ruby, Node.js and Python at no cost.
  • A redesign of to make it easier for you to see the current status, issue history, and API health of our Platform.
Managing Events Now Available in the Graph API

This week, we released a long-awaited update to our Graph API for . Through the , apps are now able to create, view, delete, and query RSVP status for user events.

See our and the documentation for the Graph API object for the full details.

Facebook Credits: Opening Features to All Developers

With the Facebook Credits migration now complete, we are announcing several upcoming changes to the program in an effort to better support the broader developer ecosystem.

Starting October 14, the following changes will be made to support developers integrating Facebook Credits as a Currency and Facebook Credits as a Payment Method:

  • DealSpot Ad-Targeting Engagements and Broad Category Targeting will be made available to both types of implementations.
  • Games Dashboard Featured Status and Social Placements will be evaluated on a case by case basis, such as for game quality, genre and new functionality.

During the initial Credits roll out, developers who integrated Facebook Credits as a Currency benefited from early access to these features. Soon, all implementations of Facebook Credits will be able to take advantage of these features.

For additional details, please visit: .

Reminder: Breaking Changes coming on Oct 1st

The following breaking changes are slated to go into effect on the 1st of October:

  1. OAuth 2.0 Migration

    All apps must migrate to OAuth 2.0 for authentication. The old SDKs, including the old JavaScript SDK (FeatureLoader.js) and old iOS SDK (facebook-iphone-sdk) will no longer work.

  2. Apps on Facebook authentication and security migration

    All Canvas and Page tab apps must convert to process signed_request (fb_sig will be removed) and obtain an SSL certificate for use in Secure Canvas URL and Secure Page Tab URL (unless you are in Sandbox mode).

  3. Auth 1.0 deprecation

    Auth.promotesession, auth.createtoken, auth.expiresession, auth.getsession will be removed on Oct 1st. Details on support for .

  4. manage_pages permission required to access user accounts (/me/accounts)

    We are modifying access to the FQL page_admin table and the /me/accounts endpoint. Previously, with basic permissions granted, an app could go to this endpoint or the FQL table to access the list of a users’ apps and Pages. We are going to require that apps have the manage_pages permission in order to obtain access to this information.

90 Day Deprecation Announcement

The following breaking change is slated to go into effect on the 1st of January, 2012


We are deprecating FB.Data.waitOn and FB.Data.query. We noticed that these APIs are relatively sparsely used, and this functionality can be easily accomplished by FB.api.


This week, we publish an entirely new .

We updated the documentation for the following tables:

We updated the documentation for the following APIs:

We also updated the docs for the .

72 docs are under review. Bugs

This week, we introduced our new , a replacement for Bugzilla (now read-only), as such we're reporting the new bug tool stats going forward as well as stats for Bugzilla.

There are in the .

Bugzilla activity for the past 7 days:

  • 226 new bugs were reported
  • 22 bugs were reproducible and accepted (after duplicates removed)
  • 4 bugs were fixed (none of which were reported this week)
  • As of today, there are 1,470 open bugs in Bugzilla (up 225 from last week)

Facebook Stack Overflow Activity

Activity on facebook.stackoverflow.com this week:

  • 570 questions asked
  • 138 answered, 24% answered rate
  • 295 replied, 52% reply rate

Categories: Facebook

Fri, 16/09/2011 - 5:30pm
The Graph API already supported creating and deleting events. Now, you can also manage invite lists and check RSVP status for events using the . All of these new features work from the /EVENT_ID connection, following standard Graph API conventions. The following are the newly introduced APIs for managing events; see the Graph API Event object for full details.

Managing Invite Lists

You can issue the following HTTP requests to view or modify the invite list for an event:

GET /EVENT_ID/invited/USER_ID Check if USER_ID is invited to the event. This returns an object with name, id, and rsvp_status ('not_replied', 'unsure', 'attending', or 'declined') fields. Requires user_events or friends_events permission for non-public events.


Invite a user to an event. Returns true if the request is successful.


Invite multiple users to an event. Returns true if the request is successful.

DELETE /EVENT_ID/invited/uid

Un-Invite a user from an event. Returns true if the request is successful. The user must be an admin of the event for this call to succeed. Requires rsvp_event permission.

Querying RSVP Status

You can issue the following HTTP requests to query the RSVP status of an event:


Check if USER_ID is attending the event (i.e. they RSVP'd yes)


Check if USER_ID RSVP'd 'maybe' for the event


Check if USER_ID RSVP'd declined the event (i.e. they RSVP's no)


Check if USER_ID has not yet replied to the event invite

The above methods return an object with name, id, and rsvp_status ('not_replied', 'unsure', 'attending', or 'declined'). If the user is not invited to the event, the API will return an empty data array.

The following example uses the to demonstrate the new methods with several common variations.

'YOUR_APP_ID', 'secret' => 'YOUR_APP_SECRET', ); // Initialize a Facebook instance from the PHP SDK $facebook = new Facebook($config); $user_id = $facebook->getUser(); // Declare the variables we'll use to demonstrate // the new event-management APIs // We'll create an event in this example. // We'll need create_event permission for this. $event_id = 0; $event_name = "New Event API Test Event"; $event_start = time(); // We'll just start the event now. $event_privacy = "SECRET"; // We'll make it secret so we don't annoy folks. // We'll use three users to demostrate the new APIs $user_id1 = "USER_ID1"; $user_id2 = "USER_ID2"; $user_id3 = "USER_ID3"; // Convenience method to print simple pre-formatted text. function printMsg($msg) { echo "
"; } ?> api('/me', 'GET'); $user_1 = $facebook->api($user_id1, 'GET'); $user_2 = $facebook->api($user_id2, 'GET'); $user_3 = $facebook->api($user_id3, 'GET'); printMsg('User 1: ' . $user_1['name']); printMsg('User 2: ' . $user_2['name']); printMsg('User 3: ' . $user_3['name']); // Create an event $ret_obj = $facebook->api('/me/events', 'POST', array( 'name' => $event_name, 'start_time' => $event_start, 'privacy_type' => $event_privacy )); if(isset($ret_obj['id'])) { // Success $event_id = $ret_obj['id']; printMsg('Event ID: ' . $event_id); } else { printMsg("Couldn't create event."); } // Invite user 1 to the event printMsg('Inviting ' . $user_1['name']); $ret_val = $facebook->api($event_id . "/invited/" . $user_id1, 'POST'); if($ret_val) { // Success printMsg($user_1['name'] . ' successfully invited.'); } else { printMsg("Couldn't invite " . $user_1['name']); } // Check if user 1 is invited to the event $ret_val = $facebook->api($event_id . '/invited/' . $user_id1, 'GET'); if($ret_val) { printMsg($user_1['name'] . ' is invited (checked).'); } else { printMsg($user_1['name'] . ' is not invited'); } // User 1 should be no reply, so we check now. // Check in the same way for /attending, /maybe, /declined $ret_val = $facebook->api($event_id . '/noreply/' . $user_id1, 'GET'); if($ret_val) { printMsg($user_1['name'] . ' has not replied.'); } else { printMsg('Error: ' . $user_1['name'] . ' has replied'); } // Check if user 2 is invited to the event (shouldn't be, yet) $ret_obj = $facebook->api($event_id . '/invited/' . $user_id2, 'GET'); // If the user is not invited, we'll get an empty data[] array if(count($ret_obj['data']) > 0) { printMsg('Error: ' . $user_2['name'] . ' invited.'); } else { printMsg($user_2['name'] . ' is not invited'); } // Invite users 2 & 3 printMsg('Inviting ' . $user_2['name'] . ' and ' . $user_3['name']); $ret_val = $facebook->api( $event_id . '/invited?user=' . $user_id1 . ',' . $user_id2, 'POST'); if($ret_val) { printMsg($user_2['name'] . ' and ' . $user_3['name'] . ' invited'); } else { printMsg("Couldn't invite " . $user_2['name'] . ' and ' . $user_3['name']); } // Now User 2 should be invited. $ret_obj = $facebook->api($event_id . '/invited/' . $user_id2, 'GET'); // If the user is not invited, we'll get an empty data[] array if(count($ret_obj['data']) > 0) { printMsg($user_2['name'] . ' invited (checked).'); } else { printMsg('Error: ' . $user_2['name'] . ' is not invited'); } // Un-invite user 2 printMsg('Un-inviting ' . $user_2['name']); $ret_val = $facebook->api($event_id . '/invited/' . $user_id2, 'DELETE'); if($ret_val) { printMsg($user_2['name'] . ' un-invited.'); } else { printMsg("Couldn't un-invite " . $user_2['name'] ); } // Creator of the event ("me") should be attending by default printMsg('Checking if creator of event (' . $me['name'] . ') is attending'); $ret_obj = $facebook->api($event_id . '/attending/' . $me['id'], 'GET'); // If attending, the data[] array will have our ID in it. if(isset($ret_obj['data'][0])) { printMsg($ret_obj['data'][0]['name'] . ' is attending'); } else { printMsg('Error: Creator of event is not attending ?!'); } // Delete the event printMsg('Deleting the event.'); $ret_val = $facebook->api($event_id, 'DELETE'); if($ret_val) { printMsg('Event deleted'); } else { printMsg("Error: Couldn't delete event"); } } catch(FacebookApiException $e) { // If the user is logged out, you can have a // user ID even though the access token is invalid. // In this case, we'll get an exception, so we'll // just ask the user to login again here. $login_url = $facebook->getLoginUrl( array( 'scope' => 'create_event, rsvp_event' )); echo 'Please login.'; error_log($e->getType()); error_log($e->getMessage()); } } else { // No user, so print a link for the user to login $login_url = $facebook->getLoginUrl( array( 'scope' => 'create_event,rsvp_event' )); echo 'Please login.'; } ?>
Categories: Facebook

Fri, 16/09/2011 - 3:00pm

Today we are launching a to replace Bugzilla which will help us get even faster and more efficient at fixing bugs. It is integrated into the Dev Site and uses your Facebook login so you no longer need to have a separate account to use it (as was the case with Bugzilla).

Get started by clicking on on the . When you land in the tool you will see the top 20 most active bugs (“Trending”). In most cases, this view should contain the bug you are looking for. If you do not find the bug you are looking for here, start a search and choose a tag, title, or phrase related to the issue you’re seeing.

A filtered list of all open bugs that include that tag or phrase will be shown. You can add multiple tags or phrases to continue narrowing your search results. If you are not quite sure what tags to use to further scope your search, click a tag from the list of tags on the left menu. This list contains all the tags found on the bugs in your search result along with the number of bugs in your search with that tag.

Once you have found the bug you are experiencing, you can subscribe to it to receive emails whenever new activity occurs on it (e.g. it’s been fixed), see other developers who are having the same problem, let us know that you’re seeing the same problem, or discuss workarounds in the comments.

If you can’t find the bug you are experiencing, click the “Create” button to file a new bug report. In the bug report, you must provide steps we can follow to reproduce the issue along with the IDs and access tokens you are using when you see the bug occur. Having this information up front helps us more quickly reproduce this issue and figure out what is happening in order to fix the bug as quickly as possible.

You will notice a few other features when you try it out and we expect that this will be a significant improvement over Bugzilla that will help you find and stay better informed about the bugs that affect you.

Today we are making Bugzilla read-only. We will continue to triage and fix the open bugs in Bugzilla, but all new bugs should be filed in the new tool. If you find any issues with the new bug tool itself, file a bug for us with the “bug tool” tag. We are actively working on adding more improvements to the bug tool and would love to hear your feedback in the comments below.

Special thanks to , our product management intern this summer, for all his help building the new bug tool.

Categories: Facebook

Our next event