API Reference

Guardrail api/v1/guardrails base view, for invoking a Guardrail.

class smarter.apps.guardrail.api.v1.views.base.GuardrailApiBaseViewSet(**kwargs)[source]

Bases: SmarterAuthenticatedNeverCachedWebView

Base viewset for all Guardrail API endpoints.

This class serves as the foundational viewset for all guardrail-related APIs in the Smarter platform, including prompt completions that leverage the Smarter LLM Tool Call Plugin architecture.

Key Responsibilities:

  • API Key Authentication and Request Validation: Enforces authentication for all API requests, rejecting those without a valid API key.

  • Lifecycle Management: Handles initialization of Account, Guardrail, GuardrailHelper, and PromptHelper objects, and manages request dispatching and routing to the appropriate handler methods.

  • Logging and Observability: Provides robust logging and observability for all major lifecycle events, including error handling.

Django Integration:

  • Subclasses Django’s view-template system (not DRF), participating in the standard request/response lifecycle.

  • Overrides and extends methods such as setup(), dispatch(), get(), and post() to provide guardrail-specific logic.

  • CSRF-exempt to support API clients.

Prompt Completion & LLM Tool Call Plugins:

  • This base view is designed to support prompt completion endpoints that utilize Smarter’s LLM Tool Call Plugin architecture.

  • Plugins can be discovered and invoked as part of the guardrail’s response generation, enabling extensible and dynamic tool use.

Examples:

Notes:

  • Intended to be subclassed by concrete guardrail API views.

  • Provides robust error handling and logging for all major operations.

  • Authentication is enforced by default.

  • CSRF-exempt for API compatibility.

See Also:
dispatch(request, *args, name=None, **kwargs)[source]

Dispatch method for the Guardrail API base viewset.

This method is invoked as part of the Django REST Framework (DRF) view lifecycle. It is responsible for preparing the viewset for request processing, including initializing the GuardrailHelper and PromptHelper instances, setting up the request context, and logging relevant information for observability and debugging.

The dispatch method performs the following key actions:

  • Extracts and sets the guardrail ID from the URL parameters, if present.

  • Initializes the Guardrail and Account context for the request.

  • Validates the existence and readiness of the GuardrailHelper and Guardrail instances.

  • Handles error conditions such as missing or invalid guardrail configuration, returning appropriate HTTP error responses.

  • Loads and attaches plugins for the guardrail, if available.

  • Emits signals and logs key request metadata for auditing and debugging.

  • Calls the parent class’s dispatch method to continue the DRF request/response lifecycle.

Parameters:
  • request (ASGIRequest) – The HTTP request object provided by Django, containing all request data, headers, and user context.

  • *args – Additional positional arguments passed to the view.

  • name (Optional[str]) – The name of the guardrail, if provided as a URL parameter.

  • **kwargs – Additional keyword arguments passed to the view, often including URL parameters.

Returns:

A Django JsonResponse or HttpResponse object representing the result of the request, or an error response if initialization fails.

Return type:

JsonResponse or HttpResponse

Notes

  • This method is a critical integration point with DRF’s request/response lifecycle.

  • It ensures that all necessary context, helpers, and plugins are available before the main handler methods are called.

  • Subclasses may override this method to provide additional dispatch logic, but should always call super().dispatch() to preserve base functionality.

See also

-, -

property formatted_class_name: str

Returns the class name in a formatted string.

along with the name of this mixin.

Returns:

Formatted class name string.

Return type:

str

get(request, *args, name=None, **kwargs)[source]

GET request handler for the Smarter Prompt API.

Currently, GET requests are not supported and will return a message indicating that POST should be used instead.

Parameters:

request (ASGIRequest) – The HTTP request object.

Returns:

A JsonResponse indicating that GET is not supported.

Return type:

JsonResponse

property guardrail

Returns the Guardrail instance.

Returns:

The Guardrail instance.

Return type:

Optional[Guardrail]

property guardrail_id

Returns the guardrail ID.

Returns:

The guardrail ID.

Return type:

Optional[int]

http_method_names: list[str] = ['get', 'post', 'options']
property name

Returns the name of the guardrail.

Returns:

The name of the guardrail.

Return type:

Optional[str]

options(request, *args, **kwargs)[source]

OPTIONS request handler for the Smarter Prompt API.

Sets CORS headers to allow cross-origin requests from the Smarter environment URL.

Parameters:

request (ASGIRequest) – The HTTP request object.

setup(request, *args, **kwargs)[source]

Set up the Guardrail API base viewset for request processing.

This method is called as part of the Django REST Framework (DRF) view lifecycle, immediately after the view instance is created and before the request is dispatched to the appropriate handler method (such as get() or post()).

The primary responsibilities of this method are to:

  • Initialize the SmarterRequestMixin with the current request and any additional arguments.

  • Prepare and set up the GuardrailHelper and PromptHelper instances, which are used throughout the request lifecycle for guardrail-specific logic and prompt session management.

  • Log key setup events for observability and debugging.

Parameters:
  • request (ASGIRequest) – The HTTP request object provided by Django, containing all request data, headers, and user context.

  • *args – Additional positional arguments passed to the view.

  • **kwargs – Additional keyword arguments passed to the view, often including URL parameters.

Notes

  • This method is a critical integration point with DRF’s request/response lifecycle.

  • It ensures that all necessary context and helper objects are available before the main handler methods are called.

  • Subclasses may override this method to provide additional setup logic, but should always call super().setup() to preserve base functionality.

See also

-, -, -