Module 12
End-to-End Project
Microsoft Fabric REST API
Module 12 · Lesson 12.1
Source Systems
Module 12 · Lesson 12.2
SQL Server
Module 12 · Lesson 12.3
Azure Blob
Module 12 · Lesson 12.4
REST API
Microsoft Fabric REST API
In Microsoft Fabric, a REST API allows you to manage and automate Fabric resources programmatically instead of manually clicking through the Fabric portal.
For your current topic—Azure DevOps + DEV → TEST → PROD deployment—REST APIs become especially useful for CI/CD automation.
REST API = Send an HTTP request to Fabric → Fabric performs an operation → returns a response
1. Why do we need REST APIs in Fabric?
Imagine you have:
Fabric-DEV
Fabric-TEST
Fabric-PROD
Without automation:
Developer
↓
Open Fabric Portal
↓
Select Deployment Pipeline
↓
Deploy DEV → TEST
↓
Wait
↓
Validate
↓
Deploy TEST → PROD
This works, but it involves manual operations.
With APIs:
Developer
↓
Azure DevOps
↓
CI/CD Pipeline
↓
Fabric REST API
↓
Deploy / Manage Fabric
↓
TEST
↓
Approval
↓
PROD
This is where REST APIs become powerful.
2. What does REST mean?
REST stands for:
Representational State Transfer
You don't need to focus heavily on the full form.
For Fabric, think:
Client
↓
HTTP Request
↓
Fabric REST API
↓
Fabric Service
↓
HTTP Response
The client could be:
Python
PowerShell
Azure DevOps
Postman
Custom application
Automation script
3. Simple REST API example
Suppose you want to get Fabric workspaces.
Conceptually you send:
GET /workspaces
Fabric returns information about the workspaces the authenticated identity can access.
For example:
{
"value": [
{
"id": "workspace-id-1",
"displayName": "Fabric-DEV"
},
{
"id": "workspace-id-2",
"displayName": "Fabric-TEST"
}
]
}
Now your automation knows which workspaces exist.
4. REST API architecture
Think of Fabric APIs like this:
Your Automation
│
┌─────────┼─────────┐
▼ ▼ ▼
Python PowerShell Azure
DevOps
│
▼
REST REQUEST
│
▼
Microsoft Fabric API
│
┌─────────────┼──────────────┐
▼ ▼ ▼
Workspaces Items Deployment
Pipelines
5. HTTP methods
REST APIs commonly use these methods:
| Method | Meaning |
|---|---|
| GET | Read/get information |
| POST | Create or start something |
| PUT | Create/replace/update |
| PATCH | Partially update |
| DELETE | Delete |
Easy way to remember:
GET
↓
Give me something
POST
↓
Create/start something
PATCH/PUT
↓
Change something
DELETE
↓
Remove something
6. GET example
Suppose:
"Give me my Fabric workspaces."
GET /workspaces
Conceptually:
Azure DevOps
↓
GET Workspaces
↓
Fabric API
↓
Workspace List
7. POST example
Suppose you want an API operation to create or initiate something.
Conceptually:
POST /some-resource
with a body:
{
"displayName": "Fabric-TEST"
}
Think:
POST
↓
Request operation
↓
Fabric performs operation
↓
Response
The exact endpoint and body depend on the Fabric API you're using.
8. DELETE example
Conceptually:
DELETE /workspaces/{workspaceId}/items/{itemId}
means:
Delete a particular Fabric item.
Obviously, production automation needs strict permissions and safeguards around destructive operations.
9. API endpoint
Microsoft Fabric REST APIs use a base endpoint such as:
https://api.fabric.microsoft.com/v1/
For example, the Workspaces API is documented under the Fabric REST API reference.
Microsoft Fabric REST API documentation
Conceptually:
Base URL
https://api.fabric.microsoft.com/v1
+
Resource
↓
workspaces
giving:
/v1/workspaces
10. Important concept: IDs
REST APIs generally work with IDs rather than just display names.
For example:
Fabric-DEV
has a Workspace ID:
Fabric-DEV
↓
Workspace ID
↓
xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Similarly:
Workspace
↓
Workspace ID
Notebook
↓
Item ID
Pipeline
↓
Item ID
Deployment Pipeline
↓
Pipeline ID
You'll see IDs frequently when working with Fabric APIs.
11. Where can I find Workspace ID?
One approach is to query the API.
GET /v1/workspaces
Conceptually:
{
"value": [
{
"id": "11111111-2222-3333-4444-555555555555",
"displayName": "Fabric-DEV"
}
]
}
Your automation can locate:
displayName = Fabric-DEV
and retrieve:
id
12. Authentication
This is one of the most important REST API concepts.
Fabric doesn't simply allow:
Unknown User
↓
REST API
↓
Production Workspace
The caller must authenticate and be authorized.
Conceptually:
Azure DevOps
↓
Authentication
↓
Microsoft Entra ID
↓
Access Token
↓
Fabric REST API
13. Access token
An access token effectively tells the service:
"This request comes from an authenticated identity."
The API request commonly contains:
Authorization: Bearer <access-token>
Conceptually:
Request │ ├── URL ├── HTTP Method ├── Headers │ └── Authorization └── Body
14. Don't hardcode tokens
Never do this in a repository:
token = "eyJxxxxxxxxxxxxxxxx"
and commit it.
Tokens and secrets should be handled securely.
For automated CI/CD, you might use:
Azure DevOps
↓
Secure Identity / Credentials
↓
Microsoft Entra ID
↓
Access Token
↓
Fabric
15. Service Principal
For Azure DevOps automation, you'll often encounter the service principal concept.
Instead of:
Sreehari
↓
Login
↓
Deploy PROD
automation can use:
Azure DevOps
↓
Service Principal
↓
Microsoft Entra ID
↓
Fabric
A service principal is an application identity used by automation.
16. Why not use a personal account?
Imagine an employee leaves the company.
If production deployment depends on:
employee@company.com
then deployment can break when their account is disabled.
Better:
Azure DevOps Pipeline
↓
Controlled workload identity
↓
Fabric
This makes the process less dependent on one individual.
17. API request structure
A REST API request usually consists of:
REST Request │ ├── Method │ GET / POST / DELETE / ... │ ├── URL │ │ ├── Headers │ Authorization │ Content-Type │ └── Body
JSON
Example:
POST /some-resource
Authorization: Bearer <token>
Content-Type: application/json
Body:
{
"displayName": "Example"
}
18. Response
The server responds with an HTTP status code and, often, a body.
For example:
200
generally means:
OK
Other common codes:
| Code | Meaning |
|---|---|
| 200 | Success |
| 201 | Created |
| 202 | Accepted / processing |
| 400 | Bad request |
| 401 | Authentication problem |
| 403 | Permission denied |
| 404 | Resource not found |
| 409 | Conflict |
| 429 | Too many requests |
| 500 | Server error |
These are very useful during troubleshooting.
19. 401 vs 403
A very common interview question.
401
401 Unauthorized
Usually think:
Authentication issue
For example, token missing/invalid/expired.
403
403 Forbidden
Usually think:
Authenticated, but not allowed to perform the operation.
For example:
Identity
↓
Valid token ✓
↓
No required permission ✕
20. Fabric API resource hierarchy
Conceptually:
Fabric │ ├── Workspaces │ │ │ └── Items │ │ │ ├── Notebooks │ ├── Pipelines │ ├── Lakehouses │ ├── Warehouses │ └── Other supported items │ └── Deployment Pipelines
Therefore API operations frequently need:
Workspace ID
Item ID
Deployment Pipeline ID
21. Get workspace items
A common pattern is:
GET /v1/workspaces/{workspaceId}/items
Conceptually:
Fabric-DEV
↓
Workspace ID
↓
GET Items
↓
Notebook
Pipeline
Lakehouse
Warehouse
...
Fabric Items REST API reference
22. Python example
A simplified Python request might look like:
import requests
url = "https://api.fabric.microsoft.com/v1/workspaces"
headers = {
"Authorization": f"Bearer {access_token}"
}
response = requests.get(
url,
headers=headers
)
print(response.status_code) print(response.json())
Flow:
Python
↓
GET
↓
Fabric REST API
↓
JSON Response
23. JSON
REST APIs frequently send and receive JSON.
JSON example:
{
"displayName": "Fabric-DEV",
"description": "Development workspace"
}
Think:
JSON
=
Structured key/value data
If you already work with ADF/Synapse pipeline JSON, this concept should feel familiar.
24. PowerShell example
Fabric APIs can also be called from PowerShell.
Conceptually:
Invoke-RestMethod `
-Uri $url `
-Method GET `
-Headers $headers
Therefore:
Azure DevOps
↓
PowerShell
↓
REST API
↓
Fabric
is a valid automation pattern.
25. REST API + Azure DevOps
Now connect this to your previous topic.
Your architecture becomes:
Developer
↓
Fabric DEV
↓
Git
↓
Azure DevOps Repo
↓
Pull Request
↓
Merge
↓
Azure Pipeline
↓
Fabric REST API
↓
Fabric TEST
↓
Testing
↓
Approval
↓
Fabric REST API
↓
Fabric PROD
This is why REST APIs matter for 11.6 Deploy Across Workspaces.
26. Native deployment vs API automation
Manual/native approach
Fabric DEV
↓
Deployment Pipeline
↓
Click Deploy
↓
TEST
Good when learning or when deployments are relatively simple.
Automated approach
Git Merge
↓
Azure Pipeline
↓
REST API / CI-CD tooling
↓
TEST
↓
Automated Validation
↓
Approval
↓
PROD
Better suited to mature enterprise CI/CD.
27. Deployment Pipeline APIs
Fabric exposes REST APIs for deployment pipelines.
Fabric Deployment Pipelines REST API
Conceptually:
REST API │ ├── Get Deployment Pipelines ├── Create Deployment Pipeline ├── Get Pipeline ├── Manage stages └── Perform supported deployment operations
This enables programmatic control over deployment processes.
28. Example deployment automation
Suppose:
Pipeline:
EDW-Deployment
Stages:
DEV
TEST
PROD
Azure DevOps can conceptually do:
Step 1
Authenticate
↓
Step 2
Get Deployment Pipeline
↓
Step 3
Deploy DEV → TEST
↓
Step 4
Check deployment status
↓
Step 5
Run validation
↓
Step 6
Approval
↓
Step 7
Deploy TEST → PROD
That's CI/CD automation.
29. Long-running operations
Some Fabric operations aren't instantaneous.
For example:
Azure DevOps
↓
POST Deployment
↓
Fabric
↓
202 Accepted
That can mean:
"I accepted the request, but the operation is still running."
The automation may need to:
Start operation
↓
Receive operation reference
↓
Check status
↓
Running...
↓
Check again
↓
Succeeded / Failed
This pattern is known as a long-running operation.
30. Why this matters for Azure DevOps
Don't write automation that assumes:
POST
↓
Immediately finished
↓
Deploy PROD
Instead:
POST deployment
↓
Wait / poll status
↓
Succeeded?
│ ┌──┴──┐ YES NO │ │ ▼ ▼
Tests Fail Pipeline
Then continue only when the operation succeeds.
31. Error handling
Production automation needs proper error handling.
For example:
Call API
↓
Status?
│ ├── 200 → Continue │ ├── 202 → Monitor operation │ ├── 401 → Authentication issue │ ├── 403 → Permission issue │ ├── 404 → Check IDs/resource │ ├── 429 → Retry appropriately │ └── 5xx → Handle service failure
Don't simply write:
requests.post(...)
and assume everything succeeded.
32. Logging API deployments
Every production deployment should generate useful logs.
For example:
2026-08-03 09:00
Deployment Started
Environment:
TEST
Commit:
abc123
Workspace:
EDW-Fabric-TEST
Status:
Running
Then:
09:04
Deployment Completed
Status:
Succeeded
This gives you:
Who
What
When
Which version
Which environment
Result
33. Secrets
Your Azure DevOps repository should never contain:
client_secret = "xxxxx" password = "xxxxx" access_token = "xxxxx"
Instead:
Azure DevOps
↓
Secure Variable / Variable Group
↓
Secret Management
or an appropriate Azure secret store/identity-based authentication mechanism.
The key rule:
Code belongs in Git. Secrets don't.
34. REST API vs fabric-cicd
From the previous lesson, you saw Microsoft's fabric-cicd package.
Think:
Fabric
▲
│
REST APIs
▲
│
┌───────┴───────┐
│ │
Your Code fabric-cicd
With raw REST APIs:
You manage:
Authentication
Endpoints
Request bodies
Responses
Polling
Errors
Deployment logic
With a higher-level CI/CD library:
Library
↓
Simplifies common deployment operations
↓
REST APIs underneath
For learning Fabric APIs, understanding REST first is valuable.
For production CI/CD, higher-level supported tooling can reduce custom code.
35. REST API vs Git
Don't confuse these.
Git
Git
↓
Store versions
Track changes
Branches
Pull Requests
REST API
REST API
↓
Perform operations
Create resources
Retrieve information
Update resources
Automate deployments
Together:
Git
↓
Approved Version
↓
Azure DevOps Pipeline
↓
REST API
↓
Fabric Environment
36. REST API vs Deployment Pipeline
Again, different responsibilities.
Deployment Pipeline
↓
Fabric lifecycle concept
DEV → TEST → PROD
REST API:
REST API
↓
Programmatically tell Fabric
to perform operations
You can use APIs to automate supported deployment pipeline operations.
37. Complete CI/CD architecture
This is the diagram I'd recommend remembering:
DEVELOPER
│
▼
FABRIC DEV
│
▼
Git Integration
│
▼
AZURE DEVOPS REPO
│
▼
FEATURE BRANCH
│
▼
PULL REQUEST
│
▼
REVIEW
│
▼
MAIN
│
▼
AZURE PIPELINE
│
▼
AUTHENTICATION
│
▼
FABRIC REST API
│
▼
FABRIC TEST
│
▼
AUTOMATED TESTS
│
▼
UAT / APPROVAL
│
▼
FABRIC REST API
│
▼
FABRIC PROD
│
▼
MONITORING
38. Real project example
Suppose your Fabric project contains:
EDW-Fabric-DEV │ ├── LH_EDW ├── WH_EDW ├── PL_Load_Customer ├── PL_Load_Sales ├── NB_Customer ├── NB_Sales ├── Semantic Model └── Reports
Developer modifies:
NB_Sales
Release:
NB_Sales changed
↓
Commit
↓
Azure Repo
↓
Pull Request
↓
Review
↓
Merge
↓
Azure Pipeline
↓
Authenticate
↓
Fabric API / CI-CD tooling
↓
Deploy TEST
↓
Validate
↓
Approval
↓
Deploy PROD
↓
Monitor
39. Interview question — What is Microsoft Fabric REST API?
A good answer:
Microsoft Fabric REST APIs provide programmatic access to manage and automate Fabric resources and operations. They can be used from tools such as Python, PowerShell and Azure DevOps to manage workspaces and items and to automate supported CI/CD and deployment operations.
40. Interview question — How do you authenticate?
Fabric REST API requests are authenticated through Microsoft Entra ID. The client obtains an access token for an authorized identity and sends it in the Authorization Bearer header. For CI/CD, I prefer a supported workload identity such as a service principal rather than depending on a developer's personal account.
41. Interview question — What is the difference between 401 and 403?
401 generally indicates that the request isn't properly authenticated—for example, the token is invalid or missing. 403 means the identity is authenticated but doesn't have sufficient authorization to perform the requested operation.
42. Interview question — How would you use REST APIs with Azure DevOps?
I would trigger an Azure DevOps pipeline after approved code is merged. The pipeline authenticates to Microsoft Entra ID using a controlled workload identity and then calls Fabric REST APIs or supported CI/CD tooling to deploy or manage Fabric resources in TEST. After automated testing and approval, the same controlled process promotes the approved version to PROD.
43. Interview question — Why REST API instead of manual deployment?
REST APIs provide repeatable automation. They reduce manual deployment steps and make it easier to integrate Fabric with Azure DevOps CI/CD, automated validation, logging, approvals and consistent environment promotion.
44. Interview question — What is a long-running operation?
Some Fabric API operations don't complete immediately. The API can accept the request and return an operation reference, after which the client monitors the operation until it succeeds or fails before proceeding to the next deployment step.
45. REST API quick cheat sheet
GET
↓
Read
POST
↓
Create / Start
PUT / PATCH
↓
Update
DELETE
↓
Remove
And:
200 → Success
201 → Created
202 → Accepted / Processing
400 → Bad Request
401 → Authentication
403 → Authorization
404 → Not Found
429 → Too Many Requests
500 → Server Error
46. Complete Fabric deployment picture
Your last few topics now connect:
MICROSOFT FABRIC
│
▼
FABRIC DEV
│
Develop/Test
│
▼
GIT INTEGRATION
│
▼
AZURE DEVOPS
│
┌──────┴──────┐
▼ ▼
Repos Pipelines
│ │
▼ ▼
Versioning Automation
│ │
└──────┬──────┘
▼
REST API
│
▼
FABRIC TEST
│
Validation
│
Approval
│
▼
REST API
│
▼
FABRIC PROD
│
▼
MONITOR
The simplest way to remember it
Git stores the version. Azure DevOps controls the workflow. REST API performs automated Fabric operations. Deployment moves the approved solution from DEV → TEST → PROD.
For interviews, remember this one sentence:
“In a Fabric CI/CD solution, I use Azure DevOps Git for source control and pull requests, then Azure Pipelines with authenticated Fabric REST API or Fabric CI/CD tooling to automate deployment from DEV to TEST and PROD with testing, approvals, and monitoring.”
↑ Back to topModule 12 · Lesson 12.5
Module 12 · Lesson 12.6
Hands on Implement
Module 12 · Lesson 12.6
Incremental Loading
Module 12 · Lesson 12.7
SCD Type 1 & Type 2
Module 12 · Lesson 12.8
Logging
Module 12 · Lesson 12.9
Error Handling
Module 12 · Lesson 12.10
Monitoring
Module 12 · Lesson 12.11
Git Integration
Module 12 · Lesson 12.12
Deployment Pipeline
Module 12 · Lesson 12.13