Pending SROs

Submit one or more devices to the staff Pending SRO queue, then retrieve the SRO number for each device after staff receive it. A Pending SRO is an intake request; creating one does not immediately create a repair in PIMS.

Authentication

Use HTTPS and HTTP Basic Auth with your tenant's API ID and API Secret. Send teamID in the query string, including on POST requests. Keep credentials on your server and out of URLs; see Authentication.

Creation has a separate rate limit from reads. See Rate limits.

Create a Pending SRO

POST /tenant/api/pims/v1/pending_sros

Send a JSON object with Content-Type: application/json. Use intake_source: "warehousing" for warehouse requests or "corporate" for corporate requests. Staff receive the request in their existing queue. If supplied, pims_customer_code preselects the customer when staff receive the devices; otherwise, staff select the customer.

Request fields

Each object in devices accepts:

Data backup status

Omit optional fields you do not need. Explicit null values are rejected. Unknown fields, including unknown fields inside contact or device objects, return 400. Do not send IDs, confirmation numbers, timestamps, origin, tenant ownership fields, or other server-assigned values in the JSON body. Unsupported control characters in text are rejected.

The request body is limited to 512 KiB. The saved intake, including server-assigned fields, is limited to 384 KiB. A request can exceed the saved-data limit even when each text field is within its individual limit.

Example request

curl -s -u 'YOUR_API_ID:YOUR_API_SECRET' \
  'https://cloud.weevio.co/tenant/api/pims/v1/pending_sros?teamID=<YOUR-TEAM-ID>' \
  -H 'Content-Type: application/json' \
  --data '{
    "intake_source": "warehousing",
    "external_reference": "WH-12345",
    "pims_customer_code": "M-1000",
    "contact": {
      "name": "Warehouse contact",
      "email": "[email protected]",
      "phone": "555-0100"
    },
    "additional_comments": "Call before returning the device",
    "devices": [
      {
        "device_type": "Mac mini",
        "serial_number": "EXAMPLE-SERIAL",
        "cant_find_serial": false,
        "symptoms": "No power",
        "repair_approver": "Warehouse contact",
        "data_backup_status": "backed_up"
      }
    ]
  }'

{
  "status": "success",
  "data": {
    "pending_sro_id": "12345678-1234-5678-9234-123456789abc",
    "repair_number": "1234-5678",
    "intake_source": "warehousing",
    "external_reference": "WH-12345",
    "created": true
  }
}

Save pending_sro_id for subsequent reads. repair_number is the intake confirmation number, not a PIMS SRO number. Each device gains its own sro_number after staff receive it.

Safe retries with external_reference

The exact external_reference value identifies one request within a tenant. It is not trimmed or case-normalized for idempotency. Repeating the same reference returns the original intake values with 200 OK and created: false, even after the intake is completed or canceled.

{
  "status": "success",
  "data": {
    "pending_sro_id": "12345678-1234-5678-9234-123456789abc",
    "repair_number": "1234-5678",
    "intake_source": "warehousing",
    "external_reference": "WH-12345",
    "created": false
  }
}

A replay does not update the intake or resend notifications. Reuse the reference when retrying after a timeout or server error; use a new reference only for a new intake. Retries must still contain a valid request body. Different tenants may use the same reference independently.

Create responses and errors

{
  "status": "error",
  "message": "intake_source must be corporate or warehousing"
}

Get a Pending SRO

GET /tenant/api/pims/v1/pending_sros/:id

Read the intake by its pending_sro_id, including after it is completed or canceled. Only intakes belonging to your tenant are available.

curl -s -u 'YOUR_API_ID:YOUR_API_SECRET' \
  'https://cloud.weevio.co/tenant/api/pims/v1/pending_sros/12345678-1234-5678-9234-123456789abc' \
  --get \
  --data-urlencode 'teamID=<YOUR-TEAM-ID>'

{
  "status": "success",
  "data": {
    "pending_sro_id": "12345678-1234-5678-9234-123456789abc",
    "repair_number": "1234-5678",
    "intake_source": "warehousing",
    "external_reference": "WH-12345",
    "origin": "open_api",
    "created_at": "2026-10-01T14:30:00.000Z",
    "pims_customer_code": "M-1000",
    "devices": [
      {
        "device_type": "Mac mini",
        "serial_number": "EXAMPLE-SERIAL",
        "data_backup_status": "backed_up",
        "sro_number": "EXAMPLE-SRO-001",
        "received": true,
        "sro": {
          "sro_number": "EXAMPLE-SRO-001",
          "status": "Pending",
          "status_changed_at": "2026-10-01T10:35:00",
          "invoice_number": null,
          "billed_on_invoice": false,
          "modified_at": "2026-10-01",
          "previous_status": null,
          "estimate": 0,
          "estimated_tax": 0,
          "repair_type": null,
          "intake_source": null,
          "customer_code": "M-1000",
          "location_code": "MAIN",
          "notes": {
            "screen_comment": "Call before returning the device",
            "repair_statement": null
          },
          "created_at": "2026-10-01"
        }
      }
    ]
  }
}

Response fields

A missing linked SRO leaves sro_number intact and received: true, with sro: null. A PIMS connection failure returns 502 instead of reporting an unreceived device. The live summary follows the same note redaction and timestamp rules as SRO reads. Its intake_source can be null even when the stored intake source is known, because SRO source tagging is optional.

Read responses and errors

Once devices have SRO numbers, save those links and use batch status polling to follow their progress.

This endpoint does not show whether staff canceled an intake. received: false can mean the device is still waiting or the intake was canceled. Use an app-defined timeout for unreceived devices, and reconcile them with the tenant outside the API.