Give each connection a clear contract
Email, model calls, incoming events and REST requests have different inputs and execution behavior. Wildo gives these connection types named contracts instead of treating every provider as an interchangeable URL.
A provider implements the contract appropriate to its work. The application chooses the provider and the configuration that the contract requires.
Example — Chat and document reading are separate choices
A product uses one model for conversation and another provider to extract text from documents. Separate connection contracts let those choices evolve independently, even when a vendor offers both services.
For engineers
Match the authoring protocol to the executable binding
A backend module pairs its declared protocol with a discriminated runtime contract. This selected Resend binding shows the email path and encoding inside that contract; request-builder and response-parser implementations are omitted:
{
protocol: "EMAIL_PROVIDER",
runtimeContract: {
kind: ProviderProtocolRuntimeKind.EMAIL,
baseUrl: "https://api.resend.com",
apiKey: {
secretRef: "RESEND_API_KEY",
headerName: "Authorization",
prefix: "Bearer "
},
operations: ["sendEmail", "sendBatch"],
supportedEmailTypes: ["transactional"],
sendEndpointPath: "/emails",
payloadEncoding: EmailProviderPayloadEncoding.JSON,
// buildSendRequest and parseSendResponse complete this binding.
},
}
This is an explanatory selection from the current module, with compacted arrays. A complete email binding also implements its request builder and response parser. Composition checks that the authoring key and runtime kind agree; a protocol name alone does not install executable behavior.
Select a contract that describes the work
ExternalProvider_ExchangeProtocol_Kind owns the protocol vocabulary. Backend runtime kinds are a subset of its values, so dispatch can discriminate the relevant contract without translating between unrelated identifiers.
| Work | Contract distinction |
|---|---|
| Generate conversation | Language-model runtime |
| Create vectors for retrieval | Embeddings runtime, selected separately from chat |
| Extract text from document bytes | Document-extraction runtime |
| Receive vendor events | Webhook-originator binding and its ingress consumer |
| Run browser integration code | Frontend SDK module, outside the backend runtime union |
Application configuration selects the protocol in its provider scope and supplies protocol-specific settings where required. Keep the provider’s runtime module reachable through the generated artifact and its package entrypoint.
Extend the implementation as well as the vocabulary
When adding a vendor for an existing contract, implement the provider-specific details in its module and test the relevant consumer. Naming an additional protocol requires an executable contract and a consumer; a declared identifier is not evidence of supported behavior. Audio and video identifiers remain reserved rather than runnable backend contracts.