Skip to main content
Back to messaging or digital channels Connect your agent to a WhatsApp Business sender so customers reach it from WhatsApp. Artemis reaches WhatsApp through a Business Solution Provider (BSP): Meta Cloud API, Infobip, or Gupshup. The provider you choose decides which credentials you collect, which webhook route you register, how Artemis verifies inbound traffic, and who owns the sender. The setup requires:
  1. Choose a provider before you collect any value.
  2. Complete the provider setup for your choice: Meta setup, Infobip setup, or Gupshup setup.
  3. Artemis channel configuration: create the connection with the provider’s values, then copy the generated webhook URL.
  4. Webhook configuration with your provider: register the callback URL so inbound messages reach Artemis.
  5. Verify the connection with a real two-way WhatsApp conversation.
After you complete the configuration, your provider posts inbound WhatsApp messages to Artemis. The runtime matches the business sender in each callback to a saved connection, verifies the callback, and hands the message to the agent deployed in the bound environment. The agent’s reply goes back out through the same provider. Important considerations
  • The provider selector changes the whole setup: It decides which fields the dialog shows, which webhook route the connection generates, and which in-product setup guide appears. Values from one provider never work on another provider’s route, so pick the provider first and keep every value on that single path.
  • Who owns the WhatsApp Business account differs by provider: On Meta Cloud API, you hold the account directly and Meta issues a test sender in minutes. On Infobip and Gupshup, the provider holds the account and onboards the sender for you, which removes the Meta paperwork at the cost of a provisioning wait.
  • Inbound verification strength differs by provider: Meta signs every callback with your App Secret. Gupshup can send a signed bearer token if you set a JWT secret. Infobip sends no signature at all, so you protect its route with network controls instead.
  • The Meta test token expires within 24 hours: It’s enough to test and not enough to run. See Create a permanent access token.
  • A verified webhook proves less than it appears to: A 2xx response proves only that your provider reached the runtime. It says nothing about whether your outbound credentials work, so always finish with a real two-way conversation.

​
Prerequisites

Collect these before you open the connection dialog, because Meta and the BSPs both gate production on review time you can’t shorten.
  • An account with your chosen provider: a Meta developer account, an Infobip account, or a Gupshup Enterprise WhatsApp account.
  • For production on any path, the business details Meta requires for verification. Every route waits on Meta review, so start early.
  • An HTTPS-reachable Artemis runtime, since providers call the callback URL from the public internet.
  • Artemis project access with permission to open Deployments -> Channels, and a deployed agent in the environment you intend to bind.

​
Choose a provider

Each card jumps to that provider’s setup. Read the comparison below the cards first if you haven’t picked one yet.

Meta Cloud API

You own the account. Fastest test sender, strongest inbound verification.

Infobip

Infobip owns the sender. Inbound traffic relies on network allowlisting.

Gupshup

Gupshup owns the sender. Optional JWT verification on inbound traffic.

​
What each provider needs

The routing identifier tells the runtime which connection an inbound callback belongs to. The credentials authenticate outbound messages and, where the provider supports it, inbound callbacks.

​
Webhook route and inbound verification

Each provider gets its own route on the runtime, and the connection generates the right one for you. The route decides which payload format and which verification model the runtime applies. Never append a phone number, connection ID, or provider slug to these routes yourself. The runtime reads the sender from the callback body.

​
How Artemis routes WhatsApp events

Every inbound message follows the same path, whichever provider carries it. Knowing the path tells you where to look when a message goes missing. The runtime finds the connection by reading one field from each provider’s callback body. That field must match the routing identifier you saved in Artemis. The path also splits troubleshooting in two. A session in Sessions means the inbound half worked and the outbound half failed. No session means nothing passed routing and verification.

​
Meta setup

Complete this section only if you selected Meta Cloud API. Everything here happens in Meta before you open Artemis, and each screen depends on the one before it. Meta covers the same ground in its Cloud API get started guide.
1

Register as a Meta developer

  1. Go to Meta for Developers and sign in with your Facebook account.
  2. Complete developer registration when Meta prompts you, confirming an email address and a phone number.
A personal Facebook account gets you started. You need a Meta Business portfolio only when you move past the test sender.
2

Create the app

  1. Open My Apps and select Create App.
  2. When Meta asks what the app does, choose the business messaging use case, or choose Other and then Business as the app type if Meta shows you that older flow.
  3. Enter an app name and a contact email, attach a Meta Business portfolio if you have one, and create the app.
Only a business app exposes the WhatsApp product. Keep development and production on separate apps or separate phone numbers, so test traffic never reaches customer conversations.
3

Add the WhatsApp product

  1. On the App Dashboard, scroll the Add products to your app list to WhatsApp and select Set up. If you’ve navigated away, the Add product entry in the left menu returns you to the same list.
Meta provisions a test WhatsApp Business Account, a test business phone number, and a set of pre-approved message templates. The test number reaches up to five verified recipients at no cost. The left menu now shows a WhatsApp section containing API Setup and Configuration, the two screens you’ll use.All of this is test infrastructure. It works for development and none of it works for production.
4

Find the Access Token and Phone Number ID

Go to WhatsApp -> API Setup in the left menu. This screen carries most of what Artemis needs.
  1. Select Generate access token and complete the prompt, then copy the token. Meta issues a fresh one each time you open this panel, and it expires within 24 hours.
  2. Below the From field, Meta shows the test business phone number, and directly beneath that, a numeric Phone Number ID. Copy the ID.
The Phone Number ID isn’t the phone number, and it isn’t the WhatsApp Business Account ID either. It’s Meta’s numeric resource ID for the sender. Entering either of the other two values is the most common reason a connection never receives traffic, and all three sit close together in Meta’s screens.
See Create a permanent access token before you move past testing.
5

Find the App Secret

The App Secret lives outside the WhatsApp section, so the left menu is the only way to reach it.
  1. Go to App settings -> Basic.
  2. Select Show beside App secret.
  3. Re-enter your Facebook password when Meta asks, then copy the value.
Meta signs every inbound callback with this secret, and Artemis checks that signature. A wrong value fails every inbound message even though the webhook itself verified successfully, which makes it a confusing failure to diagnose later.
6

Choose a Verify Token

Meta doesn’t issue this value. You invent a high-entropy secret string and use it in two places: the Artemis connection and the webhook configuration in Meta.The runtime finds the connection by its Verify Token during the handshake, so give each connection its own value. Store it where you can retrieve it, because Meta shows it back to you only while you edit the webhook.
7

Add a test recipient

While the app stays in development mode, Meta delivers only to numbers you register, so your own number receives nothing until you add it.
  1. Return to WhatsApp -> API Setup.
  2. Select the To field and choose Manage phone number list.
  3. Add your WhatsApp number, then enter the confirmation code Meta sends you in WhatsApp.
You can register up to five recipients. Select your number in the To field once it verifies.

​
Infobip setup

Complete this section only if you selected Infobip. Infobip owns the WhatsApp Business account and the sender. You collect the sender number, your account’s API base URL, and one set of outbound credentials from the Infobip web interface.
1

Open the right account and get a WhatsApp sender

  1. Sign in to the Infobip web interface with the account and workspace that own the sender you intend to connect.
  2. Go to Channels and Numbers -> Channels -> WhatsApp -> Senders.
  3. Complete sender onboarding if the sender isn’t live yet, then note the sender number.
A trial account comes with a shared test sender that reaches numbers you verify, which is enough to prove the integration works. A production sender goes through Infobip onboarding, where Infobip registers the number with Meta and runs business verification for you. Infobip’s WhatsApp over API guide covers what the channel supports once the sender is live. Start early, because onboarding waits on Meta review.
2

Find your API base URL

Infobip gives every account a personalized base URL in the form xxxxx.api.infobip.com, shown on the homepage once you sign in. Infobip explains the scheme under base URL.This URL isn’t a credential. It routes your requests to the data center serving your account, so a wrong one degrades or fails the integration rather than exposing it. Enter it in Artemis with the https:// scheme.
3

Choose one authentication method

Artemis supports three authentication methods for Infobip outbound calls: API Key, Basic Auth, and Custom Header (API Gateway). Pick the method that matches your Infobip setup. The connection dialog displays and submits only the fields for the selected method.
  1. API Key: Go to Developer Tools -> API Keys, create a key for this integration, and copy it into your secret manager when Infobip displays it.
  2. Basic Auth: Use the username and password associated with your Infobip account.
  3. Custom Header (API Gateway): Select this method when your Infobip connection uses an API gateway that requires a custom header. Enter the Header Name and Header Value required by your gateway.
Prefer a restricted API key where your account supports one. A dedicated credential per integration lets you revoke it without disturbing anything else.
4

Plan inbound network controls

Infobip doesn’t sign its callbacks, and the API key authenticates only your outbound calls. It never authenticates Infobip’s calls to you.
  1. Ask your Infobip contact which source addresses their platform sends webhooks from.
  2. Arrange an allowlist, a trusted gateway, or equivalent network controls in front of the Artemis route before you go live.
You can also configure an optional Inbound Webhook Secret when creating the connection. Enter a secret between 16 and 256 characters. Infobip sends this value in the X-Webhook-Secret header for typed continuity replies.

​
Gupshup setup

Complete this section only if you selected Gupshup. Gupshup owns the WhatsApp Business account and the sender, and you collect the business number and the account’s API credentials. The Artemis Gupshup fields take an Enterprise account’s user ID and password and route on the waNumber field that Enterprise callbacks carry.
1

Confirm your account type and open the right account

  1. Sign in to the Gupshup account that owns the intended WhatsApp sender.
  2. Confirm with Gupshup that it’s an Enterprise WhatsApp account that authenticates with a user ID and password.
Gupshup’s self-serve WhatsApp apps authenticate with an API key and post a different callback payload, so they don’t fit these fields. Keep production credentials on a separate account from sandbox or development accounts. Some Enterprise setups split template messaging and two-way messaging across separate account IDs, so confirm which account carries two-way conversations.
2

Confirm the WhatsApp business number

  1. Note the WhatsApp business number Gupshup provisioned for the account, as digits only with the country code.
This is the number Gupshup sends as body.waNumber in every inbound callback, and it becomes the routing identifier in Artemis. Don’t use the customer’s number, which Gupshup sends as body.mobile in the same callback.
3

Collect the API username and password

  1. Note the user ID and password for the account. Gupshup issues them when it creates the account.
  2. Store both in your secret manager.
These credentials authorize every outbound Gateway API call Artemis makes. Rotate them on your Gupshup account’s policy. Gupshup’s API reference shows how the Gateway API uses them.
4

Decide on webhook JWT verification

The Webhook JWT Secret is optional. Set it only when Gupshup or a trusted gateway in front of Artemis sends an Authorization: Bearer JWT signed with the same secret.
  1. Agree on the shared secret with whoever signs the token.
  2. Store it in your secret manager for the Artemis connection.
Leaving the field blank skips cryptographic verification, so protect the route with network controls instead. Setting it without a matching signer rejects every callback.

​
Artemis channel configuration

Create the connection before you register the webhook with your provider. Callbacks can arrive as soon as you save the webhook, and the runtime has to resolve an inbound sender to a saved, active connection before it can authenticate the event.
  1. Open Artemis and select the project.
  2. Go to Deployments -> Channels -> WhatsApp -> + New. The New WhatsApp Connection dialog opens, with the setup guide on the left and the connection fields on the right.
  3. Set Provider first. The guide, the field set, and the label of the routing identifier field all change to match. The routing identifier field sits above Provider, so recheck it after you switch providers.
  4. Configure the fields that apply to every provider:
  5. Configure the routing identifier and credential fields for your provider:
    Meta Cloud API asks for the Phone Number ID twice: once as the external identifier that routes inbound events, and once as the credential for outbound delivery. Paste the same value into both. Other providers use different values in each role, which is why the fields stay separate.
  6. Select Create.
  7. Open the connection and copy the Webhook URL from the summary panel on the right, or from the Configuration tab. The URL already carries your provider’s route, so copy it rather than building it by hand. If the dialog reports that the Runtime URL is unavailable, configure Runtime first, then reopen the connection to get the complete URL.

​
Webhook configuration with your provider

The webhook turns a one-way integration into a conversation. Until your provider has the callback URL, your agent can send but never receives.
In your Meta app, go to WhatsApp -> Configuration in the left menu. The Webhook row sits at the top of this screen.
  1. Confirm the Artemis connection exists and is Active. The runtime answers Meta’s handshake only for a saved connection.
  2. Select Edit. Meta opens a dialog with two fields.
  3. Paste the Artemis Webhook URL into the callback URL field, and the same Verify Token you saved in Artemis into the verify token field.
  4. Select Verify and save. Meta sends a GET challenge to the URL. The runtime finds the connection by its Verify Token and returns hub.challenge only when the token matches. A dialog that closes means the URL verified. A dialog that stays open with an error means the handshake failed.
  5. Below the webhook row, find the webhook fields list, select Manage, and subscribe to the messages field.
  6. Confirm the right WhatsApp Business Account and phone number attach to this app.
Verification alone delivers nothing. Meta verifies the URL whether or not you subscribe to anything, so a verified webhook with no subscription looks correct on screen and still sends your agent no traffic. Check the subscription first when the setup looks right and nothing arrives.Use the generic route exactly as the connection shows it. The runtime extracts metadata.phone_number_id from each signed POST body, so don’t append the phone number or a provider slug.

​
Validation checklist

Work down this list once per connection. Each row depends on the one above it.

​
Verify the connection

Artemis doesn’t synthesize provider callbacks, so a real WhatsApp message is the only way to confirm the integration works end to end.
  1. Use an approved test recipient. On a Meta app in development mode or a provider sandbox, register the number first. For production, confirm business verification, sender quality, payment, and template approvals are complete.
  2. From a normal WhatsApp account, send the business sender a short, distinctive message you can search for later.
  3. Check that the agent replies once, from the intended sender and the intended environment. Duplicate replies point to duplicate provider subscriptions, another automation on the same number, or repeated webhook delivery rather than an agent fault.
  4. If no reply arrives, open Sessions and search for the message you sent. A session tells you the webhook works and the outbound path failed. No session tells you nothing reached the runtime. The two need different fixes, so make this check before you change any configuration.
  5. If the agent sends buttons or lists, select a button and a list row and confirm the action returns to the same session. WhatsApp limits how many reply buttons a message carries and how long their labels run, so check that your content renders in WhatsApp rather than only in preview.
  6. Exercise every message type your provider enables, and confirm the agent handles the downloaded attachment rather than only acknowledging it.
The runtime normalizes these WhatsApp inputs across all three providers. Test only the ones your provider enables for your sender.
A webhook that returns 2xx proves only that your provider reached the runtime. It says nothing about whether your outbound credentials work. Always confirm a real two-way conversation before you call the channel done.

​
Security and provider boundaries

Each provider protects a different part of the exchange. These rules keep the inbound and outbound halves trustworthy. These rules apply to every provider:
  • Preserve the raw body: Where a provider signs the body, any proxy or middleware in front of Artemis must pass the exact raw bytes through. Re-serializing JSON breaks the signature and fails every callback.
  • Rotate in the right order: Rotate credentials without changing the inbound sender identifier. Update Artemis first, then revoke the old credential, then verify both inbound and outbound traffic.
  • Separate environments completely: Use separate apps or senders, credentials, webhooks, and connections for development and production.
  • Match verification strength to evidence: Keep Provider Verification Strength at Weak unless the provider’s identity assertion carries cryptographic proof, or your deployment adds and validates one.

​
Create a permanent access token

This section applies to Meta Cloud API only. Infobip API keys and Gupshup passwords don’t expire on a schedule, so rotate them on your own policy instead. The token on the API Setup page expires within 24 hours. Replace it with a system user token, which lasts until you revoke it. Meta explains how the token types differ under access tokens. This work happens in Meta Business Suite rather than the App Dashboard, and it needs a Meta Business admin.
1

Create a system user

  1. Open Meta Business Suite and select your business portfolio from the dropdown at the top of the page.
  2. Select its settings icon to open Business settings.
  3. Go to Users -> System users and select Add.
  4. Name the system user, set its role to Admin, and create it.
A system user represents your integration rather than a person, which is why its token survives staff changes.
2

Assign the app and the WhatsApp account

  1. Select the system user you created and select Assign assets.
  2. Assign your app and your WhatsApp Business account, granting full control on each.
  3. Reload the page and confirm both show as assigned before you continue, because a token generated before the assets attach can’t reach them.
3

Generate and store the token

  1. Select Generate token, choose your app, and set the expiration to never.
  2. Select the whatsapp_business_messaging permission so the token can send and receive messages, and whatsapp_business_management so it can manage templates and account settings. Grant nothing beyond what the integration uses.
  3. Generate the token and copy it straight into your secret manager, because Meta displays it once and never again.
  4. Update the Access Token on the Artemis connection from the Credentials tab, then revoke the temporary token.

​
Move to production

A test sender covers development and nothing else. Who does the production paperwork depends on your provider, and every path waits on Meta review. Two WhatsApp rules shape what your agent can say, whichever provider carries the traffic: The customer service window. After a customer messages you, you can reply freely for 24 hours. Outside that window, an outbound message needs an approved template, so an agent that reaches out first needs templates approved before it can start a conversation at all. Template approval is its own review, and a rejected template blocks the conversation you wrote it for. Separate senders per environment. Use different senders, credentials, webhooks, and connections for development and production. Sharing a sender means test traffic lands in the same conversation history as customer traffic.

​
Manage the channel connection

Open a WhatsApp connection from Deployments -> Channels -> WhatsApp to manage it. The page has a header, three tabs, and a summary panel on the right. Header. Shows the connection name, its environment badge, its status, and when it last changed. The … overflow menu holds the connection-level actions. Summary panel. Stays visible on every tab and carries the values you need on the provider side.
The platform encrypts credentials after you save them, so every field reads as saved rather than showing its value. Leave a field empty to keep the current value, or enter a new value to replace it.Select Save Credentials to apply your changes. Update credentials here before you revoke the old ones at the provider.

​
Key values reference

Each value sits on a different provider screen, and several look alike enough to swap by accident. Use the table for your provider to collect everything in one pass.

​
Troubleshoot connection issues

Start with the Sessions check from Verify the connection, then match the symptom here.

​
Provider reference

Use these pages when you need detail beyond what this article covers.
Related articles: