Use Case — Utilities

Boiler down at 11pm.
Tradespeople alerted before the customer calls back.

Boiler down at 11pm. Tradespeople alerted before the customer calls back.

See how the API works →

Utility providers promise 24/7 cover — but their dispatch process runs on spreadsheets

A customer calls at 23:00 reporting no heating. Your call handler logs the fault, checks a spreadsheet for out-of-hours contractors, leaves a voicemail, and promises a callback by 8am. The customer wakes up cold and angry, posts on X, and cancels their cover plan. Out-of-hours dispatch failures are your biggest churn driver — and they're entirely preventable.

Fault logged on your system — PipeIQ alerts the on-call contractor network instantly

What the contact received — for real

pipeiq.co.uk ✓ Delivered
"Hi Dan, your boiler breakdown report to Northern Energy has been received. An engineer will contact you to arrange a callout."
Sent 07 Aug 2026, 16:46 BST · Confirmed delivered · Reply STOP to opt out

A message, sent and delivered live on the platform. TPS-screened before every send. ICO registered: ZC164080.

Fault reported. On-call engineers alerted. Customer updated automatically.

A fault is logged out of hours; you POST the customer's number and postcode. Only those two fields are required — who to reach and where the job is. Everything else is optional attribution.

POST https://app.pipeiq.co.uk/api/leads/register POST
curl -X POST https://app.pipeiq.co.uk/api/leads/register \
  -H "Content-Type: application/json" \
  -H "X-PipeIQ-Token: YOUR_API_KEY" \
  -d '{
    "mobile_number": "07700900000",
    "postcode": "NE1 7RU",
    "selected_trade": "gas",
    "utm_source": "ooh-dispatch",
    "utm_campaign": "boiler-faults"
  }'

A 201 Created response means the lead was registered and the welcome SMS was dispatched; the body returns the matched postcode sector. mobile_number accepts 07xxxxxxxxx or 447xxxxxxxxx. selected_trade takes plumbing, gas, electrical, roofing, building or all; it is not validated, so an unrecognised or omitted value is recorded as Other rather than rejected. Full field and response reference on the Partner API page.

Seven response codes, and what your integration should do with each

Lead distribution fails quietly when nobody handles the unhappy path. One of these you must never retry.

CodeMeaningWhat to do
201Lead registered, welcome SMS dispatchedStore the returned postcode sector against the lead.
400Missing or invalid fieldsFix the payload; do not retry unchanged.
401Invalid or missing API keyCheck the header. Never put the key in client-side code.
405Wrong HTTP methodPOST only. OPTIONS returns 200 for CORS preflight; everything else is rejected.
422Number previously opted outDo not retry. Mark the lead unreachable by SMS and route it another way.
429Daily call limit reached (100 per key per 24h)Back off and resume; email support to raise the cap. Sandbox keys share this status.
500Unexpected server errorRetry with backoff; contact support with your request id if it persists.

The 422 is the one worth designing around. It is not a transport failure, it is a lawful-basis answer: that person has told us not to text them. Retrying it is the easiest way to turn a compliance feature into a compliance incident.

What utility providers and home cover companies see

9%
Average engineer acceptance rate on out-of-hours fault dispatches
600+
Fault dispatches handled per month for a regional home cover provider
0
On-call coordinators needed — dispatch runs automatically around the clock