General Updates

Feed Elements

In API versions 30.0 and earlier, a Chatter feed was a container of feed items. In API version 31.0, the definition of a feed expanded to include new objects that didn’t entirely fit the feed item model. The Chatter feed became a container of feed elements. In API version 32.0, feed elements can be either feed items or generic feed elements. Generic feed elements don’t have an actor property, which means they can be used for system-generated content like the new recommendations in the feed.

This table shows the properties that are shared by Generic Feed Element and Feed Item, and the properties that are unique to Feed Item.
Property Generic Feed Element Feed Item
actor X
body X X
capabilities X X
canShare X
createdDate X X
feedElementType X X
header X X
id X X
isDeleteRestricted X
modifiedDate X X
originalFeedItem X
originalFeedItemActor X
parent X X
photoUrl X
relativeCreatedDate X X
type X
url X X
visibility X
Important

Important

API version 32.0 introduces new resources that get, search, update, and post feed elements. These resources operate on and return new request and response bodies that represent feed elements. Older resources, request bodies, and response bodies that operate on and represent only feed items aren’t supported in API version 32.0. The documentation for older resources, request bodies, and response bodies contains links to the documentation for the newer resources, request bodies, and response bodies.

Detailed information about these changes are in the following “Feed Elements” sections.

Capabilities

As part of the effort to diversify the feed, pieces of functionality found in feed elements have been broken out into capabilities. Capabilities provide a consistent way to interact with objects in the feed. Instead of inspecting feed item type and using other indirect means to determine which functionality is available for a specific feed element, the capabilities object tells you explicitly what is available. A client should check for the presence of a capability to determine what it can do to a feed element.

All feed elements have a capabilities property, which holds a Feed Element Capabilities response body. The Feed Element Capabilities response body can have one or more properties, each holding a capability of the feed element.
Feed Element Capabilities Property Type
approval Approval Capability
associatedActions Associated Actions Capability
banner Banner Capability
bundle
  • Generic Bundle Capability
  • Tracked Change Bundle Capability
canvas Canvas Capability
caseComment Case Comment Capability
chatterLikes Chatter Likes Capability
comments Comments Capability
content Content Capability
dashboardComponentSnapshot Dashboard Component Snapshot Capability
emailMessage Email Message Capability
enhancedLink Enhanced Link Capability
link Link Capability
moderation Moderation Capability
poll Poll Capability
questionAndAnswers Question and Answers Capability
recommendations Recommendations Capability
recordSnapshot Record Snapshot Capability
topics Topics Capability
trackedChanges Tracked Changes Capability

In version 32.0 and later, every feed element can have a unique set of capabilities. A capability includes both an indication that a feature is possible and data associated with that feature. If a capability exists on a feed element, that capability is available, even if there isn’t any data associated with the capability yet. For example, if the chatterLikes capability property exists on a feed element (with or without any likes included in the list of likes found in the chatterLikes.page.items property), the context user can like that feed element. If the capability property doesn’t exist on a feed element, it isn’t possible to like that feed element.

Important

Important

In API version 32.0, new resources have been introduced that operate on the capabilities of feed elements. These resources operate on and return new request and response bodies that represent capabilities. Older resources, request bodies, and response bodies are not supported in API version 32.0. In addition, all attachment functionality has been moved into capabilities and attachments are not supported in API version 32.0. Whereas a feed item could have only one attachment, feed items can now have multiple capabilities. The documentation for attachments contains links to the new capabilities.

Detailed information about these changes are in the following “Capabilities” sections.

Recommendations

Recommendations are new to the Chatter feed in API version 32.0.

The news feed in Salesforce1 mobile browser app can include recommendations about useful groups to join. The feed can also recommend the Today app but this option can be turned off from Setup | Customize | Chatter | Settings.

Recommendations are generic feed elements with a recommendations capability. They’re an example of what’s possible with the new feed element and capabilities architecture.

Recommendations Recommendations

Detailed information about these changes are in the following “Recommendations” sections.

Use CORS (Cross-Origin Resource Sharing) to Access Chatter REST API

Note

Note

To enable this feature, contact your Salesforce representative. In API version 32.0, only Chatter REST API supports CORS. REST API does not support CORS.

CORS is a W3C recommendation that enables Web browsers to request resources from origins other than their own (cross-origin requests). For example, using CORS, a JavaScript script at https://www.example.com could request a resource from https://www.salesforce.com.

Chatter REST API supports CORS (cross-origin resource sharing). To access this API from JavaScript in a Web browser, add the origin serving the script to the CORS whitelist.

To add an origin to the CORS whitelist, from Setup, choose Security Controls | CORS. Click New and enter an origin URL pattern.

The origin URL pattern must include HTTPS and a domain name, and may include a port. The wildcard character (*) is supported and must be in front of a second-level domain name. For example, https://*.example.com adds all the subdomains of example.com to the whitelist.

If a browser that supports CORS makes a request to an origin in the Salesforce CORS whitelist, Salesforce returns the origin in the Access-Control-Allow-Origin HTTP header, along with any additional CORS HTTP headers. If the origin is not in the whitelist, Salesforce returns HTTP status code 404.

You must still pass an OAuth token with requests that require it.