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.
The engine ships server modules for email (Resend, which also receives email, SendGrid, Brevo, Postmark, Mailgun and Mailchimp Transactional, plus a local preview that sends nothing), payments (Stripe) and text messages (Twilio). For AI it ships language models from Anthropic, OpenAI, Google, Mistral, Grok and Perplexity; OpenAI also produces images and embeddings, Mistral also reads scanned documents, and Anthropic, OpenAI and OpenCode run coding agents.
It also ships sign-in with Apple, GitHub, Google and Microsoft, connections to a person’s Google Drive or OneDrive, PostHog for model-call traces, Better Stack for telemetry, immudb as a tamper-evident audit ledger, reCAPTCHA to verify form submissions and Google Places for address lookup. Vendor modules from Wildo’s module registry, such as Asana, Microsoft Teams and Azure Document Intelligence, are installed into the application and become its own code.
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. Any other provider is a package installed in the runtime owner that exposes the discovery/runtime entrypoints. A vendor module from the module registry is installed with wildo registry add wildo/providers/<ref>, which copies it into the application as its own @<your-scope>/provider-<ref> package and adds that package to the backend; an application can also author one in the same shape.
Know what each engine module is for
The provider reference is what an application declares; the right-hand column is how the engine reaches it.
| Need | Engine provider references | How it is reached |
|---|---|---|
| Transactional email | resend, sendgrid, brevo, postmark, mailgun, mailchimp; email-preview for local development | EMAIL_TRANSACTIONAL slot |
| Marketing email | sendgrid, brevo | EMAIL_MARKETING slot |
| Receiving email | resend | EMAIL_INBOUND slot |
| Billing | stripe | BILLING slot |
| Text messages | twilio | SMS slot |
| Language models | anthropic, openai, google, mistral, grok, perplexity | AI_LLM slot |
| Images, embeddings | openai | AI_IMAGE_GENERATION, AI_EMBEDDINGS slots |
| Scanned documents | mistral | AI_DOCUMENT_EXTRACTION slot |
| Coding agents | anthropic, openai, opencode | AI_CODING_AGENT slot |
| Sign-in | apple, github, google, microsoft | The authentication subsystem |
| Personal drives | google-drive, microsoft-onedrive | File pickers and file storage |
| Model-call traces, telemetry, audit ledger | posthog, betterstack, immudb | LLM_OBSERVABILITY, OBSERVABILITY_TELEMETRY, COMPLIANCE_AUDIT_TRAIL slots |
| Form verification, address lookup | recaptcha, google-places | The engine’s contact form; the address field |
microsoft also carries the Microsoft Graph connection that registry modules such as Teams add operations to. Browser-side modules, such as error monitoring and file pickers, are described in browser integrations.
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 vendor 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 Asana 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 created task’s reference.