Skip to main content

Upload an AI Model

Upload one version of your model and confirm that it is ready for deployment. This walkthrough uses Model defect-detector, Edition 1-0-3 and your own defect-detector.onnx file.

WEDA Console combines creation and upload in one form. An API client creates the Model, registers the Edition and transfers the file in separate requests. Both paths finish by checking Uploaded, not just the transfer percentage.

Prepare Your Model File​

Before you begin:

  • Select the Org that will own the Model and Edition.
  • Prepare the file for your inference application's runtime. Substitute your own compatible file for the illustrative defect-detector.onnx.
  • Choose the names. Model and Edition names accept letters, digits, hyphens and underscores. Do not use spaces or periods; use an Edition such as 1-0-3, rather than 1.0.3.
  • Check the size. Console displays a 50 GB file limit. API responses expose maxFileSize in bytes; use that service value when checking an API upload.
  • For API requests, obtain a bearer token with access to the Org through User Authentication.

Keep the original file unchanged during upload and retry. Console computes its SHA-256 hash when you select it. For an API upload, prepare the actual filename, exact byte count and 64-character lowercase SHA-256 hash without a prefix.

Create a Model and Edition​

In WEDA Console​

  1. Select the intended Org and open AI Models.
  2. Select Add.
  3. In Basic information, enter defect-detector as AI model name, or select that Model from the dropdown if it already exists. Add a Model Description if needed.
  4. In Edition information, enter 1-0-3 as Edition name, add a description if needed and select your model file. Allow the SHA-256 calculation to finish.
  5. Select Submit, then Add in the confirmation dialog.

Console returns to the AI Models list and starts uploading. Follow the Edition row under your Model.

Check the result: The Edition appears under the intended Model. A creation success message confirms the records were created; wait for the upload and verification result before deploying.

Through the API​

  1. Call Create Model:

    POST /api/v1/orgs/{orgId}/ai-models

    {
    "modelName": "defect-detector",
    "description": "Inspection defect detection model"
    }

    Retain the modelId returned with 201 Created. If the name already exists, use List Models in the management table below to find and reuse the intended Model's ID.

  2. Call Register New Edition under that Model:

    POST /api/v1/orgs/{orgId}/ai-models/{modelId}/editions

    Send a JSON body with the following values from your own file:

    FieldValue to provide
    edition1-0-3, unique within this Model.
    fileNameYour file's name, such as defect-detector.onnx.
    fileSizeIts exact byte count, as an integer.
    fileHashIts computed lowercase SHA-256 hex digest, without sha256:.
    descriptionOptional Edition description.
    changeSummaryOptional summary of this Edition's changes.

    Supply fileName, fileSize and fileHash together. Omitting all three creates an empty Pending Edition with no file or upload session. You cannot add a file to that empty Edition later; delete it and register it again with all three fields to start this workflow.

  3. Retain the returned uploadId, tusEndpoint, maxFileSize and uploadExpiresAt. Use the Edition string 1-0-3 in later paths, not a numeric version ID.

Check the result: Registration returns 201 with an uploadId for this file. It has not transferred the file bytes yet. Continue with tus using the returned endpoint.

Upload the Model File​

In WEDA Console​

The Edition row shows upload progress and the available controls:

What you need to doConsole action
Pause an active transferSelect Pause.
Continue a paused transferSelect Resume.
Continue after refreshing or reopening the pageOn the Interrupted row, select Resume and select the same original file.
Stop an unfinished transferSelect Cancel. To start over afterward, use Upload again.
Retry a failed transfer or verificationSelect Upload again, select the matching original file and restart the transfer.
Start a Pending Edition registered with file metadata that has not begun transferringUse Reupload when offered. An empty Edition without file metadata must be deleted and registered again.

For an interrupted upload, Console checks the selected file's name, size and modification time. Keep the uploading page open when possible. While the row is Verifying, wait for the result instead of trying to pause or cancel verification.

Through the API​

Use your bearer token for these requests and send Tus-Resumable: 1.0.0 on the tus operations. The HTTP blocks below are templates: substitute the endpoint, token, IDs, size and offsets from your upload.

  1. Create a Resumable Upload by sending POST to the returned tusEndpoint, in the same WEDA API and tenant context as registration:

    POST {tusEndpoint}
    Authorization: Bearer {access_token}
    Tus-Resumable: 1.0.0
    Upload-Length: {registered fileSize}
    Upload-Metadata: uploadId {Base64-encoded registration uploadId}

    On 201, retain the upload resource URL in Location. Use that returned URL for transfer, offset queries and termination; do not reconstruct it from the registration ID.

  2. Upload a File Chunk using PATCH on the Upload URL:

    PATCH {Upload URL from Location}
    Authorization: Bearer {access_token}
    Tus-Resumable: 1.0.0
    Upload-Offset: {confirmed byte offset}
    Content-Type: application/offset+octet-stream

    {file bytes beginning at that offset}

    A new upload begins at offset 0. Each successful 204 response returns the updated Upload-Offset; continue with the next bytes until it equals Upload-Length.

  3. If the connection is interrupted, call Get Current Upload Offset with HEAD on that same Upload URL. Resume from the returned offset. A 409 on PATCH means the offsets disagree: query again before sending more bytes. A 404 means that resource was not found.

  4. To abandon the current transfer, call Terminate an Upload with DELETE on the Upload URL. A successful 204 terminates that transfer. To retry, create a new tus session using the original registration uploadId.

Note: Encode the upload ID, send the file as bytes

Base64 encoding is required for the registration uploadId in Upload-Metadata. The PATCH body is the file's raw bytes, not Base64 text or a JSON object. Keep the registration ID for status queries and the Location URL for tus transfer operations.

Resume and restart have different results. Resume an available resource with HEAD and PATCH to keep its stored bytes. A new tus session starts from zero. A fresh in-progress session blocks replacement until uploadExpiresAt passes; creating a replacement afterward discards the stalled transfer's bytes.

The registration uploadId remains valid for retry. The API's 12-hour window determines when an unfinished session may be replaced; it is refreshed when a tus session is created. Read the returned uploadExpiresAt rather than treating it as a permanent expiry of the registered Edition. Do not register the Edition again to retry: an existing Edition returns 409 WEDA.Common.AlreadyExists, including when it is still Pending. An already uploaded Edition does not accept a new tus session.

Check Upload and Verification Status​

In Console, wait for the Edition row to show Uploaded. Through the API, poll Get Upload Status using the registration uploadId:

GET /api/v1/orgs/{orgId}/ai-models/{modelId}/editions/{edition}/uploads/{uploadId}/status
Upload statusMeaning and next action
PendingThe upload is registered but byte transfer has not started. Create the tus session and transfer the file.
UploadingByte transfer is in progress. Continue or resume it.
VerifyingThe transfer is complete and WEDA is computing SHA-256. Wait for the result.
UploadedThe file passed verification and the Edition is ready to deploy.
UploadFailedThe transfer was cancelled or failed. Inspect the upload resource and retry as appropriate.
VerifyFailedHash verification failed, for example because of a mismatch or a verification I/O error. Check the original file and registered metadata before retrying.

Paused and Interrupted are Console states, not values returned by this endpoint. The Edition's own lifecycle status in Get Model Edition Detail is also different from upload progress: use the upload-status query for the six states above. If Console shows a failure after waiting for verification, check the API's current status before starting another transfer; verification may still be running.

No separate finalize request is required after transferring the bytes. Wait for Uploaded, then read the Edition detail and check its filename, byte count and hash. Response file.fileHash includes a sha256: prefix; the registration input does not.

Check the result: The intended Model and Edition have the expected file metadata and an Uploaded result. Upload-Offset == Upload-Length or a success message from record creation alone is insufficient. Continue with Deploy an AI Model.

Manage Models and Editions​

In Console, expand a Model to find its Editions and select an Edition name to open its Information view. Use Edit on a Model or Edit edition on an uploaded Edition to update its description, then Submit and Save. The Console edit forms keep the names and uploaded file read-only.

For API clients, the management operations are:

OperationAPIUse it to
List ModelsGET /api/v1/orgs/{orgId}/ai-modelsFind Model IDs within the Org.
List EditionsGET /api/v1/orgs/{orgId}/ai-models/{modelId}/editionsFind the Model's Editions and file metadata.
Get Edition DetailGET /api/v1/orgs/{orgId}/ai-models/{modelId}/editions/{edition}Inspect the exact Edition, file and upload-session fields.
Update Model Basic InfoPATCH /api/v1/orgs/{orgId}/ai-models/{modelId}Update modelName and/or description. Null fields retain their values.
Update Edition MetadataPATCH /api/v1/orgs/{orgId}/ai-models/{modelId}/editions/{edition}Update the Edition's description. Its name and file are unchanged.
Delete an EditionDELETE /api/v1/orgs/{orgId}/ai-models/{modelId}/editions/{edition}Permanently remove that Edition and its Cloud file.
Delete a ModelDELETE /api/v1/orgs/{orgId}/ai-models/{modelId}Permanently remove the Model, its Editions and their Cloud files.

Model and Edition lists support skipCount / maxResultCount pagination, with a default page size of 20 and an allowed size of 1–1000. Model lists default to modelName asc; Edition lists are primarily newest first, with supported edition / fileSize sorting applied secondarily. Edition responses do not include a creation timestamp. Query additional pages instead of assuming the first page contains every Edition.

For a description-only update, send the following body to the appropriate Model or Edition PATCH endpoint, then read the record back to confirm it:

{
"description": "Inspection model validated for production line A"
}

After upload verification, changing the model file requires a new Edition. Updating a description does not replace its file or deploy anything to devices.

Caution: Cloud deletion is permanent and separate from device removal

Deleting an Edition removes that Cloud file; deleting a Model removes its Editions as well. Already deployed device files are managed separately. If you also intend to remove them, use the device-removal procedure in Deploy an AI Model before deleting the Cloud records.

In Console, select Delete on the intended Model or Edition, enter the requested name and confirm. A successful API deletion returns 204 No Content. Read the relevant list again to confirm removal.

For the protocol background, see Resumable Uploads with tus.