FABRIC REST API Connections - Create Connection

Hi,

Here's a working body structure for SQL Server + Service Principal:

$body = @{

connectivityType = "ShareableCloud"

displayName = "SQL Server Connection"

connectionDetails = @{

type = "SQL"

creationMethod = "SQL"

parameters = @(

@{ dataType = "Text"; name = "server"; value = "yourserver.database.windows.net" },

@{ dataType = "Text"; name = "database"; value = "yourdatabase" }

)

}

privacyLevel = "Organizational"

credentialDetails = @{

credentialType = "ServicePrincipal"

credentials = @{

tenantId = "your-tenant-id"

servicePrincipalClientId = "your-client-id"

servicePrincipalSecret = "your-client-secret"

}

singleSignOnType = "None"

connectionEncryption = "Encrypted"

skipTestConnection = $false

}

} | ConvertTo-Json -Depth 10

Call it against api.fabric.microsoft.com directly, double check field casing against current docs since it's picky.

If this helped, feel free to give it a kudos or mark it as solution, helps others find it too.

Hi Charline_74​ ,

Could you review the suggestion provided above and let us know if you have any additional questions, we are happy to address. 

Thanks!!

I think there are two separate calls here. POST /v1/connections creates the SQL cloud connection; binding it to the semantic model uses bindConnection. For SP auth, put credentialType, tenantId, servicePrincipalClientId, and servicePrincipalSecret under credentialDetails.credentials. One catch: the bindConnection caller needs to own the semantic model.

The body structure looks right for a ShareableCloud SQL connection with Service Principal authentication.

A couple of things I’d verify:

• the service principal has access to the SQL source
• the app/service principal has the required Fabric permissions
• tenantId, servicePrincipalClientId, and secret are all valid
• ConvertTo-Json -Depth 10 is kept, otherwise nested credential objects may be truncated

For debugging, I’d also inspect the final JSON before the API call:

$body

If the request still fails, the HTTP response body from Invoke-PowerBIRestMethod should help identify whether the issue is authentication, permissions, or the connection payload itself.