REST API

Figure 1: Simple REST API Configuration Without Headers

• URL - This is your target endpoint to which the attack messages will be sent.

• POST Request Payload Sample - Here, you provide the payload (body of the HTTP request). Once provided, the payload should include the following placeholders, which you need to insert:

  • {message} - This placeholder represents where the Probe will insert attack messages, simulating input from a user interacting with your application.

  • {session_id} - This placeholder marks the location where a unique string, identifying the current conversation session, will be placed. This ensures that the request is tied to a specific session for multi-step testing.

  • The payload can contain additional fixed arguments if needed.

• Response Path - The JSON path pointing to the message within your chatbot's API response to the given request.

• HTTP Headers - Enter the key-value pairs necessary for your API Requests. Authorization headers must be included for non-public APIs.

Obtaining the values

One way to obtain these values is by interacting with your application and inspecting the network requests using developer tools (e.g., in your browser or API testing tool like Postman).

• URL: Locate the endpoint URL where your chatbot sends requests. This is typically found in the network tab of developer tools or in your API documentation.

• HTTP Headers: Review the headers in the network request to identify any required key-value pairs, such as authorization tokens or content types.

• Request Payload: Copy the body of the POST request, then replace the user message with the {message} placeholder and the session identifier with the {session_id} placeholder.

• Response Path: Inspect the chatbot's API response and identify the JSON path to the specific part of the response where the chatbot's message is returned.

Session Management

Sometimes, the way your application handles sessions, used to track that messages belong to the same conversation, may involve separate endpoints from those used for sending messages. For example:

• A session might be initiated with one request to an "open session" endpoint.

• The session might then be closed with another request to a "close session" endpoint.

If your application operates this way, the Open Session and Close Session options can be toggled and configured in the integration settings. This allows you to add the appropriate requests for starting and ending sessions, ensuring the Probe can properly simulate and test multi-step conversations.

SplxAI Proxy

API endpoints can be implemented in various ways, and we can’t cover every scenario. To address this, we’ve developed the SplxAI Proxy Interface, which you can use for easier integration.

Feel free to contact us, and we’ll assist you in creating it.