Technical Information

Architecture and Security

The platform lives in the Google Cloud in the US-East region of South Carolina; except for BigQuery datasets that can be created in other regions according to customer specifications.

1. Network Specifications

  • Load balancer over HTTPS.
  • Firewall - VPC: The firewall only allows traffic to be received in the load balancer to reach the service cluster. The load balancer only receives traffic from WhatsApp and Facebook servers (REST API / HTTPS).
  • Cluster Master: The kubernetes administrator
  • Cluster internal network: The cluster's internal network lives in the private segment

2. Service Specifications

  • Cluster: The Kubernetes cluster is self-scalable, that is, the number of instances and pods varies depending on the workload / network traffic. Within the cluster lives the application composed of several microservices, including some transactional databases.
  • BigQuery: BigQuery stores messages and flow information from user conversations. This information is stored for analysis purposes, obtaining metrics (to report to the customer about their service consumption), and to improve the natural language intelligence engine. Datasets are stored in the Google Cloud region that the customer requires.
  • Stackdriver: This service centralizes and stores the Google Cloud infrastructure logs. Provides monitoring, troubleshooting, and continuous platform improvement services.

3.- Integration Specifications

AWS Lambda: When it is required to consult customer infrastructure information, an integration is created through Lambdas in AWS. The Yalo platform connects to AWS through the SDK, with service account token authentication. In turn, the Lambda connects to the client's infrastructure as the latter indicates (usually through REST API / HTTPS, or IPSec tunnel). The Lambdas reside in the US-East region of AWS, in North Virginia).

4.- Infrastructure Specifications

  • Kubernetes Cluster: The number of instances and pods in the cluster is variable, and depends on the amount of traffic received. Usually the cluster maintains approximately 15 instances. The cluster's internal network is self-administered by the Master of the Cluster, so users of Google Cloud or other services cannot access it.
  • Operating System: The servers in the cluster use the Container-Optimized System (COS, version cos-73-11647-348-0) as the Operating System. COS is automatically updated by Google. Also, version 1.14.8-gke.17 of the Google Kubernetes Engine is used.
click to enlargeclick to enlarge

click to enlarge

Authentication and Heading Method

The authentication to consume the Yalo Notifications API is through Bearer Token Authorization, Yalo provides a token to the users and this must be sent in each request.


The following set of HTTPS header fields provides the required information about the request or response, or about the object sent in the message body. Both request headers and response headers can be controlled using Yalo endpoints.






The expected value for the service is a JSON Body


Bearer {{token}}

Credential used by an application to access an API



The API or token key acts as a unique identifier and a secret key for the authentication of a set of access rights, this is delivered and renewed periodically by YALO

The following example shows a segment of a request using CURL POST to the YALO API:

curl -X POST \ d/notifications \ -H 'Authorization: Bearer token @token' \ -H 'Content-Type: application/json' \



@bot_id It is an identifier provided by Yalo to the client that indicates the Bot that responds to the calls and must be included in the EndPoint structure.

Service Parameters

The parameters that the API receives are in JSON format and the values that you expect are the following:


Expected value


Template Name or HSM authorized by WhatsApp


Message recipient's phone number

"params": {
"@example 1": "@value 1",
"@example n": "@value n"

Variables and values to be interpreted by templates are specified


curl -X POST \
x/notifications \
    -H 'Authorization: Bearer token' \
    -H 'Content-Type: application/json' \
    -d '{
    "type": "<type>",
    "users": [
            "phone": "<phone>",
            "params": {
            "example 1": "@value 1",
            "example n": "@value n"




201 Created
"success": true

This indicates that the shipment was successful

"success" : false,
"reason": "Requred
parameters are not
present in the request"

This response is received when a parameter is missing in the request

"success" : false,

The list of known error codes is:

  • ommited_notifications: One or more users have unsubscribed from notifications
    • invalid_number*: Message cannot be delivered to some phone numbers
    • duplicated*: Duplicated notification for some users
    • error_with_templates*: Error creating the message to send
    • error_with_botrunner*: error updating the conversation in the bot

API Response Levels


Service capacity

Currently, the service has the following response capacity:
Rate Limit: Supports 40 Notifications per second.

Did this page help you?