Connector
Register Python functions as testable endpoints in Rhesis using the SDK connector. This code-first approach automatically creates and manages endpoints, providing an alternative to manual endpoint configuration.
How it works: Decorate functions with @endpoint and they automatically become endpoints
in Rhesis. The SDK connects via WebSocket, registers function metadata, and keeps endpoints in
sync with your code.
Quick Start
Initialize the Client
Decorate Functions
Automatic Registration
When your app starts, functions are automatically registered as endpoints. View them in Projects → Your Project → Endpoints.
See It in Action
Watch this video to see how the Rhesis SDK connector integrates an LLM application in under a minute using a single decorator:
What You’ll Learn:
- Integrating an LLM app with the
@endpointdecorator - Automatic session management in action
- Single-turn and multi-turn testing made easy
No complex APIs. No orchestration. Just one decorator connecting your Python functions to comprehensive testing.
Environment
The environment parameter is required and must be one of:
development: Local iteration and testingstaging: Pre-production validationproduction: Live systems
Production: Changes take effect immediately. Test in development/staging first.
Disabling the Connector
To disable all connector and tracing functionality (useful for CI/CD or testing), set:
Accepted values: true, 1, yes, on (case-insensitive)
When disabled:
@endpointand@observedecorators return functions unmodified- No WebSocket connection is established
- No telemetry or tracing occurs
- All SDK method calls become no-ops
Use this in CI pipelines or test environments where you don’t want connector overhead.
Platform Integration
Viewing Endpoints
Registered endpoints appear in the Rhesis dashboard:
- Location: Projects → Your Project → Endpoints
- Connection Type:
SDK - Status:
Active(connected) orInactive(disconnected) - Naming:
{Project Name} ({function_name})
Connection Management
- Reconnection: SDK automatically reconnects with exponential backoff if connection is lost
- Re-registration: Functions are automatically re-registered on reconnect
- Function changes: Adding/modifying functions updates endpoints automatically; removing functions marks endpoints as Inactive
Best Practices
- Use connectors when: Functions are in your codebase, using standard patterns, want code-first definition
- Use manual config when: Testing external APIs, need complex transformations, services outside codebase
- Function naming: Use descriptive names (avoid
function1,handler) - Type hints: Always include type hints for better auto-detection and type serialization
- Error handling: Return structured error responses:
{"output": None, "status": "error", "error": str(e)} - Parameter binding: Use
bindfor infrastructure dependencies (db, config, auth) that shouldn’t appear in remote signatures - Callable bindings: Use lambdas for dependencies that need fresh values per call (database connections, auth context)
- Static bindings: Use direct values for singletons (configuration objects, shared resources)
- Avoid binding business logic: Only bind infrastructure dependencies, not business logic parameters
Troubleshooting
Functions not appearing:
- Verify
RhesisClientinitialized withapi_key,project_id, andenvironment - Check functions use
@endpoint()decorator - Check logs for “Connector initialized” and “Sent registration” messages
Connection issues:
- Verify API key and project ID are correct
- Ensure Rhesis backend is accessible
- Check firewall/network settings for WebSocket connections
Mapping problems:
- Auto-mapping: Use standard field names (
input,session_id,output) - Manual mapping: Verify Jinja2/JSONPath syntax
- Custom fields: Ensure custom request fields are included in API requests
Common errors:
"RhesisClient not initialized": CreateRhesisClientinstance before using@endpoint"@endpoint requires project_id": Provideproject_idor setRHESIS_PROJECT_IDenv var"Functions not appearing as Active": Restart app to trigger re-registration
Parameter binding issues:
- Bound parameter not injected: Ensure the parameter name in
bindmatches the function parameter name exactly - Callable not evaluated: Check that you’re passing a callable (lambda or function), not calling it (e.g.,
lambda: get_db()notget_db()) - Static value stale: If using a static value that changes, use a callable instead:
bind={"config": lambda: get_config()} - Exception in bound callable: Exceptions in bound callables are propagated - ensure your dependency functions handle errors gracefully
Next Steps - Learn about Mapping for input/output transformations - See Advanced Mapping for complex objects - Explore Parameter Binding for dependency injection