SROs

Read live PIMS Service Repair Orders (SROs) to follow repairs from intake through invoicing. These endpoints return a defined set of fields using snake_case names. To submit devices for staff to receive, see Pending SROs.

Authentication

Use HTTPS and HTTP Basic Auth with your tenant's API ID and API Secret for new integrations. Every request also needs a teamID query parameter. Keep credentials on your server and out of URLs. For legacy credential options, see Authentication.

These endpoints share a read budget with Get a Pending SRO. See Rate limits.

Get an SRO

GET /tenant/api/pims/v1/sros/:sro_number

curl -s -u 'YOUR_API_ID:YOUR_API_SECRET' \
  'https://cloud.weevio.co/tenant/api/pims/v1/sros/EXAMPLE-SRO-001' \
  --get \
  --data-urlencode 'teamID=<YOUR-TEAM-ID>'

{
  "status": "success",
  "data": {
    "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",
    "equipment": [
      {
        "serial_number": "EXAMPLE-SERIAL",
        "description": "Mac mini",
        "part_number": null
      }
    ]
  }
}

Response fields

Notes and redaction

The API returns screen comments and customer-facing repair statements. Internal technician notes are excluded. Render returned text as escaped text, not HTML.

Blank notes are null. As a safeguard, the API applies a conservative filter: notes that contain credential-like words or serialized JSON are withheld in full. Notes mentioning passwords, passcodes, or tokens are withheld, including device passwords and notes that say no password was supplied. The filter is a safety net, not a guarantee. Do not store secrets in SRO notes.

A withheld note is null and has a sibling screen_comment_redacted: true or repair_statement_redacted: true inside notes. The flags are omitted for ordinary or blank notes. For example:

{
  "screen_comment": null,
  "screen_comment_redacted": true,
  "repair_statement": "Replace the display"
}

Both notes may be withheld independently. Treat a redaction flag as withheld content, not an empty note. These rules also apply to serial search results and live summaries in Pending SRO responses. As an additional safeguard, other returned strings containing a current tenant credential value can also be null.

Timestamps

Do not append Z or assume UTC for PIMS local status times. Agree on the PIMS timezone with the tenant if your app needs an absolute timestamp. modified_at cannot identify every status transition because it has only day precision.

Find SROs by serial number

GET /tenant/api/pims/v1/sros?serial_number=EXAMPLE-SERIAL

Use this to link older or manually created repairs when you do not already have an SRO number. A serial can have several historical repairs.

Surrounding whitespace is trimmed for serials and customer codes; internal whitespace is invalid. Matching is exact, not a substring or wildcard search. Results retain their stored spelling and are ordered by creation date descending, then SRO number descending. Creation dates have day precision, so this does not establish the order of repairs created on the same day.

curl -s -u 'YOUR_API_ID:YOUR_API_SECRET' \
  'https://cloud.weevio.co/tenant/api/pims/v1/sros' \
  --get \
  --data-urlencode 'teamID=<YOUR-TEAM-ID>' \
  --data-urlencode 'serial_number=EXAMPLE-SERIAL' \
  --data-urlencode 'customer_code=M-1000' \
  --data-urlencode 'limit=1'

A successful response contains data, an array of SROs with the same detail fields shown above, and a top-level incomplete flag.

{
  "status": "success",
  "data": [
    {
      "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",
      "equipment": [
        {
          "serial_number": "EXAMPLE-SERIAL",
          "description": "Mac mini",
          "part_number": null
        }
      ]
    }
  ],
  "incomplete": false
}

A completed search with no matches returns data: [] and incomplete: false.

The incomplete flag

An empty response with incomplete: true is not evidence that no repair exists. Retry later if the search timed out, narrow the search with customer_code, or use a saved Pending SRO or SRO link. Searches are bounded and have no continuation cursor.

Batch status

GET /tenant/api/pims/v1/sros?sro_numbers=EXAMPLE-SRO-001,EXAMPLE-MISSING

Poll known SRO numbers together instead of making one detail request per repair.

Numbers are trimmed and duplicates collapse. The 50-entry limit applies before deduplication. Found results and missing numbers each follow request order. Do not combine sro_numbers with serial_number, customer_code, or limit.

curl -s -u 'YOUR_API_ID:YOUR_API_SECRET' \
  'https://cloud.weevio.co/tenant/api/pims/v1/sros' \
  --get \
  --data-urlencode 'teamID=<YOUR-TEAM-ID>' \
  --data-urlencode 'sro_numbers=EXAMPLE-SRO-001,EXAMPLE-MISSING'

{
  "status": "success",
  "data": [
    {
      "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"
    }
  ],
  "missing_sro_numbers": ["EXAMPLE-MISSING"]
}

Batch items contain exactly the six fields shown above. Estimates, notes, equipment, and other detail fields require Get an SRO.

missing_sro_numbers is always present. It is empty when all numbers are found; if none are found, data is empty and missing_sro_numbers contains all requested numbers after deduplication. Missing batch entries do not produce a 404 response.

Status choices

GET /tenant/api/pims/v1/sros/status_choices

Retrieve the tenant's configured status names and defaults. The only required query parameter is teamID.

curl -s -u 'YOUR_API_ID:YOUR_API_SECRET' \
  'https://cloud.weevio.co/tenant/api/pims/v1/sros/status_choices' \
  --get \
  --data-urlencode 'teamID=<YOUR-TEAM-ID>'

{
  "status": "success",
  "data": {
    "status_choices": ["Example Received", "Example In Repair", "Example Ready", "Example Invoiced"],
    "default_new_status": "Example Received",
    "default_completed_status": null
  }
}

status_choices contains names only. Defaults are null when unset. Status names and their meaning vary by tenant; do not assume a fixed list or that Invoice and Invoiced are interchangeable. Agree with the tenant which status and invoice conditions mean a device is repaired or ready for logistics. The API does not calculate a terminal repair state.

Identifier rules

For these reads, SRO numbers are 1–50 characters; Pending SRO IDs, serials, and customer codes are 1–100. Identifiers must start with an ASCII letter or digit and contain only ASCII letters, digits, ., _, /, or -. URL-encode path components and query values.

Quotes, @ wildcards, semicolons, control characters, and whitespace inside an identifier are rejected. Serial and customer lookups trim surrounding whitespace and compare case-insensitively. Single and batch SRO-number reads use the stored spelling. Unsupported query parameters on the SRO collection route, arrays or objects instead of strings, mixed lookup modes, and invalid limits return 400.

Recommended polling

1. Save pending_sro_id when you create an intake.
2. Read the Pending SRO until each device has an sro_number, then save each link.
3. Poll open SROs every 15–30 minutes, using the batch endpoint with up to 50 numbers per request.
4. Compare status, status_changed_at, invoice_number, and billed_on_invoice. Fetch details when you need estimates or notes.
5. Stop polling when the terminal status and invoice conditions agreed with the tenant are met.

The API does not report canceled intakes. A device with received: false may still be waiting, or staff may have canceled the intake. Set an app-defined timeout for unreceived devices, and reconcile them with the tenant outside the API.

Honor Retry-After on 429 responses and back off on 500 and 502. Use serial search to establish missing links, rather than repeatedly rediscovering known repairs. Do not scan the tenant by modified date: PIMS MODIFIED_DATE is date-only and cannot reliably identify every transition.

Responses and errors

Successful reads return 200 with status: "success" and data. Successful reads and most read errors use Cache-Control: no-store. 429 responses and errors raised before the read starts may not include it.

{
  "status": "error",
  "message": "Unable to read repair data. Please retry."
}