# Integrate the embedded API

An embedded integration opens a database connection directly instead of sending SQL to a server. Define who owns that connection, where its database file lives and when it is closed. Use an in-memory connection for examples that do not need persistence.

## Bind values through the API

The public API provides `Connection::open(path)` and `Connection::open_in_memory()`. A prepared statement separates SQL from positional values. Use `prepare`, then the documented `execute_prepared` or `query_prepared` operation with the appropriate values. Missing bindings are errors.

The [prepared-statement example](https://coordinatordb.com/docs/guides/clickhouse/data-modelling/stored-procedures-and-prepared-statements) shows the complete binding and result contract. Document the adapter's conversion between database values and application values, especially nulls and integer boundaries.

## Respect the connection boundary

An embedded connection does not expose server commands such as `USE`, `SHOW` and `SET`, or the server's format encoders. Several connections in one process can share a file; simultaneous access from separate processes is outside the supported concurrency model.

Use one server when multiple application processes need shared access. Verify rollback on failure and reopen the file when testing persistence. See [deployment modes](https://coordinatordb.com/docs/get-started/about/deployment-modes) for selecting the boundary and [transactions](https://coordinatordb.com/docs/concepts/features/operations/insert/transactions) for SQL transaction controls.