WEDA Postman API Collection
Download WEDA Postman API Collection
What is WEDA Postman API Collection?
This collection provides example requests for the WEDA platform and has been confirmed compatible with WEDA Core v1.2.0. It covers selected workflows rather than every v1.2.0 operation. Use the API Hub for current request and response contracts.
What's Included:
- ✅ Authentication & Authorization
- ✅ Organization & Device Management
- ✅ Container Stack Deployment
- ✅ Telemetry Data Collection
- ✅ Tunnel Management for Remote Access
- ✅ AI Model Management
Why Use This Collection?
Problems It Solves
1. Complex API Dependencies WEDA APIs require specific execution sequences, such as authentication before device provisioning. The examples show the requests and capture variables needed for subsequent steps.
2. Manual Testing is Tedious The collection provides URLs, request bodies and scripts that capture authentication tokens and resource IDs. Review workflow-specific variables before sending requests.
3. Multi-Module Coordination Use the relevant requests in order to test workflows such as deploying a container to a device. A successful dispatch response still requires a later result check.
4. Learning Curve The examples provide a starting point for learning WEDA APIs. Replace example values with your deployment, Org, device and application settings.
What You Get
- ✅ Pre-configured Requests - Examples for the included workflows
- ✅ Automatic Variable Management - Authentication tokens and IDs are auto-saved between requests
- ✅ Sequential Workflows - Related requests arranged by task
- ✅ Response Checks - Scripts in the collections help inspect results
Pre-requisites
Step 1: Install Postman
Install Postman.
Step 2: Get Collection Files
Download and extract the WEDA API collection package
Note: If you download the .zip file, make sure to extract it.
Step 3: Import into Postman
- Click Import button (top-left)
- Choose the file or folder you downloaded
- Import the seven collection JSON files and
weda-core.postman_environment.json. You should see 7 collections in the left sidebar and the weda-core environment.
The collection filenames match the repository, including their spelling:
| Collection file | Workflow |
|---|---|
0-WiseSso.postman_collection.json | Authentication |
1-Org&ClientCrend.postman_collection.json | Organization and Client Credentials |
2-Provisioning&Activation.postman_collection.json | Device registration and activation |
3-Telemetry.postman_collection.json | Telemetry |
4-Contaienr-Stack.postman_collection.json | Container Stacks |
5-Tunnel-Mgmt.postman_collection.json | Tunnels |
7-AI-Model-Mgmt.postman_collection.json | AI Models |
Postman Overview
- left side:
- Collections: 7 collections containing categorized API requests
- Environments: Select
weda-coreenvironment for API requests
- main panel:
- send request and request setting/response details
- right side:
- Variables: shows environment variables (auto-populated from API responses)
Step 4: Configure Your Environment
- Click Environments tab (left sidebar)
- Select your environment(
weda-core). - Fill in your account credentials:
| Variable | Your Value |
|---|---|
login | Your WEDA account email — required |
password | Your WEDA account password — required |
domain | Pre-filled with https://tpe.cloud.advantech.com; change only if your deployment differs |
ssoBaseUrl | Pre-filled with identity; change only if your deployment differs |
Note: If you don't have WEDA account, please go to Request Free Account to request one.
tenantPath (default central) and appPath (default weda) are also pre-filled — change them only if your deployment uses different values.
Fill in login and password for the sign-in example and verify the deployment defaults. Feature workflows also require their own inputs, such as device IDs, application files and target container names; these are not all populated by importing the environment.
- Activate the environment - Select it from the dropdown (top-right corner)
Start with 0-WiseSso and check the captured authentication values before proceeding to the relevant feature workflow.
How to Use
Running a Single Request
- Select a collection from the left sidebar (e.g., 2-Provisioning&Activation)
- Click on a request (e.g., Provisioning Node)
- Review the request details in the main panel
- Click Send button
- Check the response:
- Status code (successful operations can return 200, 201, 202 or 204, depending on the API)
- Response body (JSON data returned by API)
- Test Results tab (validation results)
Run the requests needed for your task in order, starting with authentication and the required resource IDs. You do not need to run unrelated collections. 202 confirms acceptance of asynchronous work; query its result before treating it as complete. 204 has no response body.
Selecting Send runs that request and its scripts; it does not execute the next request automatically. Workflow branching with setNextRequest applies to collection runs. See Postman's workflow documentation.
AI Model Upload and Deployment
Before using 7-AI-Model-Mgmt, prepare a compatible model file and an inference container on the target device:
- Configure
apibaseurl,baseUrl,tusd,accessToken,org_idanddeviceIdas described in the repository README. The API base URL includes/api/v1. - Set
fileName,fileSize(the exact byte count) andfileHash(the 64-character lowercase SHA-256 hex digest without a prefix). All three must match the file to be transferred. - In Upload a file chunk, choose that same file under Body → binary. For Newman, place the file under its
--working-dirand set the request's filesrcto the corresponding relative path. - Set
containerNameto the actual target container. Its default,container1, is an example. The collection generates a uniquemodelEditionusing v1.2-compatible naming. - Run Create Model, Register New Edition of an Existing Model, Create a resumable upload and Upload a file chunk in order. If the Model name already exists, use List Models for an Organization to select the intended Model before registering an Edition.
- Repeat Check Upload Status until it reports Uploaded. Inspect an upload or verification failure before deploying.
- Run Create Model Deployment, then query List All AI Models for a Specific Device and List Devices for a Specific Model Edition. Check the device state and the inference application's use of the model.
The sample deployment requests ATOMIC_SWAP_AND_RESTART_CONTAINER for the configured container. Its other hooks are NOOP, so it does not request additional disk-space, device-side checksum or application health checks. See Deploy an AI Model for explicit checks and result interpretation.
In the repository revision reviewed on October 27, 2026, two AI collection scripts target names that differ from the imported request names:
| Script location | Existing target | Imported request name |
|---|---|---|
| Create Model, on a name conflict | List Models (find existing) | List Models for an Organization |
| Check Upload Status, while waiting | Wait Upload Status = Uploaded | Check Upload Status |
Use the individual-request sequence above, or correct these targets in your local copy before using Collection Runner or Newman. Check a newer repository revision before applying the same adjustment.
The final requests, Delete Model File from a Specific Device and Delete a Model and All Its Editions, perform cleanup. Run them only when you intend to remove the device deployment and Cloud Model. Use a test device and confirm the target container before executing the deployment and cleanup sequence.
Troubleshooting
Clear All Cookies
If sign-in fails, verify the deployment URL, tenant, account and token. Clear stale cookies when they conflict with a new sign-in, then repeat authentication. For validation or conflict responses, inspect the API error details and workflow inputs rather than assuming cookies are the cause.