Why is this setting causing immediate failures when triggering outbound messages through the /api/v2/conversations/messages endpoint? Our Premium App integration handles high-volume notifications. The specific error returned is a 400 Bad Request with the message ‘Invalid recipient type’. This occurs only when the target user has their ‘Allow inbound messages’ setting disabled in their profile.
The application uses a service account with full admin scopes and valid OAuth tokens. The payload includes a valid conversation ID and message content. We expect the system to respect the API permissions while honoring user-level privacy settings by queuing or rejecting gracefully. Instead, the API throws a hard error that breaks our batch processing logic for scheduled alerts.
Is there a specific header or parameter required to bypass this validation for administrative actions? We need to send critical system notifications to users who have opted out of general chat. Current behavior forces us to implement complex fallback logic. Any insight on the expected behavior for this endpoint would be appreciated.