Does getDefinition support DirectLake semantic models?

[jaryszek]

Hi,

I'm using the Fabric REST API to retrieve a semantic model definition:

POST /v1/workspaces/{workspaceId}/semanticModels/{semanticModelId}/getDefinition

This works for Import models, but I'm unsure about DirectLake semantic models.

Does getDefinition fully support DirectLake models?
Has anyone successfully retrieved the definition (TMDL) for a DirectLake semantic model using this API?

Thanks!

[jaryszek]

Has anyone had a similar case and can confirm based on real experience, not docs? 

Best,
Jacek

[v-tejrama]

Hi @jaryszek ,

Thank you for reviewing this and sharing your test results. The behavior you observed has also been reported by others in the community. When a long-running operation completes successfully, the getDefinition endpoint may still return a null definition for semantic models using DirectLake over OneLake.
This differs from Import or DirectQuery models, where the TMDL definition is typically available after the operation finishes. Based on your results, there does not appear to be an issue with your API call rather, it is related to how the REST endpoint handles definitions for this storage configuration. Currently, there are few confirmed cases of the API returning a populated TMDL definition for DirectLake over OneLake models, so your experience aligns with existing feedback.
As a workaround, some users retrieve metadata through the XMLA endpoint or tools like Tabular Editor, which can script the semantic model even if the REST API returns a null definition. If anyone has successfully obtained a populated result for DirectLake models using this endpoint, their insights would be valuable.

Thank you.

[jaryszek]

Thanks, 

"Currently, there are few confirmed cases of the API returning a populated TMDL definition for DirectLake over OneLake models" do you nkow what is different in those models where definition is there than others? 

[v-tejrama]

Hi @jaryszek ,

Thank you for your follow-up question and for providing additional context. Based on the scenario and the discussion in the thread, the behavior you are seeing is linked to the semantic model type. The getDefinition REST API returns the semantic model definition in TMDL format via a long-running operation, which is consistent for models with fully materialized definitions.

In your situation, the semantic model uses DirectLake over OneLake, operating directly on Delta tables in OneLake, rather than relying on a fully imported storage layer. Due to this architecture, the REST API may complete successfully but return a null definition payload for DirectLake models.

This outcome does not indicate an issue with your API call or polling logic it is a reflection of how metadata for DirectLake semantic models is currently exposed. For inspecting or scripting the semantic model structure, connecting through the XMLA endpoint with tools like Tabular Editor or SQL Server Management Studio is recommended, as these tools access the metadata layer directly, even when the REST API does not provide the full model definition.

Thank you.
Tejaswi.

[jaryszek]

Thank you  but this is still does not explain why for some people getDefinition is returning null, for some not. 

Best,
Jacek

[v-tejrama]

Hi @jaryszek ,

The main point is that there is no documented model-level setting that controls whether getDefinition returns a populated TMDL or null for DirectLake over OneLake semantic models. The REST API provides a definition only if a fully serialized semantic model definition is present in the service. In many DirectLake scenarios, the model structure is generated dynamically from OneLake Delta metadata rather than stored as a separate serialized artifact, which explains why the API may return null.

If a model was created or deployed using workflows that produce a complete tabular model definition, such as XMLA scripting or TMDL deployments, the service may have a serialized definition for the API to return. Due to this architectural difference, the behavior can vary between models using DirectLake, resulting in some users receiving a definition while others receive null.

Thank you.

[jaryszek]

Ok thank you, 

still have questions:

1. the exact deterministic rule for predicting which DirectLake model will return null
2. whether Microsoft considers this expected permanent behavior or a limitation/bug
3. how to force a DirectLake model to always have a serialized definition

Thank you,
Jacek

[v-tejrama]

Hi @jaryszek ,

Thank you for sharing these questions. Based on the current behavior of the Fabric REST APIs and Microsoft documentation, there is no documented rule to determine which DirectLake semantic models will return a populated definition or a null result when using the getDefinition endpoint. The API provides a definition only if a serialized semantic model definition exists in the service. In DirectLake scenarios, especially when models are built directly on OneLake tables, some metadata may be dynamically resolved from lake metadata rather than being fully stored as a serialized artifact. This can cause the API to return a null definition, even though the model operates as intended.

Microsoft documentation does not list this as a product bug it is considered a limitation of REST API coverage for certain DirectLake cases. While additional API features may be introduced as the product develops, there is currently no assurance that DirectLake semantic models will always return a serialized definition through this endpoint.

To reliably retrieve or script the semantic model structure, it is advised to use the XMLA endpoint with tools like Tabular Editor or SQL Server Management Studio, which can access model metadata even if the REST API returns a null definition.

Thank you.

[v-tejrama]

Hi @jaryszek ,

I wanted to follow up and see if you had a chance to review the information shared. If you have any further questions or need additional assistance, feel free to reach out.

Thank you.

[jaryszek]

thank you @AmosHersch @v-tejrama 

Are you sure that DiretLake over OneLake after the result of LRO will have something?

In my case it was always null. 
Can you pleasecheck the scenario in your case? 

Best,
Jacek 

[v-tejrama]

Hi @jaryszek ,

Based on your summary, the original poster is seeking confirmation on whether the Fabric REST API endpoint used to retrieve a semantic model definition works for DirectLake semantic models, in addition to Import mode models. They are already using the API endpoint successfully with Import mode and are uncertain if it supports DirectLake models, specifically for retrieving the TMDL definition. Currently, there is no Super User response in the thread addressing this question, so there is no answer to validate, and the correct status remains None 0%.

According to Microsoft documentation, the getDefinition API is intended to return the public definition of a semantic model item, regardless of the storage mode DirectLake, Import, or DirectQuery. The API retrieves the definition as long as the model exists in the workspace and the user has the necessary permissions. The storage mode does not affect the endpoint’s functionality. This is supported by the Fabric REST API documentation, which confirms that the endpoint returns the semantic model definition for the specified item.

A suitable forum response would be: Yes, the getDefinition endpoint is compatible with DirectLake semantic models. The API retrieves the definition of the semantic model item itself, and the storage mode does not impact this process. Provided you have the necessary permissions and the model exists in the workspace, the API will return the model definition in TMDL format. Any issues encountered are typically related to permissions or the type of semantic model item, rather than the DirectLake storage mode.


Thank you.

[jaryszek]

thank you, 

I tested it and got null as an answer (202). So it means that DirectLAke over OneLake is not working with this rest api. Any alternatives?

Best,
Jacek

[v-tejrama]

Hi @jaryszek ,

Receiving a 202 response from the getDefinition API does not mean that DirectLake semantic models are unsupported. In the Fabric REST API, this endpoint works as a long-running operation. A 202 Accepted response indicates that the request has been received and processing has started, but the definition is not yet ready, so the response body may be empty at this point.

The usual process is to use the operation details provided in the response headers, like the operation ID or location, and then check the operation status endpoint. Once the operation completes, you can retrieve the result, which will include the semantic model definition in TMDL format. This process is the same for Import, DirectQuery, or DirectLake storage modes.

The official documentation for the Fabric REST API Get Semantic Model Definition and the general guidance on long-running operations confirm that a 202 response means processing is underway and clients should poll the operation endpoint for the result.

Therefore, DirectLake over OneLake is not blocked by the API. The important step is to follow the long-running operation pattern after receiving the 202 response, rather than expecting the definition immediately. By doing this, you can retrieve the TMDL for the semantic model.

Thank you.

[AmosHersch]

@jaryszek If you got 202 (Accepted) it doesn't mean it is not working. See here how to get the result of a long running operation in Fabric APIs
Long running operations - Microsoft Fabric REST APIs | Microsoft Learn