Cx Web Services – Getting Repair Work Orders
- Jim Walker
- Jan 9
- 4 min read
Cx Web Services – Getting Repair Work Orders (Picking Up Where We Left Off)
A while back, I wrote a post called “Cx Web Services Step by Step – Get me a token!”.If you haven’t read it, it’s probably worth a quick skim first, because everything here builds on that:
A LOT has happened and changed since then. Cx versions have moved on, but one thing has only increased - people need to get data in and out of Cx, and the Cx SOAP web services are still doing a lot of heavy lifting in the real world.
I’ve always meant to come back and write more of these. I also try to give back where I can, which is why I answer questions on Viva Engage when I’ve got the time. This post is very much in that spirit — practical, no fluff, and based on how this stuff actually gets used.
So, let’s move on from tokens and do something useful.
Quick Recap: Authentication Still Comes First
Nothing new here.
Before you can call any Cx web service, you must:
authenticate via the token service
get a valid token
pass that token into every subsequent call
If your token expires, you’ll get an “Access denied – Invalid token” fault and you’ll need to go back and get a new one. Exactly as before.
I’m not going to repeat all of that here — it’s covered in detail in the earlier post — but just remember: if your tokens not down...you're not coming in!
The Service We’re Using
To get repair work orders, we use the WSRepairContractorService, which lives at:
This service is mainly aimed at contractors and external systems, but it’s useful for anyone who needs to read repair data out of Cx in a supported way.
The method we care about in this post is:
GetRepairWorkOrders
The Basic GetRepairWorkOrders Call
Here’s a simple, working example of the SOAP request.It includes:
the token you already retrieved
paging information
and (optionally) filters.
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:civ="http://Civica.Housing.Cx.WebServices.RepairContractor"
xmlns:civ1="http://schemas.datacontract.org/2004/07/Civica.Housing.Cx.WebServices.Contracts.DataContracts.Modules.Security"
xmlns:civ2="http://schemas.datacontract.org/2004/07/Civica.Housing.Cx.WebServices.Contracts.DataContracts.BaseClasses"
xmlns:civ3="http://schemas.datacontract.org/2004/07/Civica.Housing.Cx.WebServices.Contracts.DataContracts.Modules.Repair">
<soapenv:Header/>
<soapenv:Body>
<civ:GetRepairWorkOrders>
<civ:request>
<civ1:Token>your-valid-token-here</civ1:Token>
<civ2:PageInfo>
<civ2:PageNumber>1</civ2:PageNumber>
<civ2:PageSzie>10</civ2:PageSzie>
</civ2:PageInfo>
<!-- Optional filter -->
<!--
<civ3:OrderReference>REP123456</civ3:OrderReference>
-->
</civ:request>
</civ:GetRepairWorkOrders>
</soapenv:Body>
</soapenv:Envelope>
Yes, PageSzie Is Misspelled
Before anyone emails me — that spelling is correct.
PageSzie is misspelled in the Civica code itself and has been that way forever. If you “fix” it to PageSize, the request won’t work. This has caught out more people than I can count. Be careful of that with AI generated code.
Also note that whilst the thousand page Civica Web Services Definition document might include may tags, you don't need to pass in everything. What's equally unhelpful is what's stated as optional might not be, and what is mandatory equally may not be. If you like a puzzle...getting a web services method to work can be sooooo much fun!!
Filtering the Results
In this call if you don’t pass any filters, Cx will return all repair work orders that the authenticated user is allowed to see, subject to paging. Be aware that may be tens of thousands so be sensible.
I've shown here how you can filter the results though — for example by OrderReference.
This is useful if:
you’re looking up a specific job
you’re re-syncing failed messages
you want to sanity-check data you already hold
What You Get Back
Below is an example response.
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Body>
<GetRepairWorkOrdersResponse xmlns="http://Civica.Housing.Cx.WebServices.RepairContractor">
<GetRepairWorkOrdersResult
xmlns:a="http://schemas.datacontract.org/2004/07/Civica.Housing.Cx.WebServices.Contracts.DataContracts.Modules.Repair"
xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
<a:RepairWorkOrderSummary>
<a:Address>
<a:Address>XX Sample Street, Sampletown, AB1 2CD</a:Address>
<a:AddressId>12345</a:AddressId>
<a:Description>Sample Property</a:Description>
</a:Address>
<a:Contract>Sample Contractor Ltd</a:Contract>
<a:ContractId>99</a:ContractId>
<a:CreatedDate>2024-01-10T09:15:00</a:CreatedDate>
<a:OrderDate>2024-01-10T09:16:00</a:OrderDate>
<a:OrderId>98765</a:OrderId>
<a:OrderReference>REP000123</a:OrderReference>
<a:OrderUid>00000000-0000-0000-0000-000000000000</a:OrderUid>
<a:Description>Repair description text goes here</a:Description>
<a:PriorityDescription>Routine</a:PriorityDescription>
<a:RepairTypeDescription>Day to Day</a:RepairTypeDescription>
<a:StatusCodeDescription>Complete</a:StatusCodeDescription>
<a:OrderStatusDescription>Complete</a:OrderStatusDescription>
<a:TargetStartDate>2024-01-10T09:16:00</a:TargetStartDate>
<a:TargetCompletionDate>2024-01-15T17:00:00</a:TargetCompletionDate>
</a:RepairWorkOrderSummary>
</GetRepairWorkOrdersResult>
</GetRepairWorkOrdersResponse>
</s:Body>
</s:Envelope>
A Few Important Things to Understand
This method gives you summary-level repair data. That’s by design.
You’ll get:
references and IDs
property details
dates, priorities, and statuses
You won’t get:
tasks or SORs
appointment detail
full order history
Those come from other methods, which I’ll cover in future posts.
Common Things That Still Catch People Out
A few classics I still see regularly:
tokens expire, so you have to refresh, maybe even between batches if you're doing a paged pull over many hours
Cx security roles and functional units should apply
assuming this is “real-time” (it isn’t — it’s pull-based)
If something looks odd, check the basics first.
Wrapping Up
Even with all the talk of REST, SOAP-based Cx integrations are still everywhere, quietly doing their job. If you can get a token and successfully call GetRepairWorkOrders, you’ve already cracked a big chunk of most contractor-style integrations.
In the next posts, I’ll look at:
pulling full repair detail
and how these methods are typically chained together in the real world
As always, if you’ve built something interesting — or hit something weird — feel free to shout. That’s half the reason I write these in the first place. If there's a particular method you need help with please do reach out and i'll do a post on it.
Comments