Skip to contentSkip to navigationSkip to topbar
On this page
Looking for more inspiration?Visit the
(information)
You're in the right place! Segment documentation is now part of Twilio Docs. The content you are used to is still here—just in a new home with a refreshed look.

Voucherify Destination


Voucherify(link takes you to an external page) helps developers integrate digital promotions across any marketing channel or customer touchpoint - eventually giving full control over campaigns back to the marketing team.

This destination is maintained by Voucherify. For any issues with the destination, contact the Voucherify Support team.


Getting Started

getting-started page anchor
  1. From the Segment web app, click Catalog.
  2. Search for "Voucherify" in the Catalog, select it, and choose which of your sources to connect the destination to.
  3. Enter the "API Key" and "API Token" into your Segment Settings UI which you can find from your Voucherify dashboard(link takes you to an external page).

Getting API Key and API Token

getting-api-key-and-api-token page anchor

On the Voucherify Dashboard page:

  • Open the "Project settings" from the user context menu on the top right.
  • Find the "Application Keys" section on the project page.
  • Create a new key pair if needed.
  • Use "Application ID" and "Secret Key" respectively as "API Key" and "API Token".

If you're not familiar with the Segment Specs, take a look to understand what the Identify method does. An example call would look like:

1
analytics.identify('cust_9032_re_3234', {
2
email: 'john.doe@example.com'
3
});

Received events will be carried to Voucherify.io as a Customer Create request unless the setting Identify Disabled is true.

The Customer is created, with a source_id equal to the event userId or anonymousId. When exists, an existing Customer is updated.

With setting Identify Mapping you can customize the conversion from the event payload to Voucherify Customer payload.

1
# Default identify event mapping (src : dest)
2
{
3
"traits.name" : "customer.name",
4
"traits.firstName" : "customer.firstName",
5
"traits.lastName" : "customer.lastName",
6
"traits.email" : "customer.email",
7
"traits.description" : "customer.description",
8
"traits.address.city" : "customer.address.city",
9
"traits.address.state" : "customer.address.state",
10
"traits.address.street" : "customer.address.line_1",
11
"traits.address.country" : "customer.address.country",
12
"traits.address.postalCode": "customer.address.postal_code",
13
"traits.phone" : "customer.phone",
14
"traits.metadata" : "customer.metadata"
15
}

If you're not familiar with the Segment Specs, take a look to understand what the Track method does. An example call would look like:

1
analytics.track('Registration Completed', {
2
name: 'Customer Name'
3
});

Received events will be carried to Voucherify.io as Custom Events related to the Customer, with an event name equal to segment event value, unless the setting Track Disabled is true.

The Custom Event is attached to a Customer, with a source_id equal to the event userId or anonymousId. The userId field is a field which persists from when you first make an identify call on a JavaScript source. The anonymousId field is a randomly generated field that will be generated when you call a track event. The userId will take priority if anonymousId exists. If userId doesn't exist, the anonymousId will be used.

With setting Track Events Filter you can define the list of allowed events that will be transferred.

With setting Track Mapping you can customize the conversion from the event payload to Voucherify Custom Event payload.

1
# Default track event mapping (src : dest)
2
{
3
"properties.name" : "customer.name",
4
"properties.firstName" : "customer.firstName",
5
"properties.lastName" : "customer.lastName",
6
"properties.email" : "customer.email",
7
"properties.description" : "customer.description",
8
"properties.address.city" : "customer.address.city",
9
"properties.address.state" : "customer.address.state",
10
"properties.address.street" : "customer.address.line_1",
11
"properties.address.country" : "customer.address.country",
12
"properties.address.postalCode": "customer.address.postal_code",
13
"properties.phone" : "customer.phone",
14
"properties.metadata" : "customer.metadata"
15
}

The received event payload is translated, with the specific event mapping (track or identify), to a Custom Event payload.

Regardless of the provided mapping, some fields have a fallback mapping logic:

  • event when not defined, using the event property from the event, if not defined then the event type.
  • customer.source_id when not defined, using userId or anonymousId from the event.
  • customer.name when not defined, trying to build one from firstName and lastName.