Microsoft Azure Azure SQL Database

Name: Azure SQL Database API
Brand: Azure SQL Database
Availability: InStock

★ Only Publicly Available OpenAPI DocumentStorageDatabaseoauth21 EndpointsREST

For 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.

Install Jentic One Beta

Connect the Azure SQL Database to your agent

Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Azure SQL Database, or any other public or private API you need. You set the rules, the agent never sees your credentials, and every call is logged.

Two steps, two machines. Install the instance in a safe environment, then register your agent from wherever it runs.

Step 1: Jentic One Host machine

# On the machine that will host your Jentic One instance:
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh

Step 2: Agent machine

# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh
jentic register       # connects your agent to your Jentic One instance

Jentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.

Capabilities

What an agent can do with Azure SQL Database API.

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

GET STARTED

Start building with Azure SQL Database API

Explore with Jentic

View OpenAPI Document

Use Cases

Patterns agents use Azure SQL Database API for, with concrete tasks.

★ 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.

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.

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.

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 the Jentic vault per call, and the response is used to drive the next step in a deterministic state machine.

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

1 endpoints — jentic publishes the only available openapi specification for azure sql database, keeping it validated and agent-ready.

METHOD

PATH

DESCRIPTION

POST

/subscriptions/{subscriptionId}/providers/Microsoft.Sql/checkNameAvailability

Check whether a candidate Azure SQL server name is available

POST

/subscriptions/{subscriptionId}/providers/Microsoft.Sql/checkNameAvailability

Check whether a candidate Azure SQL server name is available

Why Jentic?

Three things that make agents converge on Jentic-routed access.

Credential isolation

Azure AD client credentials are stored encrypted in the Jentic vault. A short-lived bearer token scoped to https://management.azure.com/ is fetched per call; raw client secrets and refresh tokens never reach the agent context.

Intent-based discovery

Agents search Jentic by intent (e.g., 'check azure sql server name availability') and receive the matching Microsoft.Sql operation with its full input schema so the agent calls the right endpoint without browsing the ARM reference.

Time to first call

Direct integration: a few hours for ARM auth and a single POST. Through Jentic: minutes from search to first successful call.

FAQs

Specific to using Azure SQL Database API through Jentic.

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 at https://app.jentic.com/sign-up.

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 the Jentic vault 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.