onOffice: the caller appears in the sidebar

We are not new to property management: casavi and Propstack are connected and answer at the moment of the call. What was missing was the estate agency side — and there is no way past onOffice there.

Why onOffice has the best number search in the catalogue

Most systems force a decision: do you search the landline field or the mobile field? Wanting both means two queries — and taking only one means finding half.

onOffice does not ask the question. About its `normalizedPhoneNumbers` field the vendor writes, verbatim, that it lists “all normalized phone numbers (including main, mobile, etc.)” of an address, and that you can search by a “fully or partially” normalised number.

• Every number instead of one — no either/or between landline and mobile.
• Normalised — onOffice tidies the spellings itself before comparing.
• Partial matches allowed — a number is found from a piece of it.

That is more than most vendors promise. For comparison: one Spanish system requires the number to match character for character, spaces included, or it finds nothing.

1. 1 The phone rings Incoming call
2. 2 Webex reports the number
3. 3 Haus iT Caller ID standardises it
4. 4 Your onOffice looks it up Your customer data stays here
5. 5 The sidebar names the caller

What this connector cost

We normally say: a connector is a description file, not a program. Forty-five times that has been true. With onOffice, not quite.

onOffice signs every single request. From the documentation, verbatim: the check value is produced by concatenating timestamp, token, resource type and action id “in this order”, hashing that with SHA-256 using the secret as the key, and Base64-encoding the result.

A description file cannot do that. The signature is valid only for this one request at this one moment — it does not exist before sending. So the engine had to learn to compute it.

7 auth methods

This is where a maintained catalogue pays off: the effort falls once, not per system.

What is proven — and what is not

There is no recognition rate and no response time here, because there is no onOffice account yet on which we could have measured them. A number without a measurement would be a claim.

What is proven: the request the portal builds matches the vendor’s example field by field. The computed signature matches the one produced by onOffice’s own PHP sample code. And from the sample response in the documentation, the portal reads out name and id correctly.

If something is wrong, it says so

onOffice answers a processing error with an error code in the body of the response, not with an HTTP error. Without a safeguard, a missing permission on the address module would therefore look exactly like “the number is not in there”: an empty list, no message.

The portal checks that code explicitly. During setup, the difference between “no permission” and “nothing found” is half the troubleshooting.