Integrations
Integrations connect Stallari to models, services, devices, and client surfaces. Install only what you plan to use, and approve sensitive plugins deliberately.
Integration Types
Section titled “Integration Types”| Type | Purpose |
|---|---|
| Model providers | Give Stallari an inference route for Chat and workflows. |
| Plugins / MCPs | Connect to services such as mail, tasks, calendars, files, and other local capabilities. |
| Platform integrations | Connect local networking, vault apps, or system services. |
| Client integrations | Surface notifications, review prompts, or companion app features. |
Provider Setup
Section titled “Provider Setup”At least one model route is needed before Stallari can run most work. Common choices include OpenAI, Anthropic, Google, xAI, local models, and compatible endpoints.
Provider configuration lives in Settings. Provider keys are stored in the local credential store, not in the public configuration file.
Provider access does not grant blanket vault access. Each job receives only selected context and permitted plugin results.
Plugin Setup
Section titled “Plugin Setup”Plugins declare the service contracts they support and the credentials they need. Before using sensitive capabilities, Stallari should show:
- publisher identity,
- requested data classes,
- action classes,
- network behavior,
- cloud-context implications,
- and the revocation path.
Installing a plugin is not the same as approving every action it can perform.
Platform Setup
Section titled “Platform Setup”Platform integrations are optional. They can improve local networking, peer discovery, vault viewing, or local inference, but Stallari should continue to show clear degraded states when a platform integration is unavailable.
Use Status to diagnose platform readiness. Use Settings to change the controls.
Client Setup
Section titled “Client Setup”Client integrations can deliver notifications, review prompts, or remote visibility. Treat them as additional surfaces over the same local system, not as separate authority sources.
Review and approval behavior should remain explicit even when a prompt appears on a phone or another device.
Troubleshooting
Section titled “Troubleshooting”| Symptom | Where To Start |
|---|---|
| A provider is unavailable | Settings provider card, then Status for readiness. |
| A plugin is installed but cannot run | Credentials, consent, and plugin health. |
| A platform feature is missing | Status for capability detection and recovery copy. |
| A client does not receive prompts | Notification settings, client pairing, and helper health. |
Related concepts
Section titled “Related concepts”- Local Vs Cloud — provider routing decides which inference path each integration may use
- Packs And Trust — plugin and pack integrations declare data classes, action classes, and revocation paths