Skip to main content
Endpoint Provider Registry lets you plug custom server-side providers (recipe, agents-api, MCP, A2A, and your own) into praisonai serve — no fork required.
The user starts praisonai serve with a registered provider; HTTP traffic flows through discovery and the chosen endpoint adapter.

Quick Start

1

Use a built-in provider

2

Register at runtime

3

Distribute as a pip plugin


How It Works

The registry is thread-safe and loads plugins lazily. Built-ins are discovered on first access, entry points are loaded when needed, and aliases are case-insensitive. The singleton registry is obtained via get_default_registry().

CLI Endpoint Dispatch Registry

PraisonAI ships two endpoint registries. This page documents the top-level provider registry (praisonai.endpoint_providers). A separate CLI dispatch registry resolves how the CLI invokes each endpoint type at runtime.

Built-in CLI Dispatch Keys

If you’re writing a pip plugin for CLI dispatch, use entry-point group praisonai.endpoints.providers. For the top-level provider registry (instantiating provider classes), use praisonai.endpoint_providers.

Configuration / API

Functions

ProviderRegistry Class

Built-in Provider Types


Common Patterns

Last-write-wins behavior lets you replace built-in providers:
Use the underlying PluginRegistry for alias support:
Instantiate ProviderRegistry directly for isolation:

Best Practices

Never import your provider class at module top-level — defeats lazy loading and breaks the no-heavy-deps-at-import-time guarantee:
Required for type compatibility and consistent API:
get_provider("unknown") returns None, but import failures propagate:
Use pyproject.toml entry points instead of register_provider() calls:

Integration Registry

The sibling plugin registry for CLI tools / managed agents

Framework Adapter Plugins

Third sibling plugin registry, for framework adapters