We are using Instagram API with Instagram Login on graph.instagram.com (v26.0), not the Messenger/Page-token stack.

Configuration during the controlled test: - App was Published/Live. - Standard Access only. - Permissions: instagram_business_basic and instagram_business_manage_messages only. - Receiving account was our own managed Instagram Professional account. - Connected Tools / Allow access to messages was enabled. - OAuth identity and both granted scopes were verified. - A random HTTPS callback completed Meta GET verification. - The callback accepted POST and verified X-Hub-Signature-256. - The dashboard messages test reached the receiver and returned HTTP 200. - Only the app-level messages webhook field was subscribed. - POST /{ig-user-id}/subscribed_apps?subscribed_fields=messages succeeded. - GET /{ig-user-id}/subscribed_apps confirmed only messages.

Reproduction: 1. Start the verified metadata-only receiver. 2. Confirm the app-level messages field and Professional-account subscription above. 3. Send one normal UI-originated inbound DM from a controlled ordinary Instagram account to the Professional account. 4. Observe that no webhook HTTP request arrives. 5. Read the same account via GET /{ig-user-id}/conversations.

Actual result: No real webhook request arrived. The same inbound DM was nevertheless returned by Conversations API on two independent reads. It had the same Meta message ID and Instagram-scoped sender ID on both reads, and the scoped profile lookup resolved the correct username. This proves the message exists and the token can read it.

Expected result: A messages webhook POST for the inbound DM.

We previously observed the same absence in Development mode. Publishing Live did not change real webhook delivery. After the test we unsubscribed the account and field and destroyed the temporary receiver.

Is there any additional Instagram Login-specific configuration required beyond the documented callback verification, app-level messages field, and Professional-account subscribed_apps call? If not, can Meta investigate a delivery issue for this app? Exact app/account/message IDs and UTC timestamp are available through a secure/private channel; they are intentionally omitted from this public post.