The experience feedback setup

The use of the placeholder {accesstoken} is in reference to the JWT token you get back when you authenticate against the eTrusted servers. Visit Setup and Authentication to learn how to generate one if you don't already.

What are Touchpoints?

Touchpoints in eTrusted terms refer to any part of your site where you decide to start the experience feedback process.

These are usually parts your user interacts with, like when a user completes an action on your site eg: the checkout section of an e-commerce site, or renews a subscription. It can also be a physical interaction point such as a customer walking into your establishment.

Once you identify all touchpoints relevant to your experience feedback flow, it is now time to trigger the eTrusted system through events to continue the rest of the process.

Creating touchpoints

You can think of events as webhooks, we provide you a URL to which you can both trigger and send context to, the moment a user steps into or completes one of your identified touch points.

The way you represent your touchpoints within the eTrusted system is by creating them as event-types.

So for example, say you want to create a touch point for when someone submits a form. You can create a submitted touchpoint as an event-type within eTrusted, you will do so using the event-type endpoint.

Note that the name for the touch point "submitted" is an arbitrary one, you can use any name of your choosing.

Here is an example of what this will look like in CURL:

curl --location --request POST 'https://api.etrusted.com/event-types' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer {access_token}' \
--data-raw '{
    "active": true,
    "name": "submitted"
}'

Once successfully created you should get back a JSON response similar to this:

{
    "id": "ety-dff2efe0-3903-47e0-bc35-501fd10a5509",
    "createdAt": "2021-07-22T13:05:28.709Z",
    "updatedAt": "2021-07-22T13:05:28.709Z",
    "active": true,
    "name": "submitted"
}

You can always get the list of created touchpoints using the get event type API

Invite setting

Whenever eTrusted receives events, a process chain is triggered that ultimately will send out a review invite to your customer automatically.

Invite settings control the conditions for sending out these invites via eTrusted.

A setting defines when an invite is sent out as well as the transport medium to use e.g. email.

Once you have an event-type in place, an invite setting is created automatically.

You can view the invite settings set for a particular channel using the Get all invite settings endpoint

Also, to update the default settings you can use the Update specific invite settings endpoint.
This requires you to know the invite settings ID. You can get that from the Get all invite settings endpoint previously mentioned above.

NB: Please do note that Invite Settings replaced Invite rules as of December 2022.

Triggering and sending out invites

Once you have set up your touchpoints as event types and have put in place invite settings, you can now go ahead and integrate the event-triggering element within your site.

Once a customer completes an action on your site, you can call on the Events API to begin the experience feedback process.

Below is an example showing the triggering of the events endpoint in CURL:

curl --location --request POST 'https://api.etrusted.com/events' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer {access_token}' \
--data-raw '{
    "channel": {
        "id": "chl-xxxxxxxx-yyyy-xxxx-yyyy-xxxxxxxxxxxx",
        "type": "etrusted"
    },
    "customer": {
        "email": "[email protected]",
        "firstName": "John",
        "lastName": "Doe",
        "address": "Anystr. 17, 12345, Anycity, Anystate 12345",
        "mobile": "cillum eu",
        "reference": "cst-xxxxxxxx-yyyy-xxxx-yyyy-xxxxxxxxxxxx"
    },
    "system": "customer_system_name",
    "systemVersion": "1.0",
    "transaction": {
        "reference": "submission-12345",
        "date": "2013-08-25T03:12:26.613Z"
    },
    "type": "submitted",
    "defaultLocale": "de_DE",
    "estimatedDeliveryDate": "2017-01-07",
    "products": [
        {
            "name": "Specialbrand T-Shirt White M",
            "sku": "1234-TS-WH-M",
            "url": "https://www.specialbrandshop.com/article123-TS-WH-M/",
            "gtin": "1234567890123",
            "imageUrl": "https://www.specialbrandshop.com/article123-TS-WH-M/image.jpg",
            "mpn": "23687778",
            "brand": "specialbrand"
        }
    ],
    "metadata": {
        "metaKey1": "metaValue1",
        "metaKey2": "metaValue2"
    }
}'

With an event successfully triggered you should get back a JSON response similar to what is shown below:

{
    "Message": "Your event (evt-xxxxxxxx-yyyy-xxxx-yyyy-xxxxxxxxxxxx) was accepted for processing",
    "EventRef": "evt-xxxxxxxx-yyyy-xxxx-yyyy-xxxxxxxxxxxx"
}

As you may have noticed the POST body has a large JSON object, most of which is meant to send as much context data back to the eTrusted platform.
This data is also available to you for later use, all you need to do is call on the get events endpoint

Some of the keys within the JSON object are however mandatory, including the following:

• customer object: This provides information about the customer to be used within the templates as well as how to reach them.
• type: This is the name of the event-type you will like to fire the event for.
• channel: Everything done under your account must be associated with a Channel which is a way to segment parts of your business.
• transaction: This is metadata about the action your customer performed and when they performed it. You can certainly rely on the event-type to know which action the customer performed, however, the transaction reference: This is meant to be set by you to capture any extra context you may need.
• system and system_version: This also provides you with a way to identify which of your systems triggered the event.

What next?

Hopefully, you now have a fair idea as to what is possible with the events endpoint. There are other endpoints we did not look at that might be useful to your specific use case, so please feel free to check out the API documentation for the full list of what the event API has to offer.

In the next section, we will take a look at questionnaires and templates.