Confusing RealTime API: "Invalid value: 'input_text'. Value must be 'text'."

API
1

Hi everyone,

I’m running into an issue with the Realtime API WebSocket connection when trying to send messages. Here’s what my message object looks like:

JSON.stringify({
  type: 'conversation.item.create',
  item: {
    type: 'message',
    role: 'user',
    content: [
      {
        type: 'text',
        text: messageItem.message,
      },
    ],
  },
});

Using this format, I get the following error:

{
  "type": "error",
  "error": {
    "code": "invalid_value",
    "message": "Invalid value: 'text'. Supported values are: 'input_text' and 'input_audio'.",
    "param": "item.content[0].type"
  }
}

When I update the type field from ‘text’ to ‘input_text’ (as suggested by the error), I receive this instead:

{
  "type": "error",
  "error": {
    "code": "invalid_value",
    "message": "Invalid value: 'input_text'. Value must be 'text'.",
    "param": "item.content[0].type"
  }
}

It’s a bit of a frustrating loop—switching between ‘text’ and ‘input_text’ always leads to an error.

Has anyone else experienced this? Am I missing something in the API documentation? Would love to hear your thoughts or suggestions!

Thanks in advance!

1 Like
2

Hi there,

It seems like you’re running into an issue where the expected value of the type field in your item.content[0] is inconsistent or unclear based on the error messages you’re receiving.

Let me try to break it down:

  1. Key-Value Pair:

    • The type key should have a value that aligns with the API’s expectations. Based on your message, the API sometimes expects "text" and other times "input_text".
    • This could happen if there’s a mismatch between the API version you’re using and its documentation, or if the API’s behavior varies based on other parts of your payload.

  2. Value Validation:

    • The error suggests that the API rejected "text" and "input_text" alternately. It’s possible that the expected value changes based on the context of your request.
    • Double-check if there are any conditions or dependencies in the API docs that specify when to use "text" vs. "input_text".

  3. Potential Debugging Step:

    • If you’re consistently seeing the error despite switching between "text" and "input_text", it might indicate a deeper issue in the payload format. For example:
      • Is messageItem.message formatted correctly?
      • Are there additional required fields in the payload that could affect validation?
    • A good next step would be to log the entire payload you’re sending and compare it against the example payloads in the API documentation.

  4. Suggested Fix:

    • Try replacing your content array with a simplified payload for testing:
      JSON.stringify({
  type: "conversation.item.create",
  item: {
    type: "message",
    role: "user",
    content: [
      {
        type: "text", // or "input_text"
        text: "Sample message for testing",
      },
    ],
  },
});
    • This ensures no external variables (like messageItem.message) are causing unexpected behavior.

  5. Documentation Alignment:

    • Ensure that you’re referencing the correct API documentation for the version you’re using. If this error persists despite aligning your payload with the docs, it might be worth reaching out to the API support team.
3 Likes
3

Thank sharing your thoughts @dominickwirzba .
But it seems an issue with the API because I logged messageItem.message value type and it was string during the test.

I am using this configuration for connecting to the API:
wss://api.openai.com/v1/realtime?model=gpt-4o-realtime-preview-2024-12-17

2 Likes
4

Also, I would mention that the API responses to my requests as well and my application does what I want but I can see these errors on my log system.

1 Like
5

Hi @goldast.xps ,

Thanks for clarifying that you’ve already checked the messageItem.message value and confirmed that it’s a string during testing. That helps narrow things down! Since your application is functioning as intended despite the errors in the logs, here are some potential reasons and further steps to debug the issue:

  1. API Version and Preview Behavior:

    • The model you’re using, gpt-4o-realtime-preview-2024-12-17, is a preview version, so it’s possible that the API is logging false positives or unnecessary warnings during validation.
    • This might not impact the functionality but could clutter the logs.

  2. WebSocket Connection Handling:

    • The WebSocket might be sending intermediate validation responses even when the main operation succeeds. This could explain why you’re seeing these errors in your log system but the application still behaves as expected.

  3. Payload Consistency Across Requests:

    • It’s worth verifying that all requests sent to the API are structured the same way. Even minor inconsistencies in different parts of the payload (e.g., the role or type fields) might trigger these warnings.

  4. Steps to Isolate the Issue:

    • Since the payload works as expected but the errors persist, consider:
      • Monitoring WebSocket traffic in detail to capture all incoming responses and look for patterns in when the error is logged.
      • Testing the same payload on a stable model (e.g., gpt-4 or gpt-3.5-turbo) to check if the warnings are unique to the preview version.

  5. Reach Out to OpenAI Support:

    • If the issue persists, it might be worth reporting this to OpenAI. Be sure to include:
      • The exact payload you’re sending.
      • The WebSocket endpoint and configuration.
      • A sample of the error logs.

Example Follow-Up Questions:

  1. Do you notice any patterns in when the errors appear in the logs? For example:

    • Only on specific payloads?
    • Only after a certain number of messages?

  2. Have you tried testing the same payload on a stable model to see if the warnings persist?

I hope this helps clarify things! Let me know if you discover anything new.

Best regards,
Dominick

6

I’m not sure.

I think there was an option over at platform.openai.playground/realtime to switch between audio and text, but text was broken… i just visited the realtime tab and it seems like the functionality to use text was taken off.

I’m not entirely sure this functionality is working, I didn’t get it to work and just used a chat endpoint instead whenever i need text.

If you figure it out, please be so kind to ping me too, I don’t have any urgency on figuring this out but I was curious about the solution to this too, I ran into this a few days ago

7

Thanks @dominickwirzba for your full explanation !
It means a lot to me :slight_smile:

Finally I found the root cause of this error and it’s absolutely insane!

when I put the role value as user, the content.type must be input_text, otherwise it must be text.

openAIWebsocketRef.current.send(
    JSON.stringify({
      type: 'conversation.item.create',
      item: {
        type: 'message',
        role: messageItem.sender === 'Me' ? 'user' : 'assistant',
        content: [
          {
            type: messageItem.sender === 'Me' ? 'input_text' : 'text',
            text: messageItem.message,
          },
        ],
      },
    }),
  );
2 Likes