Understanding just enough HTTP to work with the WhatsApp Cloud API

A quick introduction to HTTP

Whenever you open a website in a browser, you're making an HTTP request.

For example, we type in the URL https://www.google.com to access Google's website.

Similarly, we type in the URL https://www.instagram.com to access Instagram's website.

In both cases, we made an HTTP request to access those websites.

And, HTTP is a request-response cycle.

You request something, and you get a response back.

For example, you requested https://www.google.com, and Google's web page came back as the response.

So what does HTTP actually stand for?

It's short for HyperText Transfer Protocol.

A protocol is just an agreed-upon set of rules that lets two computers talk to each other.

And HTTP is the specific set of rules your browser and a website's server follow to exchange information.

Secure means the data is encrypted as it travels between you and the server, so no one can read it along the way.

This matters for APIs because you'll be sending secret access tokens and private data, and you never want those traveling in plain text.

That's why every WhatsApp Cloud API address starts with https://.

And here's the important part for us: HTTP isn't only how browsers load websites. It's also how apps talk to APIs.

When you use the WhatsApp Cloud API, you're still sending an HTTP request and getting a response back.

The same cycle, just without a web page to look at.

Tools like n8n are doing this for you behind the scenes all the time.

And soon, you'll do it yourself.

Anyway, that's the whole idea.

Now let's see what an HTTP request is actually made of.

Parts of an HTTP Request

Every HTTP request has these five parts:

1. The endpoint (URL) — where the request is sent
2. The method — what action you want to perform (GET, POST, PUT, PATCH, DELETE)
3. Query parameters — optional data added to the end of the URL
4. Headers — extra information about the request. For example, authorization data.
5. Request body — the data you send along with the request

And once you send it, you get back a response, and it has two parts of its own:

• A status code — a number that tells you whether it worked or not. For example, if you receive a 200 as a status code, it means that our request was successfully processed and completed.
• A response body — the actual data or message that comes back

We don't need to understand all of the above parts to register and subscribe to your WABA phone number.

For now, let's quickly talk about...

1. The endpoint

The endpoint is the web address you send your request to.

For example, every WhatsApp Cloud API request goes to an address starting with:

https://graph.facebook.com/

You'll often see endpoints written with placeholders in curly braces:

https://graph.facebook.com/{{Version}}/{{WABA-ID}}/phone_numbers

The curly-brace parts are blanks you fill in with your own values.

So {{WABA-ID}} becomes your real WhatsApp Business Account ID.

The first part, https://graph.facebook.com/, is the base address.

Everything after it is a path that points to the exact thing you want.

And one service usually has many endpoints, one for each kind of resource. For example:

• .../phone_numbers — the numbers on your account
• .../messages — sending messages
• .../subscribed_apps — the apps subscribed to your webhooks

Same base address. Different paths. Different jobs.

Next...

2. The method

The method is the action you want to perform using the HTTP request.

There are five common HTTP methods:

• GET — fetch existing data. For example, "Hey! Get me a list of users"
• POST — send or create new data. For example, "Hey! Add this phone number to your registered database"
• PUT — replace an existing resource with new data.
• PATCH — update part of existing data
• DELETE — remove data entirely

For our two steps, both subscribe and register requests are POST requests.

We are not requesting data. Instead, we are sending our data to Meta for registration and subscription. So, we have to use POST as the HTTP method.

3. Query parameters

Query parameters let you customize the request without changing the endpoint itself.

These are optional extras added to the end of the URL.

They come after a question mark (?), written as key=value.

For example, to ask Meta for only certain details about your phone numbers:

https://graph.facebook.com/v23.0/{{WABA-ID}}/phone_numbers?fields=verified_name,quality_rating

And if you want more than one, you join them with an ampersand (&).

We won't need them for our two requests, but you'll run into them with other APIs.

4. Headers

Headers carry extra information about your request.

For example:

• Who you are
• What format is your data in

A single request can carry several headers at once.

For our needs, two of them matter most.

The most important header for our needs is: Authorization

Out of all the headers, you'll use the Authorization header in every single request.

For example, the WhatsApp Cloud API can send messages, register numbers, and read your account details, right?

And Meta obviously can't let just anyone do that.

So before it runs your request, it needs to know two things:

• Who are you?
• Are you allowed to do this?

The Authorization header answers both.

For example, when sending any request to WhatsApp Cloud API, you prove yourself by sending an access token as the Authorization header.

An access token is a long, secret string that Meta gives you:

EAAKqtk5Qb1oBQa1fggb6Uy7kkIjqWCcNaR8yhaKO...

You attach it to the request like this:

Authorization: Bearer YOUR_ACCESS_TOKEN

Also, you see the word Bearer in there?

It just means "whoever holds this token."

So by sending it, you're telling Meta: "Hey! Here's my token. That's my proof I'm allowed in."

If the token is valid and has the right permissions, Meta runs your request.

If it's missing, wrong, or expired, you get back a 401 Unauthorized, and nothing happens.

For our two steps, you'll use the system user access token you created earlier, which has the whatsapp_business_messaging permission.

There's one more header called Content-Type.

We will use this with every request, too.

The Content-Type header tells the server what format your data is in.

For example, WhatsApp expects JSON, so we send:

Content-Type: application/json

5. The request body

This body is the actual data you send with the request.

And it is usually written in JSON (JavaScript Object Notation) format.

JSON is a simple way of writing data as key-value pairs:

{
  "messaging_product": "whatsapp",
  "pin": "123456"
}

Read that as: messaging_product is whatsapp, and pin is 123456.

Each line is a key (the name on the left) and a value (the data on the right).

Also, you only need a body when you're sending data.

GET requests don't have a body because they only fetch data.

POST requests have a body because we are sending data. Not fetching it.

Finally...

The response and status codes

Once you send a request, you get a response, right?

So, always check its status code first.

It contains feedback about whether the request was successful or not.

Here are some of the most common status codes and their meaning:

• 200 — success, everything worked
• 400 — something's wrong with your request, check it for mistakes
• 401 — your token is missing or invalid
• 404 — the endpoint or resource wasn't found

A few others you'll bump into:

• 201 — success, and something new was created
• 403 — you're allowed in, but not allowed to do this particular thing
• 429 — you've sent too many requests, slow down
• 500 — something broke on the server's end, not yours

If you ever forget the exact meaning, the first digit tells you most of the story:

1. 2xx means success
2. 4xx means something on your side is wrong
3. 5xx means the problem is on the server's side

Long story short: If it's a 200, you're good. But if it starts with a 4 or 5, something needs fixing.

Along with that status code, you also get the response body — the actual answer.

For a successful registration, it's short and sweet:

{
  "success": true
}

That's the server confirming it did what you asked.

But if the request failed for any reason, it gets long and detailed:

{
    "error": {
        "message": "Unsupported post request. Object with ID '{{WABA-ID}}' does not exist, cannot be loaded due to missing permissions, or does not support this operation. Please read the Graph API documentation at https://developers.facebook.com/docs/graph-api",
        "type": "GraphMethodException",
        "code": 100,
        "error_subcode": 33,
        "fbtrace_id": "Awz3kN6YutfQKS5msP0Kd-Q"
    }
}

Alright! That's all you need to know about HTTP for now.

Just to recap, every HTTP request follows the same pattern:

• Where to send it (endpoint)
• What to do (method)
• Any extra options (query parameters)
• Who you are (headers)
• What data you're sending (body)

Alright. Enough theory!

It is time to send the requests:

1. Registering your phone number (POST request)
2. Subscribing to WABA webhooks (POST request)

Come on, go back to the lesson where you came from.

I will see you there :)