Choose server integrations for the work you need
Use provider modules for server-side services such as email, billing, models and business APIs. Each module describes its identity, capabilities, protocols and credential requirements.
Select the providers each runtime uses. Engine service providers and vendor-specific API modules share the provider model while serving different application needs.
Example — Give the backend an email service
A backend declares an email provider for transactional delivery. A separate worker declares only the providers it needs, so it does not load the backend’s whole vendor set.
For engineers
Wonder CRM names its transactional email provider inside providers.scopes.backend.providers:
Selected from wildo.saas.config.ts; surrounding declarations and imports are omitted.
resend: {
engineCapabilities: [EngineCapability.EMAIL_TRANSACTIONAL],
providerCapabilities: ['EMAIL_TRANSACTIONAL'],
protocols: ['EMAIL_PROVIDER'],
},
This is a selected configuration entry. The provider’s capability and protocol declarations must agree with the module. The application also enables and selects the relevant engine capability where that service uses selection, supplies credentials, and runs wildo config sync to produce runtime artifacts.
An engine-shipped provider needs no separate vendor package. A packaged provider must be installed in the runtime owner and expose the discovery/runtime entrypoints. The generated catalogue uses a vendor subpath such as @wildo-ai/providers/slack; it does not provide a root import of every vendor.
Load only the declared modules
Engine backend loaders map provider references to dynamic imports. Runtime composition loads the chosen set and checks protocol-key/runtime-kind agreement. Capabilities that fill an engine slot participate in its resolver; a catalogue REST provider can instead be called explicitly by reference without claiming an engine capability.
| Choice | What it establishes |
|---|---|
| Runtime scope | Which host may load this provider |
| Capability declaration | Which service contract it can satisfy |
| Protocol binding | Which executable interface it implements |
| Credential configuration | Which account the call uses |
| Application call or engine selection | How the provider is actually reached |
Adding a vendor to a configuration is not a successful vendor exchange. Verify the required operation and account permissions in the target environment. Where an alternative implements the same engine contract it can be selected; a vendor-specific API remains its own contract and may require application changes.
For a vendor-specific action, the Slack application example connects this declaration to executor.execute: it supplies the current operation context, names the account target, validates the vendor reply and retains the resulting message reference.