CardDAV filter not working - Issue with 3CX Server-Side CRM Integration

[ATSrl]

CardDAV filter not working - Issue with 3CX Server-Side CRM Integration
Hi everyone,
I’m trying to integrate EGroupware with 3CX PBX using server-side CRM integration. After extensive testing, I’ve encountered some limitations that make this integration difficult.

1. CardDAV REPORT filter is ignored
   When sending a CardDAV REPORT request with a TEL filter:
   xml<C:addressbook-query>
   <C:filter>
   <C:prop-filter name=“TEL”>
   <C:text-match match-type=“contains”>348351</C:text-match>
   </C:prop-filter>
   </C:filter>
   </C:addressbook-query>
   EGroupware returns all 2078 contacts instead of only the matching ones. The filter appears to be completely ignored.
2. JSON API has no phone number filter
   The JSON endpoint (/groupdav.php/default/addressbook/ with Accept: application/json) returns all contacts. There’s no query parameter to filter by phone number server-side.
3. Complex JSON structure
   The JSON response uses paths as keys (e.g., /default/addressbook/18712) and deeply nested phone fields (responses.*.phones.tel_cell.phone), which 3CX cannot parse properly.
   Questions:

Is CardDAV filtering supported? If so, what’s the correct syntax?
Is there an API endpoint that supports filtering contacts by phone number?
Any plans to add a simpler REST API for contact lookup?

Thanks for any guidance!

[RalfBecker]

EGroupware has a special phone-number search, which understands phone-numbers and their different formatting.

It’s triggered when the search contains the complete phone-number (at least 9 digits).
Brackets, space, dash or slashes are ignored.
The following types of numbers are understood:

• international number with +<country-code> <area-code> <number>
• international number with 00<country-code> <area-code> <number>
• national number with 0<area-code> <number>

So the only thing you can do wrong, is not sending all numbers, but try the matching yourself

Unfortunately there was a bug in the last versions, which caused the phone-search to fail, which is now fixed:

* Addressbook/CardDAV/REST: fix not working search for phone-numbers (you need at least 9 digits!)

The JSON/REST API use the GET/Query parameter filter[search]=<pattern>, you can limit the attributes you get back with an optional props[]=displayname.
Here’s a full example with curl:

curl -i "https://boulder.egroupware.org/egroupware/groupdav.php/addressbook/?filters\[search\]=01701234567&props\[\]=displayname" -H "Accept:application/pretty+json" --user ralf

Enter host password for user 'ralf':

HTTP/2 200 
server: nginx/1.28.1
date: Sun, 04 Jan 2026 14:21:39 GMT
content-type: application/json; charset=utf-8
expires: Thu, 19 Nov 1981 08:52:00 GMT
cache-control: no-store, no-cache, must-revalidate
pragma: no-cache
x-dav-powered-by: EGroupware 23.1.013 CalDAV/CardDAV/GroupDAV server
x-content-type-options: nosniff

{
        "responses": {
"/addressbook/5450": "Ralf Other",
"/addressbook/5646": "Ralf Becker"
        }
}

Please note: the backslash before the square brackets are required by curl, you must not use them with other clients!

CardDAV REPORT filter is ignored

When sending a CardDAV REPORT request with a TEL filter:

xml<C:addressbook-query>

<C:filter>

<C:prop-filter name=“TEL”>

<C:text-match match-type=“contains”>348351</C:text-match>

</C:prop-filter>

</C:filter>

</C:addressbook-query>

EGroupware returns all 2078 contacts instead of only the matching ones. The filter appears to be completely ignored.

Currently only UID, EMAIL, FN and ORG are supported, TEL is not and 348351 is to short to trigger the phone-number search.

JSON API has no phone number filter

The JSON endpoint (/groupdav.php/default/addressbook/ with Accept: application/json) returns all contacts. There’s no query parameter to filter by phone number server-side.

There is, see my above example.

Complex JSON structure

The JSON response uses paths as keys (e.g., /default/addressbook/18712) and deeply nested phone fields (responses.*.phones.tel_cell.phone), which 3CX cannot parse properly.

Hmm, the standard JS-Card format is the only one we currently support. You could use e.g. jq to filter or reformat the JSON.

Or if you only need the name for the number, you can use props[]=displayname as in my example, to only return the name.

Is CardDAV filtering supported? If so, what’s the correct syntax?

As I wrote above, TEL is currently not supported, thought that could be added relativ easy.

Is there an API endpoint that supports filtering contacts by phone number?

Yes, you problem was the to short number-part, use the full number.

Any plans to add a simpler REST API for contact lookup?

No current plans, thought we’re always open for enhancing EGroupware, preferable in a standardized way.

Ralf

[ATSrl]

Hi Ralf,
Thank you so much for your quick and helpful response! I really appreciate you taking the time to explain EGroupware’s phone search functionality, and especially for identifying and fixing the bug so promptly.

You are right: EGroupware follows well-established open standards. After looking more carefully into this, I now understand that EGroupware properly implements:

• CardDAV (RFC 6352) for address book synchronization
• JSContact/JSCard (RFC 9553) for contact data representation
• A RESTful JSON API consistent with these standards

The integration challenge we’re experiencing seems to stem from 3CX’s approach. From what I can tell, their “Server-Side CRM Integration” appears to use a proprietary template system that expects a specific flat JSON format, rather than supporting standard protocols like CardDAV directly. However, I may be missing something, so I plan to reach out to the 3CX community to better understand if there’s a way to work with standard-compliant servers.

I will post a question on the 3CX forum to ask whether they support CardDAV or have recommendations for integrating with servers that follow IETF standards.

In the meantime I’ll tra to create a small middleware layer to bridge the two systems. Your suggestion to use the filters[search] parameter with the full phone number and props[]=displayname is very helpful and gives me a solid foundation to work with.

Thank you again for your support and for maintaining such a well-documented, standards-compliant platform. It’s refreshing to work with software that follows open standards!

Best regards,
Gabriele