Skip to main content
Wildo.ai Coming soon

Available integrations

Make optional SDK requirements visible

A provider can name the extra library it loads when used. The backend checks these declared runtime packages and reports missing ones before the capability is first needed.

A provider depends on an SDK being available in its runtime.

Make optional SDK requirements visible

A provider can name the extra library it loads when used. The backend checks these declared runtime packages and reports missing ones before the capability is first needed.

Install the SDK in the runtime that enables that provider. Declaring a provider does not install its optional dependency.

Example — Prepare an observability sink

A backend selects an observability provider that uses an optional analytics SDK. Its startup diagnostic names the missing package so the operator can install it in that backend.

For engineers

The PostHog backend provider puts its optional package next to the factory that uses it:

Selected from posthog.backend.module.ts; surrounding declarations and imports are omitted.

  protocols: [],
  requiredPackages: ['posthog-node'],
  agentCallTraceSinkFactory: (config, logger) =>
    new PostHogAgentCallTraceSink(
      {
        projectApiKey: config.apiKey,
        // PostHog-specific connection detail — owned by the provider, NOT the engine.
        host: process.env.POSTHOG_HOST,
        captureContent: config.captureContent,
        sampleRate: config.sampleRate,
      },
      logger,
    ),
};

This is a module fragment, not application configuration. The application declares the provider in the runtime scope and installs posthog-node in the package that runs it. The sink lazy-loads that SDK; the engine does not require every application to carry it as an unconditional engine dependency.

Understand the startup check

ExternalProvidersRegistryBackendService.reportMissingProviderRuntimePeers iterates the composed modules’ requiredPackages. It tries resolution from the running application first and the engine module second, avoiding a false missing-package report when the SDK is installed only in the application.

The diagnostic is a warning, not installation or a process-wide refusal. A provider may be declared but never reached in an environment. When the sink is actually constructed, its lazy import and provider-specific failure handling determine whether it is available.

This field is not the complete dependency graph. Some protocols carry an SDK descriptor on their runtime contract, and browser activation has its own optional-peer boundary. Check the actual provider’s requirement and its consumer rather than assuming every dependency appears here.

The declaration therefore has two useful roles: it documents what the provider loads and supplies an actionable startup diagnostic. It does not prove the installed package’s version is compatible or that a real vendor request succeeds.

Building a B2B product or an internal tool?

Wildo is not self-service yet. Tell us what you have in mind and we will say plainly whether it fits, and what happens next.