# Version 2.5.4 TextBee Inbound Polling Fallback

This patch fixes the case where:

- TextBee successfully sends the initial SMS.
- The customer replies.
- The reply does not show in the lead dashboard.
- The AI assistant does not respond.

## Root cause likely

TextBee is receiving the customer's reply, but the inbound webhook is not firing to:

/sms/incoming

or the webhook is pointed at the wrong domain/subdomain.

## Fix

The app now has a fallback poller that periodically calls TextBee's received-SMS endpoint and sends any new replies through the same AI assistant pipeline.

## New settings

Environment variables:

TEXTBEE_INBOUND_POLLING_ENABLED=true
TEXTBEE_INBOUND_POLLING_INTERVAL_SECONDS=30
TEXTBEE_INBOUND_POLLING_LIMIT=25

Admin page:

/admin/system

New fields:

- TextBee Inbound Polling Fallback
- TextBee Poll Interval Seconds
- TextBee Poll Limit

## Duplicate protection

The poller creates a stable TextBee provider ID for every received SMS.

That means repeated polling should not create duplicate AI replies.

## Manual test

Open:

GET /admin/api/textbee/received?limit=10

If replies show there, run:

POST /admin/api/textbee/process-received

Now that endpoint uses the same processor as the automatic poller.

## Logs

Look for:

- [TextBee inbound polling started]
- [TextBee inbound processor results]
- [Incoming SMS saved to lead]
- [Incoming SMS received]
- [TextBee inbound polling failed]

## Notes

Keep the TextBee webhook configured if possible. Polling is a fallback, not a replacement for a properly working webhook.