# Automate Coordinator DB SQL over HTTP

Coordinator DB provides an HTTP SQL interface rather than a hosted-service management API. Use `POST /` for SQL and `GET /ping` for an unauthenticated readiness check. Infrastructure provisioning, account billing and service lifecycle operations belong to your deployment tools.

```sh
curl --fail-with-body --silent \
  --user "$COORDINATOR_USER:$COORDINATOR_PASSWORD" \
  --data-binary 'SELECT 1 AS value FORMAT json_each_row' \
  'http://127.0.0.1:7401/?database=data'
```

## Handle the response deliberately

Check the HTTP status before treating the body as query output. Capture `X-Coordinator-Query-Id` when diagnosing a failure. SQL errors usually return 400, invalid credentials return 401 and admission failures can return 503. Never turn every failure into an unconditional retry of a write.

The accepted URL parameters are `query`, `database`, `default_format` and `result_limit`. Passwords and API keys are not accepted in URL parameters. Duplicate or unknown parameters are errors.

Each HTTP request has a separate session. Put all transaction statements into one request and commit before it ends. Responses are buffered, bound parameters and persistent HTTP sessions are unsupported, and a client must escape application values safely rather than concatenate untrusted text.

See [HTTP request contract](https://coordinatordb.com/docs/concepts/features/interfaces/http) and [transactions](https://coordinatordb.com/docs/concepts/features/operations/insert/transactions).