Set up Instagram Webhooks
Updated: Sep 16, 2026
Copy for LLM
Use this guide to set up Instagram Webhooks. Set up the callback before you enable notifications for an app user’s account.
Requirements
Your app must be Live to receive notifications for app users. Your Instagram API setup controls which permissions, token, host, and account ID you use.
| Component | Instagram Login | Facebook Login | Instagram Messaging through Messenger Platform |
|---|---|---|---|
Access level | Advanced Access | Advanced Access for comments and live_comments | Advanced Access |
Access token | Instagram User access token | Facebook User or Page access token | Facebook User or Page access token |
Business verification | Required for production access | Required for production access | Required for production access |
API host | graph.instagram.com | graph.facebook.com | graph.facebook.com |
Account identifier | Instagram professional account ID or /me | Facebook Page ID or /me | Facebook Page ID or /me |
Basic permission | instagram_business_basic | instagram_basic | instagram_basic |
Field-specific permissions |
Limitations
- Advanced Access is required for
commentsandlive_commentsnotifications. - The account that owns the media must be public. Private accounts do not receive comment or mention notifications.
- Comment notifications for live media stop when the broadcast ends.
- You cannot select fields for each app user account. An account receives every field selected for the app.
- Notifications do not include album IDs. Use the comment ID to query the album ID.
- Notifications do not return ad IDs for media used in dynamic ads.
story_insightsnotifications contain only the first 24 hours of metrics. This limit also applies when a story is saved as a highlight.
Step 1: Create a callback endpoint
This step must be completed before you can subscribe to any webhook fields in the App Dashboard.
Your endpoint must be able to process two types of HTTPS requests: Verification Requests and Event Notifications. Since both requests use HTTPs, your server must have a valid TLS or SSL certificate correctly configured and installed. Self-signed certificates are not supported.
The sections below explain what will be in each type of request and how to respond to them. Alternatively, you can use our sample app which is already configured to process these requests.
Verification requests
Anytime you configure the Webhooks product in your App Dashboard, we’ll send a
GET request to your endpoint URL. Verification requests include the following query string parameters, appended to the end of your endpoint URL. They will look something like this:Sample Verification Request
GET https://www.your-clever-domain-name.com/webhooks? hub.mode=subscribe& hub.challenge=1158201444& hub.verify_token=meatyhamhock
| Parameter | Sample Value | Description |
|---|---|---|
hub.mode | subscribe | This value will always be set to subscribe. |
hub.challenge | 1158201444 | An int you must pass back to us. |
hub.verify_token | meatyhamhock | A string that we grab from the Verify Token field in your app’s App Dashboard. You will set this string when you complete the Webhooks configuration settings steps. |
Validating Verification Requests
Whenever your endpoint receives a verification request, it must:
- Verify that the
hub.verify_tokenvalue matches the string you set in the Verify Token field when you configure the Webhooks product in your App Dashboard (you haven’t set up this token string yet). - Respond with the
hub.challengevalue.
If you are in your App Dashboard and configuring your Webhooks product (and thus, triggering a Verification Request), the dashboard will indicate if your endpoint validated the request correctly. If you are using the Graph API’s /app/subscriptions endpoint to configure the Webhooks product, the API will indicate success or failure with a response.
Event notifications
When you configure your Webhooks product, you will subscribe to specific
fields on an object type (e.g., the photos field on the user object). Whenever there’s a change to one of these fields, we will send your endpoint a POST request with a JSON payload describing the change.For example, if you subscribed to the
user object’s photos field and one of your app’s Users posted a Photo, we would send you a POST request that would look something like this:POST / HTTPS/1.1 Host: your-clever-domain-name.com/webhooks Content-Type: application/json X-Hub-Signature-256: sha256={super-long-SHA256-signature} Content-Length: 311 { "entry": [ { "time": 1520383571, "changes": [ { "field": "photos", "value": { "verb": "update", "object_id": "10211885744794461" } } ], "id": "10210299214172187", "uid": "10210299214172187" } ], "object": "user" }
Payload Contents
Payloads will contain an object describing the change. When you configure the webhooks product, you can indicate if payloads should only contain the names of changed fields, or if payloads should include the new values as well.
We format all payloads with JSON, so you can parse the payload using common JSON parsing methods or packages.
You will not be able to query historical webhook event notification data, so be sure to capture and store any webhook payload content that you want to keep.
Most payloads will contain the following common properties, but the contents and structure of each payload varies depending on the object fields you are subscribed to. Refer to each object’s reference document to see which fields will be included.
| Property | Description | Type |
|---|---|---|
object | The object’s type (e.g., user, page, etc.) | string |
entry | An array containing an object describing the changes. Multiple changes from different objects that are of the same type may be batched together. | array |
id | The object’s ID | string |
changed_fields | An array of strings indicating the names of the fields that have been changed. Only included if you disable the Include Values setting when configuring the Webhooks product in your app’s App Dashboard. | array |
changes | An array containing an object describing the changed fields and their new values. Only included if you enable the Include Values setting when configuring the Webhooks product in your app’s App Dashboard. | array |
time | A UNIX timestamp indicating when the Event Notification was sent (not when the change that triggered the notification occurred). | int |
Validating Payloads
We sign all Event Notification payloads with a SHA256 signature and include the signature in the request’s
X-Hub-Signature-256 header, preceded with sha256=. You don’t have to validate the payload, but you should.To validate the payload:
- Generate a SHA256 signature using the payload and your app’s App Secret.
- Compare your signature to the signature in the
X-Hub-Signature-256header (everything aftersha256=). If the signatures match, the payload is genuine.
Responding to Event Notifications
Your endpoint should respond to all Event Notifications with
200 OK HTTPS.Frequency
Event Notifications are aggregated and sent in a batch with a maximum of 1000 updates. However batching cannot be guaranteed so be sure to adjust your servers to handle each Webhook individually.
If any update sent to your server fails, we will retry immediately, then try a few more times with decreasing frequency over the next 36 hours. Your server should handle deduplication in these cases. Unacknowledged responses will be dropped after 36 hours.
Note: The frequency with which Messenger event notifications are sent is different. Please refer to the Messenger Platform Webhooks documentation for more information.
Step 2: Subscribe your app to fields
In the App Dashboard, open Webhooks for your Instagram API setup. Add the callback URL and verify token. Verify the endpoint, then select the fields that your app needs.
Use the Instagram webhook fields and permissions matrix to find supported fields. Ask only for the permissions that your app needs.
Instagram credentials
For Instagram Login, use an Instagram User access token. Send a
POST request to the account’s /subscribed_apps edge.curl -i -X POST \
"https://graph.instagram.com/v26.0/<INSTAGRAM_ACCOUNT_ID>/subscribed_apps
?subscribed_fields=<WEBHOOK_FIELDS>
&access_token=<INSTAGRAM_USER_ACCESS_TOKEN>"
Set
<WEBHOOK_FIELDS> to the fields selected in the App Dashboard. Separate field names with commas. A successful request returns:{ "success": true }
Facebook credentials
For Facebook Login, use a Facebook Page access token. Send a
POST request to the linked Page’s /subscribed_apps edge.curl -i -X POST \
"https://graph.facebook.com/v26.0/<FACEBOOK_PAGE_ID>/subscribed_apps
?subscribed_fields=<WEBHOOK_FIELDS>
&access_token=<FACEBOOK_PAGE_ACCESS_TOKEN>"
You can use
/me when the token represents the linked Facebook Page. Set <WEBHOOK_FIELDS> to the fields selected in the App Dashboard. Separate field names with commas.A successful request returns:
{ "success": true }
Step 3: Configure mutual TLS
Mutual TLS (mTLS) is a method for mutual authentication.
mTLS ensures that the parties at each end of a network connection are who they claim to be by verifying that they both have the correct private key. The information within their respective TLS certificates provides additional verification.
How to configure mTLS
Once you enable mTLS on your subscription to WhatsApp Business Account, Meta will present a client certificate together with its signing intermediate certificate. Both certificates are used to create a TLS handshake of Webhook requests to your server. Your server then can verify the sender’s identity of these requests by the trust chain and the common name (CN).
The client certificate is signed by a Meta-owned Certificate Authority (CA). Configure your server or load balancer to trust the Meta outbound API CA certificate (meta-outbound-api-ca-2025-12.pem). This certificate replaces the previous DigiCert-signed certificate, which expired on April 15, 2026.
Client certificate verification
After setting up HTTPS for receiving Webhook requests, complete the following steps to verify the client certificate and its common name
client.webhooks.fbclientcerts.com:- Install the Meta outbound API CA certificate
- Verify the client certificate against the CA certificate
- Verify the common name (client.webhooks.fbclientcerts.com) of the client certificate
Note: Servers receiving Webhooks must be using HTTPS; and we are always verifying the certificate from your HTTPS server for security.
Example
Depending on your server’s setup, the above steps vary in details. We illustrate by two examples, one for Nginx and one for AWS Application Load Balancer (ALB).
Nginx
- Download the Meta outbound API CA certificate (meta-outbound-api-ca-2025-12.pem) to your server, for example to
/etc/ssl/certs/meta-outbound-api-ca-2025-12.pem - Turn on mTLS by Nginx directives
ssl_verify_client on; ssl_client_certificate /etc/ssl/certs/meta-outbound-api-ca-2025-12.pem; ssl_verify_depth 3; - Verify the CN from Nginx embedded variable
$ssl_client_s_dnequals"client.webhooks.fbclientcerts.com"(if ($ssl_client_s_dn ~ "CN=client.webhooks.fbclientcerts.com") { return 200 "$ssl_client_s_dn"; }
AWS Application Load Balancer (ALB)
- Download the Meta outbound API CA certificate (meta-outbound-api-ca-2025-12.pem) to an S3 bucket.
- Configure the HTTPS listener on the ALB to enable mTLS with the trust store containing the Meta CA certificate in the S3 bucket.
- In your application code, extract the CN from the HTTP header “X-Amzn-Mtls-Clientcert-Subject”, and verify it equals
"client.webhooks.fbclientcerts.com".
Downloadable CA certificate
Step 4: Test delivery
- Use Test for a selected field in the App Dashboard. Confirm that your endpoint receives the sample notification.
- Trigger an event for the connected account. For a messaging app, send the account a test message.
- Confirm that your endpoint checks the signature and returns a successful HTTPS response.
- Confirm that duplicate notifications do not repeat an action.
- Compare the payload with the Webhook notification examples.
Troubleshooting checklist
If your endpoint does not receive notifications, check that:
- The callback URL passed its check and is reachable over HTTPS.
- Your app selected the expected field.
- Notifications are enabled for the app user account.
- The token matches the login setup used by the request.
- The app has the right access level for the field.
- The account meets the field rules.
- Your server returns a success response before it starts slow work.
Do not include access tokens, app secrets, or client credentials in logs or support requests.
Sample application
The Graph API Webhooks sample application shows how a server can process verification requests and notifications. Review its storage, security, and deployment settings before using it in production.
Configure the sample application
The sample is a Node.js app that uses
body-parser, express, and express-x-hub. It can be deployed to Heroku for testing.To configure the sample:
- Create a Heroku account and deploy the sample app.
- In the Meta App Dashboard, open App settings > Basic and copy the app secret.
- Choose a verify-token string.
- In the Heroku app settings, create
APP_SECRETandTOKENconfiguration variables. SetAPP_SECRETto the app secret andTOKENto the verify-token string. - Open the Heroku app URL. An empty array (
[]) appears before notifications are received. - Use the Heroku app URL with
/facebookappended as the callback URL. - Use the
TOKENvalue as the verify token when configuring Webhooks in the App Dashboard.
Verify the sample application
- In the App Dashboard, open the Webhooks product and select Test for a webhook field.
- Review the sample payload, then select Send to My Server.
- Confirm that the notification appears at the Heroku app URL. You can also run
curl https://<YOUR_SUBDOMAIN>.herokuapp.com.
Next steps
- Learn how to send and receive messages from Instagram professional accounts.
- Review Webhooks from Meta.