Privacy API

You can provide Outbound with an endpoint on your system that Outbound can use to retrieve a user's contact information only when a message needs to sent to the user. Outbound discards the information after sending the message. This ensures that your user information is stored only in your system.

You can provide different endpoints for the development and production environments in Outbound.

To implement this option, contact

Traditional implementation vs. Privacy API

The privacy API requires a different set up than a traditional Outbound implementation. Here are some of the major differences you will see:

Traditional implementation Privacy API
Identify requests Identify users and their attributes whenever they share contact info and personal details. This typically takes place during login or signup, or whenever the user updates their profile. Outbound rejects all identify requests to make sure it doesn't store any user data.

Instead, use track requests (see below).
Track requests Use track requests to send events to Outbound to send messages for your users. Use track calls to trigger events for your users.

For a user to 'exist' in your account, they must trigger at least one event. This means if you're running broadcast campaigns on users who have never triggered an event before, it's important to trigger a 'dummy' event for all of your users. An efficient way to do this is with Outbound 'batch track' api endpoint.
Triggering campaigns When a user triggers a campaign, Outbound waits for the specified delay time, and then runs campaign filters. When a user triggers a campaign, Outbound waits for the specified delay time, and then runs campaign filters.

In order to run campaign filters, Outbound will make an api call to your server to retrieve the user_id's attributes. Each user and each campaign that is triggered will cause an api call to your server.
Broadcast campaigns Broadcast and dry-run reports include all users identified within the relevant environment. Broadcast and dry-run reports include users for which your environment's endpoint (see below) returns a valid user representation.

Implementing your endpoint

Outbound will make GET requests to your endpoint. The response should contain a JSON object containing the user information. Example:

  "first_name": str,
  "last_name": str,
  "email": str,
  "phone_number": str,
  "tokens": {
    "gcm": [token],
    "apns": [token]
  "timezone": str,
  "attributes": {...}

Follow these guidelines when implementing your endpoint:

  • The endpoint should be HTTPS.
  • The endpoint should return JSON data and content-type and a 200 response. Outbound will consider anything other than 200 as a failed request.
  • If the user does not exist, your system should return a 404 response.
  • Outbound can do either basic authentication or send a secret key as a header field. This can be user defined. Your system should return a 401 response if the authentication method is not valid. Examples: a wrong secret key, or an invalid user or password.
  • If Outbound receives a response code of anything other than 200, 401 or 404, it will retry the request up to 3 times with no break in between. If unsuccessful, Outbound will not send the campaign message to the user because it doesn't have the contact information.
  • If the API returns invalid JSON or has missing fields, Outbound will not retry and will not send the campaign message because it doesn't have the contact info.
  • Outbound will still validate phone numbers and email addresses. If the validation fails, Outbound will not send the campaign message.
  • If you implement an endpoint and then attempt to make an identify request to Outbound, the request will be rejected with a 403 response.