canonical: https://jentic.com/apis/azure.com/azure-sql-database

# Microsoft Azure Azure SQL Database

Jentic publishes the only available OpenAPI specification for Azure SQL Database, keeping it validated and agent-ready. This 2014-04-01 surface scopes down to the checkNameAvailability operation under Microsoft.Sql, which validates whether a candidate Azure SQL server name is available within a subscription before provisioning. It is a focused control plane utility used as a precondition step in any Azure SQL server creation workflow.

## For AI agents

Check whether a candidate Azure SQL server name is available in a subscription before attempting to create the server, returning availability and the reason a name is unavailable.

## Scope

Does not handle SQL server creation, database CRUD, elastic pool management, or query execution - use for Microsoft.Sql server name availability validation only.

## Capabilities

- Validate that a proposed Azure SQL server name is available within a subscription
- Return the reason a candidate server name is unavailable (already exists or invalid)
- Use checkNameAvailability as a precondition before issuing a Microsoft.Sql server create
- Drive deterministic naming workflows that retry with a suffix when a name collides
- Integrate name validation into infrastructure-as-code pipelines that provision SQL servers

## Use cases

### Precondition Check Before SQL Server Creation

Call checkNameAvailability with a candidate server name before issuing the Microsoft.Sql server create operation, so the workflow fails fast on naming collisions rather than after the long-running provisioning request returns. The POST returns nameAvailable, reason, and message fields so the caller can choose between retrying with a suffix and surfacing the conflict to the user. This is a standard precondition step in Bicep, Terraform, and ARM template pipelines.

Example prompt: POST checkNameAvailability with name 'prod-sql-eus' and type 'Microsoft.Sql/servers' and return whether the name is available

### Deterministic Naming Retry Loop

When a candidate Azure SQL server name is taken, retry checkNameAvailability with progressively suffixed candidates ('prod-sql-eus-01', '-02', and so on) until a name returns nameAvailable=true. The single endpoint is cheap to call and idempotent, so a naming loop produces a deterministic outcome without burning long-running create operations. This pattern keeps automated environment bootstrappers from failing on cosmetic naming clashes.

Example prompt: Loop checkNameAvailability over candidates 'prod-sql-eus', 'prod-sql-eus-01', 'prod-sql-eus-02' and return the first one whose nameAvailable is true

### IaC Pipeline Validation Step

Integrate checkNameAvailability into a Terraform or Bicep pipeline as a pre-apply validation step so naming clashes surface in the plan output rather than during apply. The agent runs the call, parses nameAvailable and reason, and either annotates the plan or fails the build before any provisioning. This converts a class of late-stage failures into early, explicit pipeline errors.

Example prompt: Run checkNameAvailability for every Azure SQL server name in the Terraform plan and fail the build if any returns nameAvailable=false

### Agent-Driven Naming Validation via Jentic

An AI agent uses Jentic to validate Azure SQL server names as part of a broader provisioning chain. The agent searches Jentic for 'check azure sql server name availability', loads the schema, and executes the call before continuing to the actual create. Azure AD bearer tokens are sourced from your Jentic One instance per call, and the response is used to drive the next step in a deterministic state machine.

Example prompt: Search Jentic for 'check azure sql server name availability', execute checkNameAvailability for the requested name, and return the boolean availability and reason to the calling chain

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| POST | /subscriptions/{subscriptionId}/providers/Microsoft.Sql/checkNameAvailability | Check whether a candidate Azure SQL server name is available |

## Key resources

- **checkNameAvailability** — Validate that a candidate Azure SQL server name is available in a subscription before issuing a create.

## Why Jentic

- **Setup:** Wiring the Azure SQL checkNameAvailability API by hand means registering an Azure AD app for OAuth2 bearer auth against management.azure.com and constructing the Microsoft.Sql provider path before a single POST returns nameAvailable. Through Jentic you install once, import Azure SQL Database from the API Directory, store the Azure AD credential once, and your agent calls it.
- **Permission scoping:** This surface exposes a single POST to /providers/Microsoft.Sql/checkNameAvailability with the candidate name in the request body, so scope the agent to the operations it needs, such as the name-availability check, and nothing more. The check is read-only and provisions nothing, so it cannot create or delete a server on its own.
- **Credential handling:** Your Azure AD credential is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'check azure sql server name availability', and Jentic returns the matching Microsoft.Sql checkNameAvailability operation with its input schema so the agent supplies the candidate name and type without browsing the ARM reference.

## Related APIs

- **Azure SQL Database Backup Long Term Retention Policy** — Manages long-term retention policy on Azure SQL databases.
- **Azure SQL Database Datamasking Policies and Rules** — Manages dynamic data masking policies and rules on Azure SQL databases.
- **Azure SQL Database Disaster Recovery Configuration** — Manages disaster recovery configuration on Azure SQL databases.

## FAQ

### Why is there no official OpenAPI spec for Azure SQL Database?

Microsoft Azure does not publish an OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call Azure SQL Database via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer.

### What authentication does the Azure SQL Database checkNameAvailability API use?

The API uses Azure Active Directory OAuth 2.0 (the azure_auth scheme) with the user_impersonation scope on https://management.azure.com/. Through Jentic, the bearer token is fetched from your Jentic One instance and injected at call time so the agent never sees the raw client secret.

### Why does this Azure SQL Database surface only have one endpoint?

The 2014-04-01 spec on this slug is scoped to the checkNameAvailability operation under Microsoft.Sql. Server, database, elastic pool, and other Azure SQL operations are exposed via separate Microsoft.Sql APIs on later API versions, each with their own slug in the catalogue.

### What does the response from checkNameAvailability look like?

The POST returns nameAvailable (boolean), reason (one of AlreadyExists or Invalid when the name is unavailable), and a human-readable message. Parse nameAvailable to gate creation; use reason to decide between retry-with-suffix and surfacing a validation error to the user.

### How do I check an Azure SQL server name through Jentic?

Search Jentic for 'check azure sql server name availability', load the schema for POST /subscriptions/{subscriptionId}/providers/Microsoft.Sql/checkNameAvailability, supply the candidate name and type 'Microsoft.Sql/servers', and execute. Jentic injects the Azure AD bearer token automatically.

### Is the Azure SQL Database checkNameAvailability API free?

Yes - control plane calls to checkNameAvailability are free. You only pay when an actual SQL server, database, or elastic pool is provisioned via the broader Microsoft.Sql APIs.

### Can I limit what my agent is allowed to do with the Azure SQL Database API?

Yes. Because you run Jentic One yourself, your own rules decide which operations and credentials the agent may use, so you can scope it to just the checkNameAvailability check under Microsoft.Sql and nothing else. That operation is a single read-only POST that validates whether a candidate Azure SQL server name is available in a subscription, so it provisions nothing and cannot create or delete a server on its own. You store the Azure AD credential once in your own instance, and it is injected at call time rather than exposed to the agent.