Skip to main content
This guide covers everything you need to build custom plugins for the Datawizz AI Gateway. Plugins are HTTP endpoints that receive requests from the gateway, process them according to your business logic, and return responses that control the request flow. A plugin is simply an HTTP endpoint that:
  1. Receives a POST request with the current request state
  2. Processes the data according to your custom logic
  3. Returns a JSON response indicating whether to allow, reject, or modify the request
Plugins can be built in any language or framework that can expose an HTTP endpoint including Node.js (Express, Fastify, Hono), Python (Flask, FastAPI, Django) or any other web framework… You can run them on serverless platforms (AWS Lambda, Cloudflare Workers, Vercel Functions) or traditional servers.

Request Schema

When a plugin is invoked, the gateway sends a POST request with the following JSON payload:

Input Structure

Field Descriptions

Phase-Specific Considerations

REQUEST Phase:
  • messages contains the messages that will be sent to the LLM (after prompt template application)
  • requestBody contains the original client request parameters
  • metadata may include prompt information if a prompt template was used
RESPONSE Phase:
  • messages contains all input messages PLUS the LLM’s response message as the last element
  • requestBody.response contains the full LLM response object
  • metadata includes additional fields like modelProvider and promptInfo
LOG Phase:
  • Same as RESPONSE phase
  • Intended for non-blocking analytics, monitoring, or logging operations

Response Schema

Your plugin must return a JSON response matching this schema:

Output Structure

Field Descriptions

Response Validation

The gateway validates your plugin’s response against the schema above using Zod. If validation fails:
  • The plugin execution is marked as failed
  • The error is logged with the validation error message
  • The request continues (fail-open behavior) with the original, unmodified messages

Implementation Examples

Example 1: Simple Content Filter (Guardrail)

This plugin rejects requests containing prohibited words.

Example 2: PII Redaction (Modification)

This plugin detects and redacts personally identifiable information.

Example 3: Response Quality Check (Guardrail)

This plugin validates that LLM responses meet quality standards.

Example 4: Context Enhancement (Modification)

This plugin adds additional context to user requests.

Testing Your Plugin

Local Testing

Before deploying your plugin, test it locally using curl or any HTTP client:
Expected response:

Integration Testing

Once your plugin is deployed and configured in the gateway:
  1. Monitor the gateway logs for plugin execution messages
  2. Check the debug array in your responses - these will appear in gateway logs
  3. Use the gateway’s inference logs to see plugin execution times and results
  4. Test timeout and retry behavior by simulating slow responses or failures

Best Practices

Performance

Response Time:
  • Aim for plugin response times under 100ms for REQUEST phase
  • RESPONSE phase plugins can be slightly slower (under 500ms)
  • Use LOG phase for any operations that can be async (analytics, slow external APIs)
Optimization Tips:
  • Cache frequently used data (e.g., ML models, lookup tables)
  • Use connection pooling for database queries
  • Implement circuit breakers for external API calls
  • Consider using async/parallel processing internally

Error Handling

Fail Gracefully:
Timeout Handling:
  • Set appropriate timeout values in your plugin configuration
  • Ensure your plugin respects the timeout and fails fast
  • Use async operations to avoid blocking

Security

As your plugins will be exposed over the internet, it’s crucial to implement robust security measures. We recommend checking for a secret header, which you can configure in the Datawizz dashboard when setting up your plugin endpoint. Authentication:
Configure the authorization header in your plugin settings in the gateway dashboard. Input Validation:
  • Always validate the structure of incoming requests
  • Sanitize any data before using it in queries or external API calls
  • Be cautious with the configs field - validate expected types
Secrets Management:
  • Never hardcode API keys or secrets in your plugin code
  • Use environment variables or secret management services
  • Rotate credentials regularly

Observability

Logging:
Metrics:
  • Track plugin execution time
  • Monitor rejection rates
  • Alert on error rates
  • Track resource usage (CPU, memory, network)

Message Handling

Preserve Message Structure:
Handle Different Content Types:

Troubleshooting

Common Issues

“Plugin response validation failed”
  • Check that your response matches the expected schema exactly
  • Ensure reject is a boolean, not a string
  • Ensure debug is an array of strings, not a single string
  • Verify messages is an array if provided
“Plugin timeout after Xms”
  • Your plugin is taking longer than the configured timeout
  • Optimize your plugin’s processing time
  • Increase the timeout value in plugin configuration
  • Move slow operations to LOG phase if possible
“Plugin returned status 500”
  • Your plugin threw an unhandled exception
  • Check your plugin’s logs for error details
  • Implement proper error handling
Messages not being modified
  • Ensure you’re returning a messages array in your response
  • Verify the array contains valid message objects
  • Check that you’re not accidentally returning the original messages reference
Plugin rejections not working
  • Ensure reject: true is present in response
  • Include a rejectReason string
  • Check that the response is valid JSON

Next Steps

Now that you understand how to build plugins:
  1. Implement a simple plugin following one of the examples above
  2. Test it locally with sample requests
  3. Deploy it to your hosting platform
  4. Configure it in the Datawizz dashboard
  5. Monitor its performance and iterate
For more information, see: