Product & development guidance
- Feedback should ideally be built into your product so it can be kicked off automatically, not manually. The goal being to remove potential bias in results and to give a sense of trust to the user (for more honest feedback) that the agent who handled the interaction is not reading the results.
- Feedback results should be delivered to the business via your product. We've built our APIs with an assumption that you could create a dashboard or file download to provide reports to managers. Twitter is not planning to provide an interface for businesses to retrieve results directly from Twitter.
- Feedback results should ideally not be surfaced directly to an agent, and instead be surfaced in supervisor reports or in an asynchronous way such that an agent doesn’t see the feedback and change their interaction demeanor or behavior.
- Initially Feedback can only be requested along with a Direct Message. Make sure to check the user object can_dm to see if you have the ability to send Feedback before hitting the POST endpoint. (Particularly relevant if sending a Feedback prompt after a public interaction.)
- A Direct Message must be sent before prompting a user for Feedback. When brands are considering the Direct Message text preceding the Feedback prompt, make sure it makes sense in the case that the Feedback experience does not rendes (old clients, 3rd party clients, etc).
- Scores and text can be submitted independently and will likely have different timestamps. A score may be submitted without a text comment ever being completed. Both scores and text are immutable once submitted.
- Code should be tolerant of n number of updates per Feedback object. It should not assume a max of three possible updates. You should always rely on the most recent “updated_at” timestamp.
- An empty next_cursor value indicates you have reached the end of the result set. You should make no assumption about empty / partial page returned in "events" array as a signal that there is no more data to be fetched.
Access & authentication
Customer Feedback Cards are only available to Enterprise data customers who request access through their Account Manager. Access is provided after review of use cases consistent with an experience where a person would realistically expect to receive a request for feedback.
- Your client app ID and a @username must each be whitelisted to get applevel access to the API.
- Authentication is 3-legged OAuth currently used with the Twitter public API.
- We must additionally whitelist the @username for any accounts you wish to send Feedback requests FROM (either your customer’s handles or your own if used for testing purposes).