Onboarding as a WhatsApp ASP

As an ASP, you can provide WhatsApp functionality to your customers through the WhatsApp channel of the Conversation API. Your customers will create accounts using an embedded signup process in your system's user interface. The information gathered from that user interface will be used on the back end of your system to make API calls to Sinch's services. These services will create subprojects for your customers, create WhatsApp Sender IDs for your customers, and create Conversation API apps that your customers will use to send and receive messages on the WhatsApp channel.

This document provides a general guide to onboard to Sinch's services as a WhatsApp ASP. Throughout the guide, we provide instructions for, summaries of, and references to several complex processes. Some of these processes must be completed using Meta's tools, and we reference Meta's documentation in several places throughout this guide and the linked articles. Although these processes are complex, they only need to be completed once in order to onboard as an ASP.

Note:

If you are interested in a quick process that demonstrates the functionality of the Conversation API (which provides support for the WhatsApp channel), see our Conversation API Getting Started guides.

In order to onboard as a WhatsApp ASP at Sinch, you must:

  1. Set up your Sinch account
  2. Become a Tech Provider
  3. Create a front-end user interface
  4. Create a back end
Note:

Throughout this guide, we assume you are a new Sinch customer. If you are an existing customer that already has access to the Conversation API, you may begin with Becoming a Tech Provider.

Setting up your account

To set up your Sinch account as an ASP, you must:

  1. Create your account
  2. Locate your parent Project ID
  3. Gain access to the Conversation API

Creating your account

In order to onboard as an ASP, you must first have a Sinch account. To create your free Sinch account:

  1. Visit the Sinch Customer Dashboard signup page.
  2. Populate the form with your information (including an email address and phone number) and desired account credentials.
  3. Verify your email address (using a link sent to your inbox) and phone number (using the code sent to the phone number you provided in the previous step).
  4. Complete any remaining steps in the signup wizard.
After signing up for a Sinch account, ensure you reach out to your Sinch account manager to upgrade your account to a postpaid account. The name of your Sinch account manager can be found on the Sinch Customer Dashboard.

For more detailed information on this process, see the following Community article: How to sign up for your free Sinch account?

Locating your parent Project ID

As an ASP, the Project assigned to your account will serve as a "parent" project, and your customers will create subprojects that are contained within your parent project. In order to make the API calls required to create subprojects (a process that is described later in this guide), you will need your Project ID.

To view your Project ID:

  1. Visit the Sinch Customer Dashboard.
  2. Click the projects drop-down list. This is usually in the top left corner of the page.
  3. Click View all projects. The Projects overview page is displayed

    View all projects

    Note:
    If you are having trouble accessing the Projects overview page, try logging into the dashboard and visiting this direct link.
  4. Your project, and the corresponding Project ID, are displayed. You may use the copy button to copy the Project ID to the clipboard.

For more detailed information on this process, see the following Community article: What is a project and how to manage projects?

Gaining access to the Conversation API

To provide WhatsApp functionalities to your customers as an ASP, you must have access to the WhatsApp channel of the Conversation API. To begin gaining access to the Conversation API:

  1. Visit the Sinch Customer Dashboard.
  2. Select Conversation API from the left menu.
  3. Click GET ACCESS on the Conversation API Overview page.
  4. The Terms of Service are displayed. Click AGREE AND CONTINUE.
For more detailed information on this process, see the following Community article: How can I request access for Conversation API?

After you have completed this process, coordinate with your Sinch account manager to ensure your account has been appropriately set up for WhatsApp usage in Sinch's systems.

Becoming a Tech Provider

Sinch provides its WhatsApp services to ASPs by participating in a partner solution. Meta partner solutions allow the parties of the solution to share WhatsApp assets and services. These partnerships are between Tech Providers (or Tech Partners, which are upgraded Tech Providers) and Solution Partners.

You must become a Tech Provider and add Sinch as a Solution Partner. Then, you must complete the partner configuration steps in the Sinch Customer Dashboard. To do so, follow the steps described in this guide: How does Sinch provide WhatsApp assets and functionality to ASPs?

Creating a front-end user interface

The front end of your system must collect several pieces of information. This information will be included in API calls made to Meta and Sinch's services.

Warning:

Later in this process, you are instructed to create a back end that makes API calls to Sinch's services. These calls must not be made from the front end of your system. Additionally, any credentials used to authenticate with Sinch's services must be stored/used in the back end of your system; they must not be used/stored in the front-end UI.

Adding Meta's Embedded Signup flow

Note:

This section includes instructions and code snippets provided by a third-party. Third-party tools, software, and documentation are subject to change at any time. Refer to the linked documentation for the latest information from the third-party source.

You must embed the signup flow in your site. Follow the steps described in Meta's Embed the Signup Flow article until the After Business Completes Signup Flow section.

We provide a brief summary of the relevant steps below, but we encourage you to review the linked article in its entirety:

  1. Load the Facebook JavaScript SDK.
    Copy
    Copied
    <script>
      window.fbAsyncInit = function () {
        // JavaScript SDK configuration and setup
        FB.init({
          appId:    'facebook-app-id', // Meta App ID
          cookie:   true, // enable cookies
          xfbml:    true, // parse social plugins on this page
          version:  'v20.0' //Graph API version
        });
      };
    </script>
  2. Create Facebook Login for Business Configuration on the App Dashboard.
  3. Set up Facebook Login, which allows you to place a button on your website or portal to initiate connection to Facebook. Make sure the following are include:
    • The response callback function
    • The config_id parameter
    • The extras object with the setup parameter for any prefilled form data.
    Copy
    Copied
    <script>
      window.fbAsyncInit = function () {
        // JavaScript SDK configuration and setup
        FB.init({
          appId:    'your-facebook-app-id', // Facebook App ID
          cookie:   true, // enable cookies
          xfbml:    true, // parse social plugins on this page
          version:  'v20.0' //Graph API version
        });
      };
    
      // Load the JavaScript SDK asynchronously
      (function (d, s, id) {
        var js, fjs = d.getElementsByTagName(s)[0];
        if (d.getElementById(id)) return;
        js = d.createElement(s); js.id = id;
        js.src = "https://connect.facebook.net/en_US/sdk.js";
        fjs.parentNode.insertBefore(js, fjs);
      }(document, 'script', 'facebook-jssdk'));
    
      // Facebook Login with JavaScript SDK
      function launchWhatsAppSignup() {
        // Conversion tracking code
        fbq && fbq('trackCustom', 'WhatsAppOnboardingStart', {appId: 'your-facebook-app-id', feature: 'whatsapp_embedded_signup'});
        
        // Launch Facebook login
        FB.login(function (response) {
          if (response.authResponse) {
            const code = response.authResponse.code;
            // The returned code must be transmitted to your back end, 
      // which will perform a server-to-server call from there to our servers for an access token
          } else {
            console.log('User cancelled login or did not fully authorize.');
          }
        }, {
          config_id: '<CONFIG_ID>', // configuration ID goes here
          response_type: 'code',    // must be set to 'code' for System User access token
          override_default_response_type: true, // when true, any response types passed in the "response_type" will take precedence over the default types
          extras: {
            setup: {
              ... // Prefilled data can go here
            }
          }
        });
      }
    </script>
  4. Implement Pre Filled Data and Pre-Verified Phone Numbers Support (optional but recommended).
  5. Create a Login Button. This will launch the Embedded Signup flow by using the onClick function to call the launchWhatsAppSignup() function set up in step 3.
    Copy
    Copied
    <button onclick="launchWhatsAppSignup()" style="background-color: #1877f2; border: 0; border-radius: 4px; color: #fff; cursor: pointer; font-family: Helvetica, Arial, sans-serif; font-size: 16px; font-weight: bold; height: 40px; padding: 0 24px;">Login with Facebook</button>
  6. Optionally set up session logging.
  7. Optionally bypass phone number selection.
Note that, after a user completes the flow, your system must record the code property of the returned authResponse object in order to make the necessary API calls to Sinch's services. The response should look something like this:
Copy
Copied
{
  "authResponse": {
    "userID": null,
    "expiresIn": null,
    "code": "<CODE_TO_BE_EXCHANGED>"
  },
  "status": "connected"
}

Additional information to collect

In addition to the information described in the previous section, your front-end system must also retrieve the following information in order to successfully create WhatsApp senders through calls made to Sinch's Provisioning API.

Warning:

Later in this process, you are instructed to create a back end that makes API calls to Sinch's services. These calls must not be made from the front end of your system. Additionally, any credentials used to authenticate with Sinch's services must be stored/used in the back end of your system; they must not be used/stored in the front-end UI.

The following pieces of information must be collected by your front-end user interface:

Field nameDescription
regionAn enum representing the region of the WhatsApp sender to be created and used with the Conversation API. One of EU, US, or BR.
nameThe name of the sender to be created.
displayNameThe display name of the sender (within WhatsApp)
verticalCategory of the sender displayed in the Business Info section within WhatsApp
Note:

The API calls made to Sinch services will require other parameters as well. However, these other parameters are generated or retrieved at other points in this guide.

Additional considerations

In addition to the required front-end components described above, you may also include tools that allow your users to create and preview WhatsApp templates. You may construct these components on your own, or you may reach out to your Sinch account manager and inquire about Sinch's Message Composer and Message Previewer functionality.

Note:

If you don't wish to include WhatsApp template creation in your front end, you may use the Sinch Customer Dashboard to create WhatsApp templates on behalf of your customers.

Creating a back end

Important!

While our code samples include basic authentication, basic authentication is intended for test purposes only, and should only be used for experimenting with APIs and building prototypes. API calls using basic authentication are heavily rate limited, and these limits may change at any time without warning. Production systems should use OAuth access tokens instead.

Your front-end system will collect information from your customers. Your back-end system will use that information to make API calls to Sinch's services in order to:

  1. Create new subprojects that represent each of your customers
  2. Create new WhatsApp Senders for those customers/subprojects
  3. Create a new Conversation API app to use with the newly created WhatsApp Senders

These API calls are described in more detail below:

Creating a new subproject

Each of your customers must have a subproject contained within your parent project. This can be accomplished through an API call to the subproject API.

Note:
Replace the YOUR_parentProjectId_PARAMETER server variable with the parent Project ID you recorded earlier in this process.
application/json
{
  • "displayName": "YOUR_customer's_business_name",
  • "labels": {
    • "YOUR_key1": "YOUR_value1",
    • "YOUR_key2": "YOUR_value2",
    • "YOUR_key3": "YOUR_value3"
    }
}
The displayName field is required. This value is how the subproject will be labelled in Sinch's system; it does not have to be exposed to your customer. For more information on any optional fields for this API call, see the corresponding entry in the subprojects API reference guide.

Creating new WhatsApp Senders

The process for creating new WhatsApp senders involves several API calls.

Setting up the flow for one WABA

The Embedded Signup flow will create the necessary resources and return a authResponse object with a code property. The code must be registered with Sinch to be able to create the Sender and start messaging. To do so, include it in the facebookCode field of the Create sender for project API call detailed below.

Note that, in this case, the YOUR_projectId_PARAMETER in the server path is the Project ID of the subproject associated with the customer for whom the senders are being created. Also note that the region field, name field, and displayName and vertical fields of the details object are required fields. The other fields in the code sample are optional.

The WABA details will be fetched automatically when calling the create sender endpoint:

application/json

Example body request to create an ES.

{
  • "region": "EU",
  • "metaLocalStorage": "DE",
  • "wabaId": "11111111111111",
  • "phoneNumberId": "222222222222222",
  • "facebookCode": "FACEBOOK_CODE",
  • "name": "Example name",
  • "cloudApi": true,
  • "details": {}
}

Setting up the flow for multiple WABAs

The Embedded Signup flow will create the necessary resources and return a code. This code should be used to request long lived access token which is needed to list WABAs, create senders, and start messaging.

Getting a long-lived access token

A long-lived access token is required to select WABA details for the WhatsApp Sender. The Embedded Signup flow will create the necessary resources and return a authResponse object with a code property. Include the code in the facebookCode field of the Create a long lived access token API call detailed below. Note that, in this case, the YOUR_projectId_PARAMETER in the server path is the Project ID of the subproject associated with the customer for whom the senders are being created:
application/json

Example body request to create a long lived access token.

{
  • "facebookCode": "FACEBOOK_CODE"
}
The Provisioning API will respond with a longLivedAccessToken string, which is used throughout the rest of this process.

Specifying the WABA and phone number

As part of the Embedded Signup process, the user will select or create a new WABA, as well as the phone number to be used for the WhatsApp Sender. To be able to pass that to the Provisioning API, you will need the WABA ID and the phone number ID. These can be retrieved from the Provisioning API using the long lived access token retrieved from the previous step. Include the token in the facebookToken field of the List WhatsApp Business Accounts details API call detailed below. Note that, in this case, the YOUR_projectId_PARAMETER in the server path is the Project ID of the subproject associated with the customer for whom the senders are being created:
application/json

Example body request to list WhatsApp Business Accounts details.

{
  • "facebookToken": "FACEBOOK_TOKEN"
}

If this call returns more than one WABA or more than one phone number ID, you must ensure your front-end user interface presents the end-user with an option to select which WABA or phone number ID they want to use to create the sender.

Warning:

While information is collected through your front-end user interface, any API calls and any credentials used to authenticate with Sinch's services must be stored/used in the back end of your system; they must not be used/stored in the front-end UI.

Creating a sender with a long lived access token

Once the necessary information has been collected, you can create a sender using the Create sender for project API call. You must include the wabaId (retrieved from the previous step), phoneNumberId (retrieved from the previous step), and facebookAccessToken (retrieved from the long lived access token step). Additionally, you must specify values for the region field, name field, and displayName and vertical fields of the details object. Note that, in this case, the YOUR_projectId_PARAMETER in the server path is the Project ID of the subproject associated with the customer for whom the senders are being created:
application/json

Example body request to create an ES.

{
  • "region": "EU",
  • "metaLocalStorage": "DE",
  • "wabaId": "11111111111111",
  • "phoneNumberId": "222222222222222",
  • "facebookAccessToken": "FACEBOOK_TOKEN",
  • "name": "Example name",
  • "cloudApi": true,
  • "details": {}
}

Creating a new Conversation API app

You must then create a Conversation API app and specify the sender(s) you created in the previous step. Note that, in this case, the YOUR_projectId_PARAMETER in the server path is the Project ID of the subproject associated with the customer for whom the senders are being created. Also note that the display_name field and the channel_credentials object are required. The channel_credentials object will include a channel specifier (in this case, WHATSAPP) and a static_bearer object. Within the static_bearer object, you must set claimed_identity to the WhatsApp sender ID you created for your customer. Set token to the bearer token that corresponds to that ID.:
application/json
{
  • "channel_credentials": [
    • {
      }
    ],
  • "display_name": "Demo WhatsApp App"
}

Next steps

After you have successfully onboarded, you can review our Conversation API reference to familiarize yourself with how to send and receive messages, manage conversations, and more.

We'd love to hear from you!
Rate this content:
Still have a question?
 
Ask the community.