# Plugins & integrations (https://docs.getaviato.com/integrations) Use Aviato's language SDKs to extend your back-office with application behavior and ready-to-use provider widgets. Your agent runs next to your database; your application hosts the SDK plugin that declares the behavior and widget bindings. Display customers, subscriptions, and invoices on record pages with typed plugins. Run the customer-side agent and connect your database. Compare TypeScript, Go, and Laravel capabilities and installation requirements. Expose an external source as a collection of records. ## Typed provider plugins [#typed-provider-plugins] `StripePlugin` implements the common `IntegrationPlugin` interface in each SDK. Its typed methods distinguish customer IDs, subscription IDs, and invoice IDs. Configure the credential environment-variable name once, declare the widgets you want, and register the integration on your application plugin using `use` / `Use`. Each widget selects a collection, a unique name within that collection, and an ID column. Bind directly to the current record or through one `belongsTo` relation. For example, an order can display invoices using its customer's `stripe_customer_id`. An optional title customizes the heading; otherwise Aviato supplies a localized title. | SDK | Integration registration | Setup | | ---------- | ----------------------------------------------- | ------------------------------------------ | | TypeScript | `plugin.use(stripe)` | [TypeScript SDK](/integrations/typescript) | | NestJS | `AviatoModule.forFeature({ plugins: [token] })` | [NestJS integration](/integrations/nestjs) | | Go | `plugin.Use(stripe)` | [Go SDK](/integrations/go) | | Laravel | `Aviato::use($stripe)` | [Laravel SDK](/integrations/laravel) | Registration validates and snapshots the declarations. To apply builder changes, register the integration again. An invalid registration leaves existing definitions unchanged. Reusing a collection/name pair replaces that widget while preserving others. Stripe is the first supported provider. The [Stripe guide](/integrations/widgets) contains complete examples and describes availability in the upcoming 0.2.0 SDKs. Intercom and Zendesk are planned possibilities, with no built-in adapters yet. ## Where provider requests run [#where-provider-requests-run] The record page requests a widget from your agent. The agent checks record and column permissions, resolves the provider ID from your database, and requests data directly from Stripe. It returns only the display fields supported by the widget. Store the restricted Stripe key in the agent's process environment. SDK configuration contains only its environment-variable name. Provider keys and response bodies never pass through Aviato's control plane. The ordinary audit trail records the local record read and outcome without provider IDs, keys, or response bodies. Widgets currently perform reads only. Configure the Stripe restricted key with Read/None permissions: accepting a restricted-key prefix and `readOnly: true` does not prove that the key has no write permissions. Follow the [credential setup](/integrations/widgets#configure-a-read-only-stripe-key). ## Extending the system [#extending-the-system] Integration authors implement `IntegrationPlugin` to produce widget declarations. Provider execution belongs in the customer agent's provider registry, where each adapter defines supported resources, credential rules, fixed endpoints, and projected display fields. Declaring a new provider name alone does not install an adapter. The shared contract lets future providers reuse record authorization and the existing widget renderer. See [future providers](/integrations/widgets#future-providers) for the extension boundaries. For application-specific behavior today, use SDK actions, hooks, [custom summaries and forms](/guides/custom-ui), or [custom datasources](/integrations/custom-datasources).