> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tensor9.com/llms.txt
> Use this file to discover all available pages before exploring further.

# External Services in Customer Installs

> Decide which external services your BYOC product uses, who owns them, and how to verify the resulting application.

> [!NOTE]
>
> Preview guidance. Review the decisions and proposed changes before applying them to your product.

A customer-owned cloud account does not move your billing, identity, telemetry or other external accounts into it. Your application can still contact those services during startup, signup, a scheduled job or a webhook.

You decide which functions belong in your BYOC product. Tensor9's supported infrastructure transforms do not silently remove application dependencies, supply third-party credentials or choose your customer's access policy.

## Choose behavior and ownership separately

For each service, first decide whether the function is needed. Then decide who operates any retained account.

| Choice | What you must resolve |
| - | - |
| Retain a vendor-owned service | Account and customer isolation, permitted data flows, credentials, billing and outage ownership |
| Retain a customer-owned service | Supported account setup, customer configuration, account-scoped identifiers, permissions and maintenance |
| Replace the function | Replacement behavior, data migration, application changes and compatibility with existing installs |
| Remove the function | The resulting product behavior, including any replacement licensing, quota or entitlement policy |

Changing a credential does not migrate remote objects or stored identifiers. Removing a secret does not stop code from requesting it. An unanswered choice stays open.

See the dedicated [Stripe](https://docs.tensor9.com/byoc/onboarding/stripe.md) and [Metronome](https://docs.tensor9.com/byoc/onboarding/metronome.md) guides for billing examples.

## Follow every consumer

Inspect more than Terraform. Trace each dependency through:

* SDK initialization, imports and application startup.
* Native user signup, organization creation and ordinary API requests.
* Queues, scheduled tasks, background workers and retries.
* Inbound webhooks, outbound calls, network access and callback addresses.
* Database schema, reference data, migrations and account-scoped identifiers.
* Usage, credits, quotas, subscriptions and entitlement checks.
* User-facing settings, billing pages, monitoring and operational scripts.

A service name or SDK import is a reason to investigate. It does not prove the call runs, that removal is safe, or that a matching feature flag controls every consumer. Keep separate evidence for separate consumers, including delayed jobs.

For example, a fictional application might create a billing customer during signup and emit usage overnight. Removing only the signup call leaves the overnight dependency intact. A disabled dashboard setting might control neither call.

## Plan the accepted change

Record the service's purpose, evidence locations, selected behavior, account owner, required configuration, affected code and data, implementation owner, and observable checks. Keep suggested choices separate from your actual answer and from completed implementation.

For a retained service, define supported secret delivery, key rotation, data retention, external connectivity and outage behavior. Customer ownership needs an account setup procedure; a vendor's account-specific product or contract ID usually cannot be reused unchanged.

For replacement or removal, agree on the new business policy before editing. Preserve required history and define the order for fresh installs and upgrades. Stop or migrate producers and delayed work, handle queued events and callbacks, introduce compatible application/data changes, and only then remove unused inputs and infrastructure. Review the resulting diff and cleanup separately. Catching provider errors and granting everyone access is not an implied replacement policy.

## Verify the product your customer receives

Use external input and an independent read-back. A useful application check creates a native user and organization, creates a record through the supported API, then authenticates and reads that exact record back.

For retained integrations, also read the corresponding provider object and confirm the application reflects the expected result. Exercise duplicate or delayed events, expired credentials and unavailable providers against the chosen policy.

For a removed integration, test a fresh install and a supported upgrade with the service absent. Exercise core application operations, delayed jobs and access-denial behavior. Confirm that the approved replacement policy works and required history survives.

Secret presence, a successful infrastructure apply, logs and a health endpoint do not establish these outcomes. Keep unexecuted checks and unresolved dependencies visible.

## Use the shared consideration catalog

The [Claude Code and Codex skills](https://docs.tensor9.com/byoc/onboarding/agent-skills.md) use shared consideration data to ask these questions. The initial catalog contains 96 service entries across 12 categories. Entries provide research cues and choices; they are not a claim of 96 verified service adapters or complete application coverage.

Both skills obtain maintained consideration data from your vendor controller (VCtrl) through the public `tensor9` CLI and its normal vendor-profile authentication. The Python helper validates the exact versioned bytes and retains labelled cache or bundled fallback when compatible CLI/controller access is unavailable. It sends no application source and requires no imported workspace, private Tensor9 source or internal Kotlin environment. See [skill installation and catalog access](https://docs.tensor9.com/byoc/onboarding/agent-skills.md) for commands, compatibility limits and source provenance. Prepared documentation JSON remains a static reference, not the default refresh source; public guide and skill publication is still pending approval.

Catalog knowledge can identify a consideration. Your source evidence, product decision, reviewed change and application read-back establish what actually works.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.