# Integration code style

Integration examples should make the connection and its ownership easy to see. Use the host application's existing conventions, descriptive names and small functions whose error paths can be read beside their successful paths.

## Keep data and SQL distinct

Use a documented parameter-binding API where one is available. The [prepared-statement guide](https://coordinatordb.com/docs/guides/clickhouse/data-modelling/stored-procedures-and-prepared-statements) describes positional values for embedded applications. The ordinary CLI and HTTP options do not provide that binding interface; examples must not present string interpolation as equivalent parameter binding.

Choose explicit columns and a result format appropriate for the caller. Use `ORDER BY` when the example promises an order. Describe what a function returns when a query produces no rows, a nullable field or an error.

## Make lifetime visible

Keep a transaction's related statements together. A native connection retains state, while each HTTP request owns its session. Return or close resources through the application's normal cleanup mechanism, including failure paths.

Use sample credentials only in the documented local configuration. Avoid logging authentication headers or real query values. A short example should still show how the caller detects failure; see [integration testing](https://coordinatordb.com/docs/resources/develop-contribute/integrations/testing-your-integration) for the cases its documentation should support.