Platform Roadmap

We publish this roadmap in advance to help developers plan for changes that may require code modifications. Developers are encouraged to subscribe to our blog, where we announce changes and timelines.

Roadmap
Completed Changes
Change Policy
Migrations

Completed Changes

These previously-announced changes have been completed. For a list of upcoming changes, check out the Roadmap.

April 9th, 2014 for Ads API

Targeting

The overall concept of targeting has been redefined as having four key areas (locations, demographics, interests, behaviors). This organization creates more flexibility and precision in audience creation in terms of the and/or logic between groups.

Example: historically, if you selected "Parents" "Photography" "Photo uploader" within interests, the audience constructed was People who are Parents OR interested in Photography OR people who upload [many] Photos. However, the intended audience was: "Parents, who are interested in photography and upload pictures". Now, the specific audience will be targeted as intended.

Unified Interests

Interest targeting has been redefined to create a unified definition for what indicates interest in a particular topic. Legacy targeting concepts such as Precise Interests (Keywords, #Topics) and Broad Categories have been unified and as a result have only one targeting segement for each term (no duplicate "Baseball" and "#Baseball"). The result is one, clear definition for each targeting segment.

If you are a member of the PMD News group, please refer to this existing post for more details

Geographic targeting

  • The new Geo-Targeting API adds targeting flexibility and incorporates inclusion/exclusion logic.
  • Select any combination of Country, Region, City or Zip without restrictions.
  • Exclude locations from your targeting parameters.
  • All previous capabilities, such as radius targeting on cities, continue to exist.
  • Geo-targeting logic is now "OR" and not "AND". For example, to target California, the previous logic would have required you to specify "US" as the country and "California" as the state. With the current logic, if you specify "US" as the country and "California" as the state, the targeting will result in the entire "US". To target "California", you now only need to specify "California".
  • With the new API, the keys have changed for regions and zip code targeting.
  • IMPORTANT NOTE: The Targeting Spec for any ad created with the new geo-targeting logic (e.g. via Create Flow or Power Editor) will not be editable via the current targeting API. All other parameters will remain editable.

If you are a member of the PMD News group, please refer to this existing posts: original and update

Advanced Demographic and Behaviors

Advanced Demographic targeting options will now be available. Key features include better coverage of workplace, education and job title types as well as expanded Relationship status types. There is also the added functionality of selecting the recency of change of a life event (3 months, 6 months, 1 year).

A new targeting type, Behaviors, has been added. These categories are specific to a user's particular actions or past purchase behavior, past purchase behavior, purchase propensity. This category is made up of some targeting segments previously categorized as Interests.

See Advanced Demographics and Behaviors for documentation.


Creative Data Model

In an effort to better align our Ads API with our Ads Simplification effort, we're making changes to simplify the creative data model to be more intuitive. The focus of creatives will be on the promoted object and the creative assets instead of the creative type, making them more consistent across promoted object types.

As part of a simplification of the ad creative object, we will be removing the field type and standardizing on field names. We will infer what type of ad you wish to create based on the other fields within the creative spec.

Some notable changes:

  • type will be sunset
  • The auto_update field will be sunset. Existing ads will continue to delivery, but will no longer update after 4/9.
  • See the ad creative documentation for exact mapping field name changes.
  • For type 12 premium ads, we will infer using the locations field. Premium standard ads will not look different than standard ads anymore (previously they were 110x80px vs. 100x72px for standard ads).
  • App ads will no longer require an object_id field, so you must explicitly specify a tracking and conversion spec.
  • Facebook will sunset the creation of sponsored stories
    • Page post and page like ads already automatically have the best social context (likes and comments) added. You may choose to add share social context by specifying social_prefs=['allow_shares'] on the adgroup. Existing page post and page like sponsored stories will continue to deliver so you must support fetching them.
    • Domain and open graph sponsored stories will no longer be allowed to be created. Existing domain and open graph sponsored stories will cease to have delivery after April 9th.
  • Facebook will sunset the creation of type 4 ads. Instead, create a canvas app install ad (type 32).
    • Please note that the image dimensions of a type 4 ad may differ from a type 32 – type 32 ads must be 1200x627. It’s recommended to resize the image if you need to reuse it.
    • image_hash is a required field of type 32 ads, whereas they were optional for type 4
    • Existing type 4 ads will continue running until they are naturally phased out, so you must still support fetching them.
    • You will not be allowed to update fields of an existing type 4 creative
    • Please see below for the mapping of type 4 fields to type 32 fields.
type 4 field type 32 field
object_id object_id
body body
name name
title title
link_url link_url
image_file or image_hash image_hash
url_tags

Objectives

Adgroups will have an optional objectives field. While this field is optional to specify, editing an ad that already contains this field will fail if the adgroup no longer passes the validation requirements.


Ad Image Cropping

Facebook has added the option to specify image crops through the Ads API. Image crops are used to describe the way that an image should be displayed in each aspect ratio of the different ad placements. During rendering, the image will be cropped according to the specifications given and if no specification is provided for a certain aspect ratio, the image will be displayed in the default way.

This is optional but if you choose to specify an image crop, you should provide information for all possible aspect ratios in our platform. For more information, please check the docs.

You should also support passing through image crops for ads created outside of your tool. After the migration, if you do not pass through the image crop value, any image crops will be removed.


Enum int->string changes

This migration changes the response of certain fields from an int value to a string value. This applies to the following fields:

As part of this change, we will also be removing the subtype_name field of custom audiences


Sunset disapprove_reason_descriptions

The field disapproval_reason_descriptions is being renamed adgroup_review_feedback. The format will be changed from an array of string to an object key-value-pair of reason enumeration and descriptive text. The previous response would be :

"disapprove_reason_descriptions": [
            "Descriptive text"
         ]

The new response will be :

"adgroup_review_feedback": {
            "REASON_ENUM": "Descriptive text"
         }

January 8, 2014

Broad age targeting deprecation Continuing our simplification effort, we are deprecating the broad age targeting as part of targeting specs. You will continue to create ads using age_min and age_max. Please refer to the documentation here.

Relative oCPM deprecation We are deprecating relative oCPM bid type (bid_type=RELATIVE_OCPM) and instead will use absolute oCPM. Note: PMD interfaces could still present the oCPM bid type as relative values, but the API calls should be all in absolute value. For example, a relative bid of 40% clicks, 30% conversions and 30% impressions should be translated to $4, $3, $3 for clicks, conversions, and impressions in the API call (PMDs should test different absolute bid values to understand performance). Please refer to the documentation here.

Feature phone targeting We are deprecating site_category as part of mobile targeting options, since this is now supported by device targeting type (the new option is user_device=feature_phone). Please refer to the documentation here.

Sponsored results, online offers and question poll ads Since we have removed these ad types, we will be returning errors in the API when attempting to create a sponsored result, online offer or a question poll ad. Please refer to the documentation here.

New image format and text size for app install ads on mobile App install ads on mobile will have image size of 1200x627 and body text of 90 characters — the old image size 600x360 and body text format of 130 characters will be deprecated.

October 2, 2013

The following changes can be enabled/disabled using the "October 2013 Breaking Changes" migration in the app dashboard until October 2nd when they will go into effect permanently for everyone:

Game Achievement API update
Game Achievement action custom properties will appear in the 'data' field, and consistent with other Open Graph Actions.

/USER_ID/likes default update
Currently the API returns all likes by default. After the migration, fetching a user's likes via the Graph API will return 25 results at a time. We've added pagination to the results so you can page through to all of a user's likes.

/POST_ID/likes update
Apps will be able to retrieve all likes on a post (rather than the first 4 as it is today) through paging. As a result of the functionality update, the like count will be moved to the summary field.

Removing 'network' based privacy
As we have deprecated 'network' based privacy settings on Facebook, we are removing the network privacy field from Graph API and FQL. Currently if an app attempts to create a post with a network privacy, it will default to 'only me'. After the migration period, posting with a network privacy will result in an error.

Removing the ability to post to friends' timelines via API
We have found that posting content via API (stream.publish) on a friend's wall lead to a high incidence of user dissatisfaction (hiding content, blocking the app). After the migration period, posting content to friends' timelines via stream.publish will no longer be allowed. Please use the Feed Dialog for posting.

FQL and Graph API limit=0 change
Currently, we have a bug where limit=0 returns all results. After the migration period, specifying a limit of 0 in FQL or the Graph API will return zero results.

Send Dialog will use Open Graph meta tags
After the migration, the Send Dialog will use Open Graph meta tags and ignore 'name', 'description', and 'picture' parameters.

Adgroups endpoint
Removing ad_id, adgroup_id, max_bid, start_time, and end_time field. Replacing bid_info and bid_type int values with enum values. You must now specify query params when retrieving information about adgroups. The only field returned by default will be id. See Ads API adgroup docs for more detail.

Adaccount endpoint
You must now specify query params when retrieving information about adgroups. The only field returned by default will be id. See docs for more detail.

Adcampaign endpoint
Removing campaign_id and include_budget_remaining flag. You must now specify query params when retrieving information about adgroups. The only field returned by default will be id. See docs for more detail.

Adcreative endpoint
Removing creative_id and run_status field. You must now specify query params when retrieving information about adgroups. The only field returned by default will be id. Creative types 8, 9, 10, 16, 17, 19 are removed. See docs for more detail.

Custom Audiences
After the migration period, apps cannot hash using CRC32, will only accept MD5 hash. See docs for more detail.

The following changes will go into effect on October 2, 2013:

Native iOS and Android apps must not use their own web views for Facebook Login
Native apps that implement Facebook Login by embedding their own web views inside their apps provide inconsistent and subpar user experiences. For example, users who are already signed in to Facebook on their devices must re-enter their Facebook credentials when logging in via custom web views. This results in a poor user experience as well as lower conversion for apps. In contrast, login flows provided by Facebook's official native SDKs allow people to skip entering their credentials. See our iOS and Android SDK documentation for more details.

To provide a better experience for all Facebook Login users, we are changing our policy to prohibit native iOS and Android apps from using custom web views for Facebook login.

Native iOS or Android apps initiating their own web views for Facebook login are required to use our official SDKs for login by October 2, 2013. Native iOS or Android apps using third-party SDKs that provide Facebook login via custom web views have an extension until January 8, 2014 to work with their third-party provider to resolve this or to migrate to our SDKs.

September 12, 2013

Local currency payments
We are migrating all canvas app developers that use the legacy Facebook Credits payments system to local currency payments. Facebook Credits will no longer be supported on September 12, 2013 and you must migrate to local currency payments to continue to accept payments from users.

July 10, 2013

The following changes can be enabled/disabled using the "July 2013 Breaking Changes" migration until July 10th when they will go into effect permanently for everyone:

New APIs for comment replies
As announced here, this migration enables the updated comment APIs.

Social plugins will require an absolute URL in the 'href' parameter
Social plugins, such as the Like Box and Like Button, will require an absolute URL in the 'href' parameter.

Stream table will throw exception with invalid filter_key
Query stream_filter table for a set of valid stream filters. The stream table will throw an exception if called with an invalid 'filter_key' option.

Removing 'publish_checkins' permissions
Publishing a Checkin object is deprecated in favor of creating an Open Graph story with a location attached. You can also create a Post with a location attached using the 'publish_steam' extended permission.

FQL Checkin table 'page_id' change
We are renaming 'page_id' to 'target_id' for the Checkin table.

Removing 'version' field for Groups
We introduced 'version' field to indicate whether the group was created prior to launch of the current groups product in October 2010. We are removing this field as all Groups on Facebook are now the same version. This impacts both Group Graph API and Group FQL Table.

Photos will no longer return larger sizes than the uploaded version
'images' field in photos and photo_src table will no longer return image sizes larger than the original uploaded version of the photo.

Deprecating 'comments' field from 'stream' FQL table
We are deprecating the 'comments' field from 'stream' FQL table. Please select the 'comment_info' column to fetch the 'can_comment' and 'comment_count' fields (formerly called 'can_post' and 'count'), and use the comment table directly to retrieve the list of comments.

Removing 'xid', 'reply_xid', 'username' and 'comments' from 'comment' FQL table
We are removing the fields on the FQL 'comment' table that were used exclusively for legacy Comments Plugins -- 'xid', 'reply_xid', 'username' and 'comments'. We now treat comments the same across plugins and within Facebook. Please query for comment replies left on the plugin the same way as you would for other comments.

Removing 'count' from 'comments' Graph API connection
We are removing the undocumented 'count' field on the 'comments' connection in the Graph API. Please request '{id}/comments?summary=true' explicitly if you would like the summary field which contains the count (now called 'total_count')

The following changes will go into effect on July 10, 2013:

Mobile App Install Ads change
We are updating the Creative Spec parameter 'app_platform_type' to 'mobile_store'. The possible values for mobile_store are now "itunes", "itunes_ipad", and "google_play".

Conversion spec and tracking pixel ID changes
We are deprecating the use of 'tracking_pixel_id' when specifying the desire to track a conversion pixel in an ad. You should instead specify the pixel in the newly launched tracking_specs field. We are also deprecating the use of conversion specs in bid types that are not optimized for actions (e.g. CPM, CPC, and oCPM when no bid value is placed on actions). You should instead use tracking_specs to track conversions for these bid types.

Custom Audiences change
We have changed the targeting spec parameter 'excluded_user_adclusters' to be 'excluded_custom_audiences'. Additionally, the endpoint to create and retrieve your custom audiences is now: https://graph.facebook.com/(act_adaccountid)/customaudiences.

Accessing link stats change
App access tokens will be required for accessing the link_stat FQL table. App access tokens will also be required for retrieving data from Graph API endpoint for link stats, ie: http://graph.facebook.com/?id=http://example.com.

Graph API search changes
User access tokens will be required for all search Graph API calls except Posts, Places and Pages. App access tokens may also be used for Post search Graph API calls. Places and Pages search Graph API calls will still require an App access token. Search for Applications will no longer be supported.

Open Graph apps using custom actions for fitness, books, movies, and TV
As announced in March, any apps that previously used custom actions to represent this type of sharing will need to move common actions by July 10, 2013.

Removing 'page_friends_of_fans' metric
We are removing the metric: 'page_friends_of_fans' from the Insights Dashboard and the Insights API.

April 3, 2013

The following changes can be enabled/disabled using the "April 2013 Breaking Changes" migration until April 3rd when they will go into effect permanently for everyone:

Removing ability to POST to USER_ID/questions
As it's no longer possible for users to create questions, we will remove this functionality from the Graph API. POSTs to USER_ID/questions will fail.

March 6, 2013

The following changes can be enabled/disabled using the "March 2013 Breaking Changes" migration until March 6th when they will go into effect permanently for everyone:

No more accessing mailbox FQL tables without a user session
It will not longer be possible to access the message, thread, or mailbox_folder FQL tables without a user session.

Removing apps from /me/accounts/ and page_admin FQL table
We will no longer show apps under /me/accounts/ in the Graph API or in the page_admin FQL table. You can access the list of apps a user is a developer on by hitting /me/applications/developer/ or using the app_role FQL table.

Removing redirect to docs when hitting graph.facebook.com
We will no longer return a redirect to the Graph API docs when hitting the URL http(s)://graph.facebook.com with no path.

February 6, 2013

The following change will go into effect on February 6th, 2013:

End of custom actions for content consumption
We will no longer show Custom Open Graph actions that were published simply by a user consuming content. If you own one of these actions and it was previously approved, you will have received an email from us. Developers should stop publishing these actions as doing so will return an error starting February 6th. The only actions that can be published upon a user simply consuming content are built-in actions. For more info, see this blog post.

The following changes can be enabled/disabled using the "February 2013 Breaking Changes" migration until February 6th when it will go into effect permanently for everyone:

Authenticated referrals going away
We will remove the Authenticated Referrals feature. You should instead use the Login Dialog.

Create_event permission required to remove attendees from event
We will require the create_event permission in order to remove attendees from an event a user admins.

Minor change to admin.getAppProperties call
When making an admin.getAppProperties call, we will now return an empty Android Key Hash field as [] instead of [""].

Canonical URLs used when fetching Open Graph objects
We will start using canonical URLs (e.g. the URL set in an og:url tag, 301/302 redirects, etc.) when fetching objects (e.g. http://graph.facebook.com?ids=http://developers.facebook.com).

Offset no longer allowed when searching posts
We will no longer allow the offset parameter to be used when searching stream posts (e.g. https://graph.facebook.com/search?q=watermelon&type=post). Please use since and until to do paging instead. For more info, check out this blog post.

Curly bracket syntax for mentioning users in notifications going away
We will no longer allow the curly bracket syntax ({USER_ID}) for mentioning users in notifications. Developers should instead use the new syntax (@[USER_ID]).

Removing ability to post to friends walls via Graph API
We will remove the ability to post to a user's friends' walls via the Graph API. Specifically, posts against [user_id]/feed where [user_id] is different from the session user, or stream.publish calls where the target_id user is different from the session user, will fail. If you want to allow people to post to their friends' timelines, invoke the feed dialog. Stories that include friends via user mentions tagging or action tagging will show up on the friend’s timeline (assuming the friend approves the tag). For more info, see this blog post.

The following change can be enabled/disabled using the "Picture as Dictionary" migration until February 6th when it will go into effect permanently for everyone:

Picture connection/field may return a dictionary
We will start returning a dictionary containing the fields url, height, width, and is_silhouette when accessing the /picture connection for an object and specifying a callback property, a redirect=false parameter, or getting the picture field as part of a larger JSON response.

January 9, 2013

The following change will go into effect on January 9th, 2013. Please note that January 9th is the second Wednesday of the month, not the first Wednesday of the month as is normally the case per our Breaking Change Policy. This is due to the fact that January 2nd is a company holiday so our standard Tuesday push will be delayed.

Removing unused splash_screen_url and gamebar_image_url properties
We will remove the splash_screen_url and gamebar_image_url app properties as these are no longer used anywhere so setting them will have no effect.

The following changes can all be enabled/disabled using the "January 2013 Breaking Changes" migration until January 9th when they will go into effect permanently for everyone:

Removing Dashboard REST API methods
We will remove all of the dashboard.* REST API methods. This was originally scheduled for June 2012 as announced in December 2011. To manage counts for your app, see the Requests documentation or this blog post.

Using canonical URLs when fetching data using link_stat table
When getting stats about a URL (e.g. number of likes) from the link_stat FQL table or by passing a URL to the ids parameter in a Graph API call, we will now use the canonicalized URL to fetch those stats. This fixes a few issues. For example, getting stats for developers.facebook.com and developers.facebook.com?foo=bar currently could return different values for shares. This change will ensure they return the same values since they in fact point to the same page.

December 5, 2012

The following change will go into effect on December 5th, 2012:

Removing the Static FBML Page tab app
We removed FBML in July of this year so any FBML code that was being used in the Static FBML Page app would have stopped working at that time. However, the Static FBML Page app is still able to render plain HTML. On December 5th, we will remove the Static FBML Page app and any Static FBML tabs you had installed on your Page will disappear. To replace any Static FBML tabs you may be using, we recommend you either host your own content and create your own Page tab or search the web for "Static HTML Facebook Page Tab" to find a replacement.

New policies for desktop web games off of Facebook.com
The following policies will go into effect:

13a. Desktop web games off of Facebook.com may only use Facebook Login (Authentication, excluding user connections such as friend list), Social Plugins and publishing (e.g., Feed Dialog, Stream Publish, or Open Graph). When authenticating, these games may not request additional permissions other than age, email, and our Publishing Permissions.

13b. Games on Facebook.com and mobile must not share the same app ID with desktop web games off of Facebook.com. You must not use Canvas apps to promote or link to game sites off of Facebook, and must not use emails obtained from us to promote or link to desktop web games off of Facebook.com.

For more information, check out the Platform Policies.

The following change can be enabled/disabled using the "Remove offline_access permission" migration until December 5th when it will go into effect permanently for everyone:

offline_access permission removal
The offline_access permission is deprecated and will be removed December 5th, 2012 (originally scheduled for July 5th). Please see the Removal of offline_access Permission doc for more details.

The following changes can all be enabled/disabled using the "December 2012 Breaking Changes" migration until December 5th when they will go into effect permanently for everyone:

New security restrictions for OAuth authorization codes
We will only allow authorization codes to be exchanged for access tokens once and will require that they be exchanged for an access token within 10 minutes of their creation. This is in line with the OAuth 2.0 Spec which from the start has stated that "authorization codes MUST be short lived and single use". For more information, check out our Authentication documentation.

Graph API will return full Custom Open Graph objects
We will begin returning full Custom Open Graph objects (including custom-defined fields) via the Graph API when requesting them using the id parameter (e.g. https://graph.facebook.com/?id=YOUR_URL). Currently we only return the id and shares fields for these objects.

Stripping HTML from Page description field
As some Page descriptions contain HTML, we will begin stripping HTML tags from the description column/field of the Page FQL table and the Page Graph API object so as to not require you to parse/render HTML when using a Page description. We will add a description_html column/field that will contain the description including the HTML tags (as description used to contain). The description_html Graph API field will not be returned by default. It will have to be explicitly requested by including a ?fields=description_html parameter in your Graph API GET request.

November 7, 2012

The following change will go into effect on November 7th, 2012:

No more payments reporting emails
We will stop sending payments reporting emails. You can download daily reports of transaction data using our Payments Reporting API.

The following changes can all be enabled/disabled using the "November 2012 Breaking Changes" migration until November 7th when they will go into effect permanently for everyone:

Notifications table no longer returns pid/aid for photos/albums
The object_id field on the notification FQL table will return photo ids and album ids (called object_id and album_object_id respectively in the photo FQL table) instead of pid and aid.

New permission required to read Page mailboxes
In order to read a Page's mailbox (PAGE_ID/conversations in the Graph API or unified_* FQL tables), you will need the read_page_mailboxes permission. The read_mailbox permission will now only give you access to a user's mailbox.

The following change can be enabled/disabled using the "External Page Migration" migration until November 7th when it will go into effect permanently for everyone:

External Page migration
You will no longer be able to publish content to the News Feeds of users who have liked your Open Graph object. This feature will only be available for Facebook Pages. Please see the Like Button Migration doc for more details.

October 3, 2012

The following changes will go into effect on October 3rd, 2012:

Built-in like/follow action required
We will stop allowing the use of Custom Open Graph "like" and "follow" actions now that there are built-in "like" and built-in "follow" actions. Please convert any custom "like" or "follow" actions you may have created to instead use the built-in "like" or "follow" actions.

Removing Bookmark URL - Originally scheduled for December 1, 2011
As mentioned on the blog, this optional field was originally created to help developers track user referrals from app bookmarks. We now pass a ref parameter to let you know that the user is coming from a bookmark (i.e. ref=bookmarks). As such, we will remove the "Bookmark URL" field from the apps settings.

The following changes can all be enabled/disabled using the "October 2012 Breaking Changes" migration until October 3rd when they will go into effect permanently for everyone:

Removing Live Stream plugin
The Live Stream plugin has been deprecated and will render the Comments Box plugin in its place. While it offers similar functionality, there are a few functional differences.

Summary field being replaced by description field
Because the two fields were somewhat redundant, we will be removing the "Summary" field (found in the "Login Dialog" section of an app's settings) and instead using the "Description" field (found in the "Advanced" section of an app's settings) in places where "Summary" was previously used.

Removing position field for photos
The position field in both the photo FQL table as well as the Photo Graph API object will start returning for all photos. The photos connection on an Album object in the Graph API will continue to return photos in the order they appear in the album. FQL queries on the photo table that have a WHERE clause containing the aid or album_object_id columns will return in the correct order as well without needing an ORDER BY position clause.

/picture connection will return a dictionary when a callback is specified
We will start returning a dictionary containing the fields url, height, width, and is_silhouette when accessing the /picture connection for an object and specifying a callback property. Currently we just return the picture URL as a string.

September 5, 2012

The following changes will go into effect on September 5th, 2012:

Deleting FB.Canvas.setAutoResize - Originally scheduled for January 1, 2011
We have renamed FB.Canvas.setAutoResize to FB.Canvas.setAutoGrow so that the method more accurately represents its function. FB.Canvas.setAutoResize will stop working on August 1st. We will completely delete the function on September 5th (if you call it you will get an "undefined function" error).

Built-in actions required for watching and reading
Custom actions for reading articles and watching videos must use built-in actions. Built-in watch and read actions can only be published after someone engages with the content for 10 or more seconds.

The following changes can all be enabled/disabled using the "September 2012 Breaking Changes" migration until September 5th when they will go into effect permanently for everyone:

Renaming 'likes' property of Comments and 'votes' property of QuestionOptions We will be renaming the likes property of the Comment object to like_count and the votes property of the QuestionOption to vote_count.

Minor change to admin.getAppProperties call
When making an admin.getAppProperties call, we will now return an empty iOS Bundle ID as [] instead of [""].

Returning actual size in photo_src table
We will start returning the actual size, height, and width of photos in the photo_src FQL table instead of the dimensions of the bounding box.

August 1, 2012

Disabling FB.Canvas.setAutoResize - Originally scheduled for January 1, 2011
We have renamed FB.Canvas.setAutoResize to FB.Canvas.setAutoGrow so that the method more accurately represents its function. FB.Canvas.setAutoResize will stop working on August 1st. We will completely delete the function on September 5th.

Page Post GETs from Graph API/FQL Will Require an Access Token
All calls to GET Page posts from the Graph API or FQL will now require an access token to be used.

Removing prompt_permissions.php and prompt_feed.php
We will be removing a very old version of the feed dialog (/connect/prompt_feed.php) as well as a very old version of the Login Dialog (/connect/prompt_permissions(s).php). If you are one of the very few developers still using these legacy endpoints, you should upgrade to the current Feed Dialog and/or Login Dialog.

Removing Add To Timeline Plugin We will be removing the Add to Timeline plugin. If you are embedding the Add to Timeline plugin, we will render the Login Button in its place with the publish_actions permission automatically added to the scope parameter.

July 5, 2012

Event GETs from Graph API/FQL Will Require an Access Token
All calls to get events from the Graph API or FQL will now require an access token to be used.

Removal of FBML
FBML apps will no longer work on Platform. All FBML endpoints will be removed and the "FBML Removal" migration added June 6th will be removed.

Updating Page Hours Property
The hours property of Pages will return times in the format HH:MM (e.g. "14:23") rather than the a Unix time.

Batch API Exception Format
Errors from the Batch API will return errors in a new format. Previously, errors would take the format:

{"error_code": "", "error_description": ""}

With this change, they will now be formatted in-line like the rest of the Graph API:

{"error": {"message": "", "type": ""}}

Removing Timezone From Event Times
We have had a migration titled "Timezone-less Events" out for a while now which removes timezones from event start and end times. This migration was originally created because in the past, events have been intended to be created with start and end times that are specific to the location of the event so including a timezone in the API simply led to confusion. Until now, this migration never had a date set for when it would go into full effect. That date is now July 5th. This change can be enabled/disabled using the "Timezone-less Events" migration.

Since this migration was originally created, we have added a timezone field to events which indicates the name of the timezone (as defined here) where the event is expected to happen. FYI, developers reading time in ISO 8601 should be supporting the full standard when reading event times. Most events return local times (no GMT offset), but in the future events likely will return other formats (namely date-only and precise).

Removing display=wap Dialogs
The wap dialog display mode will be removed.

Removing Some Event FQL Object Fields
We will be removing the following legacy fields from the event FQL object.

  • show_in_search
  • show_wall
  • show_photos
  • show_videos
  • show_posts
  • nid
  • tagline
  • event_type
  • event_subtype

Coordinate-less Tags
Tags previously could only exist on photos and always included x,y coordinates. On Facebook it is now possible to tag people in photos and statuses with no coordinates (example). These people show up as being "with" the actor. The potential breaking change is that it will be possible for the tags parameter of any photo object to return objects with no x or y parameters.

Removing Bookmark.Add and Profile.AddTab Dialogs
We will be removing the bookmark.add and profile.addtab dialogs from the Javascript SDK. These dialogs already don't do anything as the concepts of manually adding bookmarks and profile tabs have already been removed.

Moving Type Property Into Metadata Array
When querying the Graph API with a metadata=1 parameter, we append a metadata array and a type property to the response. We will be moving the type property into the metadata array.

June 6, 2012

Removal of FBML
FBML apps will no longer work on Platform. The "FBML Removal" migration will appear and will be enabled for all apps. It will be possible to disable the migration, thereby re-enabling FBML, until July 5, 2012 when the migration and all FBML endpoints will be removed completely.

XMPP Connections must be done over TLS
Apps connecting to Facebook's XMPP service will be required to use STARTTLS for all connections. We will start rejecting unencrypted connections.

May 2, 2012

Removal of group_type and group_subtype columns from group FQL table
We will remove the group_type and group_subtype columns of the group FQL table. Please ensure that your apps are not utilizing these columns.

Removing support to claim Domains using Page ID - Originally scheduled for April 1st, 2012
We will remove the ability to claim domains with a Page ID. The recommended option for claiming domains is with an App ID or User ID and existing domains that have been claimed will continue to work fine. After claiming domains, owners are able to view insights or run Domain Sponsored Stories. See the Insights documentation for more on the updated domain claiming flow.

April 4, 2012

Making deprecated SDK repositories private
We will make the Python and C# SDK repositories on GitHub private. These repositories are deprecated and may not work as expected due to changes in our auth system.

Removing canvas_name field from application object - Originally scheduled for February 1st, 2012
We will be removing the canvas_name field in favor of namespace field on the application object.

February 15, 2012

Pages Insights Metrics Deprecations
We are in the process of deprecating some old Page Insights. We announced this in a number of forums, but failed to outline this change in our Platform Roadmap per our breaking change policy. Our apologies. You can find a full list of the Insights to be deprecated from the Insights documentation. These Insights will be completely removed from API on Feb 15th 2012. Please make all necessary updates as soon as possible so that you can transition smoothly.

February 1, 2012

Removing App Profile Pages
We will be deleting all App Profile Pages and redirecting all traffic directly to the App. For more information, please refer to the blog post.

Removing REST Support for Ads API
We will be removing REST support for the Ads API. All Ads API developers now use the Graph API.

January 1, 2012

Removing the FB.Data.* JS SDK APIs
These will be no longer available.

Deprecating FBML
FBML will no longer be supported as of January 1, 2012. Aside from security and privacy related bugs, we will not fix any bugs related to FBML after January 1, 2012. On June 1, 2012 FBML endpoints will be removed from Platform.

All apps will be opted into "Upgrade to Requests 2.0" and "Requests 2.0 Efficient" Migrations
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. Details here.

Enforcing Credits Policy
We have added a new policy to the Facebook Credits Terms that prohibits routing Credits from one application to another application without our prior authorization.

2.14 You may not accept Credits in one application and deliver or transfer the purchase to the user in another application without our prior authorization. For example, an application solely designed to facilitate transactions is not permitted.

Applications that are not compliant by January 1, 2012 run the risk of having their Credits disabled shortly after.

December 1, 2011

OAuth Spec Migration
In order to be compliant with the OAuth spec we have made changes to our auth APIs. As part of this update, we will be deprecating code_and_token and need developers to use code%20token. Everything is identical, just replace _and_ with encoded <space> (%20).

Deprecating Dashboard APIs
These APIs (that start with "dashboard.") are no longer supported and will not be available past this date. This does not include the Dashboard count APIs which will deprecate on the FBML and Request 1.0 schedule (no support past Jan 1st 2012, and removed June 1st 2012.

Apps on Facebook: FB.Canvas.getPageInfo must be called with callback
The FB.Canvas.getPageInfo method will have to be called with a callback function. This was previously not required. See this blog post for more information.

November 1, 2011

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

October 1, 2011

OAuth 2.0 Migration
As we announced in May, all apps must migrate to OAuth 2.0 for authentication and expect an encrypted access token. The old SDKs, including the old JS SDK and old iOS SDK will no longer work.

Apps on Facebook Authentication and Security Migration (HTTPS)
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). You must provide an SSL certificate in the Dev App settings to avoid having your app disabled.

auth.promotesession Deprecation
This method is deprecated and will be removed.

manage_pages Permission Required to Access User Accounts (/me/accounts)
We are modifying access to the FQL page_admin table and the graph.facebook.com/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 user’s apps and Pages. We are going to require that apps have the manage_pages permission in order to obtain access to this information.

June 11, 2011

New Developer app
We are building a new version of the Developer app for managing your application's settings and will be adding features such as the ability to easily create and manage test users, manage large numbers of apps, manage users with special privileges (admin, developer, tester, insights), and more.

June 3, 2011

Requiring Access Token for Feed Connection
We will require an access token to GET from PROFILE_ID/feed.

April 18, 2011

Removing "year" and "status" properties of "affiliations" column in "user" FQL table
These properties will be removed from the "affiliations" column. You should use the "education" property of the User object in the Graph API or the "education_history" column of the user FQL table instead.


March 11, 2011

Canvas Apps and Page Tabs: No new FBML apps
We will stop allowing new FBML apps, but will continue to support existing FBML tabs and apps. Instead, we recommend using iframes.