Third-party integration dependencies ​

A Coordinator DB integration may rely on an HTTP library, a data-format reader or an application connection abstraction. Review those dependencies through the public contract they must preserve: requests, authentication, typed values, errors and cleanup.

Explain what the dependency does ​

State which part of the adapter needs it and why an existing application dependency does not cover that behavior. Record its version and relevant distribution terms. Keep credentials out of diagnostic logging and make connection ownership explicit.

For an HTTP client, verify that it sends the SQL body and Content-Length correctly, retains response headers and exposes non-success status codes. For a format reader, test its handling of nulls, column names, numeric limits and an incomplete input fixture.

Check compatibility rather than names ​

A dependency that supports another SQL database is not automatically a Coordinator DB native client. The native interface uses its own protocol. Use the supplied client or the documented HTTP interface for the selected integration boundary.

Include a small reproducible test and explain how callers receive errors. Document configuration defaults and any format restrictions in the integration guide, so users can assess the dependency through actual behavior.