Becoming a Transcend Integration

This section is for new and existing Transcend integration partners, not Transcend customers. We'll explain here a few best practices for exposing an API that Transcend can easily plug into to automate data subject requests for customers and end-users.

Please note that at this time Transcend does not have an API for partners to build on. Instead, integration partners must expose an API that Transcend can connect with to integrate with the platform. For APIs which follow the guidelines outlined here, the Transcend integrations engineering team should be able to build an integration in a matter of days.

Personal Data is any information relating to an identifiable natural person (or data subject). An identifiable natural person can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier, or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person.

That's a pretty broad definition. We think examples may help (not an exhaustive list):

  • Contact info, like card information from a CRM including name, email, phone, etc.
  • Telephony data, like call recordings, text messages, etc.
  • Support tickets and requests.
  • Survey responses
  • Applicant data, like resumes, cover letters, etc.
  • Custom audience lists
  • Financial information, like credit card number, credit score, transaction history, etc.
  • References to customers in internal tools (e.g. spreadsheet data, slack messages mentioning a user)

Transcend can trigger a number of different DSRs in your system, and automatically fulfill these requests via API. We'll describe them in detail here, as well as how you can build the respective routes into your API.

Transcend prefers a global access endpoint such that, when called, your API will return all data associated with a given user's key identifier (most commonly email). This endpoint will be used to automatically fulfill data subject access requests (DSARs).

There are many ways to implement this global access request. Some example partners that did a good job with this include:

  • Optimizely allows users to make an access request via their API. Their API returns information about where the data export location will be. Note that it allows granularity in both the type of request (e.g. GDPR vs. CCPA) and the type of user (website visitor or Optimizely user).

If the personal data that your company processes is well-structured, like in the case of Twilio, it is fine that your API just exposes simple ways of interacting with the various tables and structured data relating to users. In Twilio's case, they expose routes to check on call logs that reference particular phone numbers, and from the API response given by this call log access Transcend can dig up recordings and related data about customer interactions.

Transcend prefers a global deletion endpoint such that, when called, your API will purge all data associated with a given user's key identifier (except for data your company claims exemptions on). This erasure route can be configured as asynchronous.

There are many ways to implement erasure request endpoints as well. Segment has a protocol that we find very friendly. They have an endpoint for initiating an erasure request and then have a separate endpoint for checking up on the status of that request. They allow for data to be erased or erased and suppressed (preventing further tracking).

There are a few different types of opt-out requests covered under existing data privacy regulations. They are as follows:

  1. Do not contact - opts users out of email, text, and mail communications.
  2. Do not track - opts users out of further web analytics tracking.
  3. Do not sell my personal information - opts users out of the anonymized and non-anonymized sale of their data.
  4. Do not process - relates directly to Article 9 of the GDPR and only applies to businesses processing certain types of data.

There are many ways of implementing opt-out requests. Delighted is a good example to look to for the simple but common case of opting a user out of contact lists.

Transcend prefers to look up Personal Data by email. If that's not possible, we may be able to use mobile identifiers (IDFA, GPADVID), and even phone numbers (e.g. messages are searched by phone number in Twilio's API).

Action routes (access, erasure, opt-out) should be keyed by identifiers that the mutual customer will reliably possess. For example, Optimizely allows data subject requests by the Optimizely-assigned optimizely_end_user_id (which clients might be able to figure out for their users) or by email (every data subject request with Transcend is associated with a verified email).

Transcend can integrate easily with APIs authenticated with API Keys or through OAuth applications. Transcend prefers APIs that support OAuth authorization code flows for security reasons, and it's simpler for our customers to set up.

As a general principle, Transcend should have only the permissions that it needs to submit requests.

Here are some links to API docs for partners that had excellent APIs

  • SnapChat Ads. Snapchat has a very traditional OAuth2 authorization_code flow. One security downside of their solution is that when users give access to Transcend to manage their Snap Ads account, they technically authorize Transcend to perform any marketing related actions with the Snap API. Hypothetically, a malicious Transcend could use this access to start new ad campaigns or disable current ones (a permission Transcend does not need). When Transcend's permissions are bloated like this, it increases client hesitation when connecting to Transcend.
  • Google Analytics This API flow allows for very granular permissions. For example, Transcend's app is able to request the ability to delete users from custom audiences without having the ability to otherwise manage add campaigns through the user deletion permission.

For partners with OAuth APIs only.

We require two distinct OAuth applications: one for development and testing, and another for our mutual customers to connect to in production. As such, there are four unique callback URLs:

App name: Local Dev OAuth redirect URL: https://yo.com:4001/integration/[partnerName]/cb Developer email: dev@transcend.io

App name: Remote Dev OAuth redirect URL: https://api.dev.trancsend.com/integration/[partnerName]/cb Developer email: dev@transcend.io

App name: Staging OAuth redirect URL: https://api.staging.transcen.dental/integration/[partnerName]/cb Developer email: production@transcend.io

App name: Transcend DSR Automation OAuth redirect URL: https://api.transcend.io/integration/[partnerName]/cb Developer email: production@transcend.io