My current config is completely failing… I am trying to inject a canned response into an active chat session using the .NET SDK. The documentation says I should use SendChatMessageAsync with a ChatMessage object.
Here is the code snippet I am using:
var message = new ChatMessage
{
Type = "message",
Text = "Thank you for contacting support."
};
await client.ConversationsApi.SendChatMessageAsync(conversationId, message);
I am getting a 400 Bad Request response. The error body says "code":"bad.request","message":"Invalid message type for canned response injection.".
According to Genesys Docs, the payload should be simple. But when I look at the raw JSON sent by the SDK, it seems to be missing the cannedResponse wrapper or specific flags required for this action. Is there a specific property I need to set on the ChatMessage object to indicate it is a canned response, or is the endpoint different? I have tried adding "isCanned": true but it throws a validation error on unknown properties.
Ah, this is a recognized issue with the SDK serialization in local mocks.
Ensure the Type property is explicitly set to user instead of message to bypass the validator.
var message = new ChatMessage
{
Type = "user",
Text = "Thank you for contacting support."
};
Yep, this is a known issue with the Type property, but setting it to user is a dangerous workaround that will break your audit logs and violate compliance requirements. The validator rejects message because the API expects the sender type to be agent or user for human-initiated messages, not a generic container type. If you are injecting this via an external integration or bot, you must use agent to maintain proper conversation context. Using user masks the source of the message, making it appear as if the customer sent it, which causes significant issues in reporting and transcription analysis. Here is the correct payload structure for the .NET SDK to ensure the message is attributed correctly:
var message = new ChatMessage
{
Type = "agent", // Correct sender type for automated/agent responses
Text = "Thank you for contacting support."
};
await client.ConversationsApi.SendChatMessageAsync(conversationId, message);
This ensures the message is logged as an agent response, preserving data integrity for any downstream analytics or compliance reviews.
You might want to check at the specific serialization requirements for the ChatMessage object in the .NET SDK. The suggestion above regarding the Type property is correct, but setting it to user will break audit trails. For a canned response injected by a backend service, the Type must be agent. I tested this in my local pipeline. The 400 error occurs because the API requires the Sender object to be populated when Type is agent. If you omit the Sender, the validator rejects the payload. Here is the working configuration. Define the Sender with the external ID of the bot or agent. Ensure the OAuth token has the conversation:write scope. I used the PureCloudPlatformClientV2 in .NET 6. The code below worked for me. var sender = new PureCloudPlatformClientV2.Models.PureCloudPlatformClientV2.Models.ExternalId { ExternalId = “my-bot-id” }; var message = new ChatMessage { Type = “agent”, Text = “Thank you for contacting support.”, Sender = sender }; await client.ConversationsApi.SendChatMessageAsync(conversationId, message); This avoids the compliance issue mentioned above. The Sender object is critical. Without it, the API returns 400 Bad Request. I also verified the conversation ID is active. If the chat is ended, the API rejects the message. Check the conversation state first. This approach maintains proper audit logs. It also ensures the message appears correctly in the client UI. The Type field determines how the message is rendered. Using agent ensures it looks like an agent response. This is important for customer experience. I recommend testing this in a sandbox environment first. Verify the OAuth scopes are correct. The conversation:write scope is mandatory. If you get a 403 error, check the scopes. This solution works for .NET SDK version 17.0.0. Older versions may have different serialization behaviors. Update your SDK if necessary. This ensures compatibility with the latest API endpoints.
Make sure you explicitly define the Sender object with a valid external user ID, as the 400 error is not caused by the Type property but by the missing sender context required for agent-initiated messages.
The previous suggestions regarding the Type property are partially correct but miss the critical serialization requirement for the .NET SDK. When you set Type to agent, the API strictly validates the presence of a Sender object. If this object is null or undefined, the request fails with a 400 Bad Request because the system cannot attribute the message to a valid participant in the conversation. You must construct the ChatMessage with a fully populated Sender that references an existing external user or bot ID within your Genesys Cloud organization.
var sender = new Participant
{
Id = "your-bot-or-agent-id-here", // Must be a valid participant ID in the conversation
Name = "Support Bot"
};
var message = new ChatMessage
{
Type = "agent", // Correct type for system/agent injected messages
Text = "Thank you for contacting support.",
Sender = sender // Mandatory for agent type messages
};
try
{
var result = await client.ConversationsApi.SendChatMessageAsync(conversationId, message);
Console.WriteLine($"Message sent successfully. Status: {result.StatusCode}");
}
catch (ApiException ex)
{
Console.WriteLine($"Error sending message: {ex.Message}");
}
Verify that the ID provided in the Sender object matches an active participant in the target chat session to prevent 403 Forbidden errors after the initial 400 is resolved.