The Strategic Need for an API Bridge
In a modern enterprise, SAP Datasphere acts as the "Single Source of Truth." However, the data stored there often needs to be consumed by diverse downstream consumers: from custom Python-based AI models and React web applications to third-party reporting engines.
The challenge isn't just "getting the data out"—it’s doing so securely and efficiently. Relying on manual exports or basic authentication creates security risks and operational bottlenecks. By architecting an API Bridge using Postman, I created a standardized, automated, and OAuth 2.0-secured gateway. This allows us to move away from "one-off" data pulls and toward a professional Data-as-a-Service (DaaS) model where any authorized application can consume real-time SAP data on demand.
The blog is divided into 5 parts:
- Part 1: The Data Foundation (Datasphere - Data Builder)
Part 2: Security & Identity—The OAuth 2.0 Client
Part 3: The Connection (Postman Strategy)
Option 1: The Manual Approach (Standard)
Option 2: The Automated Approach (Professional)
Part 4: Real-Time Data Validation (The Visualizer)
Part 5: The End Goal—Exporting for Downstream Apps
Part 1: The Data Foundation (Datasphere - Data Builder)
Before an API can "see" your data, it must be properly modeled and exposed. For this setup, I used a dataset of Amazon Bestselling Books.
Why use a Graphical View instead of a Table?
While you can expose a raw table, a Graphical View is the professional choice. It acts as a "Virtual Layer" where you can:
- Filter Data: Exclude old records so the API doesn't get overloaded.
- Rename Fields: Change technical headers (like PUB_YR) to business-friendly names (like Publication_Year).
- Calculations: Add new columns (like Profit_Margin) directly in the view.
Step-by-Step:
- Import: Upload your CSV/Table into the Data Builder.
- Create View: Drag the table into a new Graphical View.
- Semantic Usage: Set this to Relational Dataset (this is mandatory for OData access).
- Expose for Consumption: Toggle this ON. This is the most critical step; it tells Datasphere to generate a URL for external tools.
- Deploy: Click the "Save and Deploy" icon.
In the SAP Datasphere Data Builder, ensure your Graphical View is set to 'Relational Dataset' and that 'Expose for Consumption' is toggled ON. A successful deployment (indicated by the green checkmark) is required for the OData service to become reachable.
Click on “Generate OData Request” and copy the OData Request URL, which will be needed later during Postman request setup.
Part 2: Security & Identity—The OAuth 2.0 Client
To allow Postman to talk to SAP Datasphere, avoid using personal login credentials. Instead, create an OAuth 2.0 Client. This acts as a "Technical User" that is secure, scoped, and easy to manage.
Step 1: Navigate to App Integration
Go to System > Administration > App Integration tab.
Step 2: Create the Technical User
Click on "Add an OAuth Client". In the configuration window:
- Provide a Name (e.g., POC_Technical_User).
- Set the Authorization Grant to Client Credentials.
- Important: Copy your Secret immediately and save it safely; you won't be able to see it again!
Step 3: The "403" Safeguard (Role Assignment)
This is the most critical technical step. The API will return a 403 Forbidden error unless permissions are set. Click Select Roles and assign Scoped Data Warehouse Cloud Viewer and Scoped Data Warehouse Cloud Modeler as optional.
Step 4: Note your Endpoints
Once saved, your new client will appear in the Configured Clients list. Make sure to note down the Authorization URL and Token URL shown at the top of the screen. You will need these for your Postman Environment.
Part 3: The Connection (Postman Strategy)
Now that our SAP Datasphere "Bridge" is built and secured, we need to cross it using Postman. There are two ways to handle the OAuth 2.0 handshake.
Option 1: The Manual Approach (Standard)
While automation is our ultimate goal, establishing a manual connection first is a critical diagnostic step. This ensures that your SAP Datasphere credentials and roles are configured correctly before we add the complexity of scripting. This is the "out-of-the-box" method. It is great for a quick one-time test, but it has a significant drawback: Tokens expire.
Detailed Steps:
Step 1: Configure the Request
In Postman, create a new GET request using your Datasphere OData URL. Navigate to the Authorization tab and select OAuth 2.0. Fill in the "Configure New Token" section using the Client ID and Secret we generated in Part 2.
Use the URL from Part 1. from Datasphere View in the https section.
Once you complete Step 2 and Step 3 below, the Token name (Yellow Highlighted) will pop up based on the token name you provided during the "Configure New Token" step.
Step 2: Authenticate with SAP
Scroll down and click "Get New Access Token". If your credentials are correct, you will see a green checkmark indicating that the authentication handshake was successful.
Step 3: Commit the Token
Once authenticated, Postman stores the token in its local manager. You must click "Use Token" to link this specific string to your current request headers.
Headers: Go to the Headers tab. You must add the key x-sap-sac-custom-auth with the value true. This tells the SAP gateway to process your request as a technical user.
Step 4: Execute the Call
With the token active, you are ready to hit Send. Postman will now pass the bearer token to SAP Datasphere to request your data.
Step 5: Validate the Result
A successful connection will return a 200 OK status. You can now see your Bestsellers Books data in raw JSON format. While this confirms the "Bridge" is working, notice how hard it is to read—this is why we will implement the Visualizer in Part 4.
The Comparison (Transitioning to Option 2)
The manual method works perfectly, but as you can see, it requires several clicks. If you close Postman or wait an hour, that token will expire, and you will have to repeat these steps.
Next, let's explore how to automate this entire flow using a Pre-request Script, so you never have to click "Get New Token" again.
Option 2: The Automated Approach (Professional)
While the manual approach confirms our connection works, it is not scalable. For a truly professional API Bridge, we need a "Set-and-Forget" solution. By using a Pre-request Script, we turn Postman into an intelligent agent that manages its own OAuth 2.0 lifecycle. This is the "Set-and-Forget" method. We use a Pre-request Script to turn Postman into an intelligent agent that manages its own security.
Step 1: Establishing the Environment Layer
Before we write the script, we must centralize our configuration. Instead of hardcoding URLs and Secrets—which is a security risk and an administrative nightmare—we use Postman Environments.
As shown in the image below, create a new environment and name it (e.g., SAP Datasphere). Enter details for ds_url, client_id, client_secret, and token_url as variables.
access_token and token_expiry will be automatically generated after finishing Step 3 below.
Why this matters:
- Security: Your client_secret is masked.
- Automation: Notice the access_token and token_expiry variables. Our script will automatically update these values every time a new handshake occurs, keeping the connection "alive" indefinitely.
Step 2: The Pre-request Script (The Brain)
Instead of adding a script to every individual request, we add it to the Collection Folder. This ensures the logic applies to every OData call you ever add to this project.
- Click the three dots next to your collection name, for e.g. "Datasphere Connection" collection, and select Edit.
- Navigate to the Scripts > Pre-request tab.
- The Logic: The script checks if a token exists or if the current time has passed the token_expiry. If needed, it fetches a fresh token silently in the background.
Paste this script into the Collection Pre-request tab:
// Check if the token is expired (or doesn't exist)
if (!pm.environment.get("access_token") || Date.now() > pm.environment.get("token_expiry")) {
console.log("Token expired or missing. Fetching a new one...");
pm.sendRequest({
url: pm.environment.get("token_url"),
method: 'POST',
header: {
'Content-Type': 'application/x-www-form-urlencoded',
'Authorization': 'Basic ' + btoa(pm.environment.get("client_id") + ":" + pm.environment.get("client_secret"))
},
body: {
mode: 'urlencoded',
urlencoded: [
{ key: 'grant_type', value: 'client_credentials' }
]
}
}, function (err, res) {
if (err) {
console.log("Error fetching token: " + err);
} else {
var response = res.json();
pm.environment.set("access_token", response.access_token);
// Set expiry time (current time + expires_in seconds)
pm.environment.set("token_expiry", Date.now() + (response.expires_in * 1000));
console.log("New token fetched successfully!");
}
});
}
Click the Save button at the top right of the Collection tab (or press Ctrl+S). If you don't save here, the collection won't "know" to run this logic before your requests.
Step 3: Inherit Authentication
After the Pre-request script fetches a fresh token and saves it to the environment, we need to tell our specific API request to use that value.
- Authorization: On your GET request, set the Auth Type to Bearer Token.
- Variable: In the Token field, type {{access_token}}.
- Environment: Ensure the "SAP Datasphere" environment is active in the top-right dropdown.
- Headers Tab: Add the mandatory key 'x-sap-sac-custom-auth' and set it to 'true'. This is essential for both approaches to bypass the SAP login screen.
- Send: Click the blue Send button.
What happens when you click Send?
This is the "Grand Opening." When you hit Send, Postman follows this sequence:
- The Script Runs: It checks the environment variables. If the token is missing/expired, it calls the SAP Token URL.
- Variables Update: You’ll actually see the access_token and token_expiry values change in your Environment tab in real-time.
- The GET Request Fires: Postman injects the fresh token into the header and sends the request to Datasphere.
- The Result: You receive your 200 OK and the JSON data.
Why this is the "Professional" Way:
This setup creates a seamless link. When you hit Send, Postman follows this sequence:
- The Script Runs: It checks the environment variables. If the token is missing/expired, it calls the SAP Token URL.
- Variables Update: You’ll actually see the access_token and token_expiry values change in your Environment tab in real-time.
- The GET Request Fires: Postman injects the fresh token into the header and sends the request to Datasphere.
- The Result: You receive a 200 OK response and the corresponding JSON data.
Benefits:
- The Automated Advantage: You can walk away for a week, come back, hit "Send," and it will just work. The script handles the handshake before you even realize a token was needed.
- Self-Healing: If the token expires, the script detects it and fixes it in milliseconds.
- Security: Your secrets are stored in the Environment layer, not the request itself.
- Scalability: You can add 100 different OData requests to this collection, and they will all share this automated login logic.
Part 4: Real-Time Data Validation (The Visualizer)
Raw JSON data is hard to read. An alternative option is to use the Postman Visualizer to transform our live SAP Datasphere OData feed into a professional, searchable dashboard.
The "Visualize" Tab:
Step 1: The "Post-Response" Script
In your automated GET request, navigate to the Scripts > Post-response tab. Unlike the Pre-request script, which handles security before the call, this script executes after the data arrives.
Paste the following code to map your OData fields to an HTML table (You can modify the template below as per your need):
// Define the HTML/CSS Template
var template = `
<style>
body { font-family: Arial, sans-serif; margin: 20px; }
#search { margin-bottom: 15px; padding: 10px; width: 100%; border: 1px solid #ccc; border-radius: 4px; }
table { border-collapse: collapse; width: 100%; }
th { background-color: #0070f3; color: white; padding: 10px; text-align: left; position: sticky; top: 0; }
td { border: 1px solid #ddd; padding: 8px; }
tr:nth-child(even) { background-color: #f2f2f2; }
tr:hover { background-color: #e9f5ff; }
</style>
<input type="text" id="search" onkeyup="searchTable()" placeholder="Search for book names or authors...">
<table id="bookTable">
<thead>
<tr>
<th>Name</th>
<th>Author</th>
<th>Price</th>
<th>Year</th>
</tr>
</thead>
<tbody>
{{#each response.value}}
<tr>
<td>{{Name}}</td>
<td>{{Author}}</td>
<td>{{Price}}</td>
<td>{{Year}}</td>
</tr>
{{/each}}
</tbody>
</table>
<script>
function searchTable() {
var input = document.getElementById("search");
var filter = input.value.toUpperCase();
var table = document.getElementById("bookTable");
var tr = table.getElementsByTagName("tr");
for (var i = 1; i < tr.length; i++) {
var txtValue = tr[i].textContent || tr[i].innerText;
if (txtValue.toUpperCase().indexOf(filter) > -1) {
tr[i].style.display = "";
} else {
tr[i].style.display = "none";
}
}
}
</script>
`;
pm.visualizer.set(template, {
response: pm.response.json()
});Step 2: The "Grand Opening" (Click Send)
Once your script is saved, click the blue Send button.
- Status Check: You will see the 200 OK status return in the bottom right.
- Visualize: In the response body section, click the Visualize tab.
- Result: Your raw data is now a clean, interactive blue table. You can search for specific authors or titles in real-time.
Part 5: The End Goal—Exporting for Downstream Apps
The ultimate goal of this "Bridge" is to feed other systems without manual intervention.
For Business Users: Use Postman’s "Send and Download" feature (click the arrow next to the Send button). This exports the live OData response into a
.jsonor.csvfile that can be ingested by Excel or Power BI.For App Developers: Since the OAuth flow is now automated, this Postman Collection can be exported as a JSON file. Developers can use the Postman Collection Runner or Newman to integrate this data feed directly into a CI/CD pipeline or a custom React/Python application.
Conclusion: From Data Silo to API Bridge
In this guide, we didn't just connect Postman to SAP Datasphere—we built a production-ready OData bridge.
- Exposed: Turned a static View into a live OData service.
- Secured: Implemented robust OAuth 2.0 scoping.
- Automated: Used Pre-request scripts to ensure the connection never expires.
- Validated: Used the Visualizer to prove the data is accurate at a glance.
By following this workflow, you can empower your external applications, third-party vendors, or internal analytics tools with real-time data from your SAP ecosystem—securely and automatically.
#SAPDatasphere #SAPBDC #Postman #OAuth2 #OData #Integration #DataAsAService