EveryoneAPI still not processing correctly

[SethTalley]

Continuation of this thread:

https://www.3cx.com/community/threa...ation-not-processing-fully.75029/#post-339146

We're wrapping up the year and looking at billing and it appears we're topping up EveryoneAPI far more than we should be.

According to EveryoneAPI, we hit them for 85 queries on December 4, for example. Yet our configuration is set up to only query EveryoneAPI for unknown numbers, we only received 58 calls on December 4 and only 41 of those were internal, incoming calls. The rest are transfers from queues to extensions, etc. All but two of those calls were already in the phone book. So... we should have been hit for 2 queries. Instead we were hit for... 85.

 

[edossantos]

Hi Seth,

The CRM engine, which is used to query EveryoneAPI, will do the contact lookup for all calls coming from an external line (even if the information has been queried before, in order to update the contact record in case anything has changed), and also for outbound calls to external lines (in order to show you the name of the destination when you call out).

I understand that EveryoneAPI works differently than a CRM, billing you for every lookup, and you will want to reduce the number as much as you can. Since Update 7 there is a variable that tells you if the call is inbound or outbound during contact lookup, so this variable could be used to restrict the lookup only for inbound calls. However, if the caller's details are already in the phonebook, the lookup will be triggered anyway.

 

[edossantos]

In order to implement the change I mentioned before to avoid doing the lookup for outbound calls, you can change the following line from the template:

<Request Url="https://api.everyoneapi.com/v1/phone/[Number]?data=name&amp;format=json" RequestType="Get" ResponseType="Json" />

To the following:

<Request SkipIf="[CallDirection]!=Inbound" Url="https://api.everyoneapi.com/v1/phone/[Number]?data=name&amp;format=json" RequestType="Get" ResponseType="Json" />

Please note that this requires 3CX v16 Update 7.

 

[SethTalley]

Nah.

1) There's a setting that says, verbatim, "Query CRM only if contact is not found in 3CX phonebook." It sounds like you're telling me this setting doesn't actually do anything.

2) We got 51 incoming calls, total, in the log for December 4. EveryoneAPI hit us for 85 queries.

3) Even if 3CX is ignoring the CRM query flag, only eighteen of those "calls" originated outside 3CX - the other 33 were hand-offs from queues to extensions.

4) If you're going to query the database every single time the phone rings, what's the point of having a phone book at all?

It doesn't appear that I can query 3CX as to when contacts were added, but looking at the log it appears that over half of our phone traffic was institutions we deal with daily; nonetheless presume all eighteen of those contacts were new. We should be into Telo for eighteen queries, which run us an average of $0.00774 each. That's fourteen cents. Instead we're paying 66 cents. Really, we should be paying about a penny and a half as again, only a couple of those numbers were new to us.

That's about $240 a year I shouldn't be paying due to poorly handled 3CX queries, or wait for it, 125% the cost of our 3CX Pro license.

I'm going to pass this along to Telo because they should know that 3CX's inability to properly interface with them is our reason for dropping them like a hot rock.

 

[SethTalley]

Look - I *get* that EveryoneAPI isn't a CRM like you want CRMs to be? But either it does what it's supposed to do and you support it, or it doesn't do what it's supposed to do and you drop it as an option. I'm $90 in six months into a service that should be costing me fractional pennies per day and that is entirely due to the parameter mismatch between "what it's supposed to do" and "what it actually does." If you can't make those parameters match, say so and drop support. If you can, then lemme help fix it. Let's not pretend this is expected behavior.

 

[edossantos]

1) There's a setting that says, verbatim, "Query CRM only if contact is not found in 3CX phonebook." It sounds like you're telling me this setting doesn't actually do anything.

This setting has a different purpose, and maybe should be better explained. This applies when the call from/to the external number matches a phone book entry, which is NOT a CRM entry. However, if the phone book entry is a CRM entry, the lookup happens always. As I mentioned before, this is in order to update the contact record in case anything has changed on the CRM side.

2) We got 51 incoming calls, total, in the log for December 4. EveryoneAPI hit us for 85 queries.

You should check your outbound calls as well. Enable verbose logs, and you will see all the invocations to EveryoneAPI in the 3cxSystemService.log, there you will see for which calls 3CX is invoking their API.

3) Even if 3CX is ignoring the CRM query flag, only eighteen of those "calls" originated outside 3CX - the other 33 were hand-offs from queues to extensions.

There are no more queries when the call is transferred. The contact lookup happens even before the call is sent to an extension. As soon as the call arrives from an external line, the contact lookup is triggered. Also when you make an outbound call to an external line. No matter how many times you transfer the call, no more lookups will be issued for a particular call. You should enable verbose logs and check the 3cxSystemService.log to understand why you're having those hits.

4) If you're going to query the database every single time the phone rings, what's the point of having a phone book at all?

This is not the case, check the logs and you will confirm this.

 

[SethTalley]

What you're saying, Ed, is that the setting is incorrectly named, not poorly explained.

I've got two different CRMs. They're EHRs, though, so I'm screwed from the get-go. I could maybe get one of them to play nicely if I'm willing to pay them $1200 to mess around in their sandbox and maybe get Zoho to play nicely but then I also have to pay for Zoho when all I want is phone numbers. If 3CX could add callerID to its phone book I wouldn't have to bother with any of this. That's all I want: Caller ID on voicemails.

So I'm utterly baffled as to why I would want a phone book entry that *isn't* a CRM entry, or at the very least, why I'm not able to configure that. I'm further baffled as to why 3CX would take a phone number that's already in its phone book and then, by default, query a paid database just to see if things have changed *after* the call is placed.

And again - presume I edit the XML to get around your non-functional CRM lookup flag. That drops my expense by 50% when really, according to advertised parameters it should be dropping it by more like 98%.

Now you've got me looking like an idiot in front of the company because 3CX is costing us more than double what it was supposed to and the reason? "This setting has a different purpose, and maybe should be better explained."

Here's how you advertise this: https://www.3cx.com/docs/everyoneapi-pbx-crm-integration/

3CX provides integration with EveryoneAPI via the 3CX API for CRM. The configuration is done server-side, in an easy and straightforward way. This integration provides these benefits to users of 3CX and EveryoneAPI:

• Contact Synchronization – Inbound calls from external numbers trigger a contact lookup in your CRM, and contact details are added to 3CX Contacts. This way, the caller name is automatically shown in your phone display when you receive the call.
• Call Pop-ups – When using the 3CX Web Client, the customer record is brought up to you automatically when you receive an inbound call.

What 3CX is now saying is that contact lookups are triggered every time you pick up the phone unless you edit the XML to explicitly not do that, and that the addition of contact details to 3CX Contacts is inconsequential because 3CX doesn't reference the contacts anyway it *has* to query EveryoneAPI every single time.

49 outbound calls, 18 inbound calls, 85 queries charged by EveryoneAPI. The math still isn't adding up.

 

[edossantos]

What 3CX is now saying is that contact lookups are triggered every time you pick up the phone unless you edit the XML to explicitly not do that, and that the addition of contact details to 3CX Contacts is inconsequential because 3CX doesn't reference the contacts anyway it *has* to query EveryoneAPI every single time.

This is not what we are saying. Contact lookup is triggered for every external call, inbound or outbound. And we check the external source for every call because otherwise we might be leaving outdated information in the phonebook. Editing the XML is a shortcut that I'm offering you to reduce the cost if you're not interested in outbound calls.

49 outbound calls, 18 inbound calls, 85 queries charged by EveryoneAPI. The math still isn't adding up.

The only way to understand what's going on here is enabling verbose logs for 1 day, and check all the queries sent by 3CX, and compare them against the calls you have.

 

[SethTalley]

Ernesto:

When I pull down 3CX's contact file, there is no distinguishing between 'CRM contact' and 'not CRM contact.' the CSV seems to load from first to last, except not really, because then it would have a lot of businesses that I imported first followed by a bunch of patients. Nonetheless, the last number (of 1100) in our contacts is nearly a month old.

I understand perfectly what's going on: 3CX sees no reason to limit database queries, despite the fact that it has a template that queries a database that charges per query. I've got logs from the 4th from Telo and they show me that on the 4th, I was charged four cents for four queries for that last number in our contacts. When I look her up, she's 44 entries in my log going back to October. When I look her up on the 4th, she's 5 entries. Your solution makes this patient, who should cost me a penny, cost me 22 cents a month.

You can't tell me this is behavior as designed. And you can't tell me that it's useful. And you've given me no workaround: I can't even see the CRM flag in your exports, let alone clear it and reimport. I can't operate on it within 3CX. You've effectively created a system that will *never* let me desegregate my phone book while at the same time arguing that 3CX will continue to treat CRM and non-CRM entries differently.

Look - my obvious, dumb workaround is to download all my contacts as a CSV, delete all my contacts, then upload all my contacts. That's stupid. It speaks to a profound disinterest in utility and customer support on your part. I shouldn't have to set a calendar event that says "purge and reimport all contacts because 3CX can't get their act together" but here we are.

 

[SethTalley]

Except C'MON MAN





Schroedinger's Phonebook - it's in there once without a plus sign as a 3CX contact, once with a plus sign as a CRM contact (made in the last 10 minutes!). I'll betcha I got hit for that lookup.

I'll betcha I continue to get hit for that lookup.

And all future lookups.

You gotta come up with a solution to this. My dumb workaround can't out-dumb your dumb implementation. And that's pathetic.

 

[Evolute IT]

Dude, just disable the integration and build your own if theirs is so shitty for your liking.

We build custom integrations for 3CX all the time. To be honest, the software company should not charge for API requests, but since they do, just don't use it? I mean, why complicate everything for a few pennies here and there.

 

[SethTalley]

Because I'm a small business owner, not a "three seals from 3CX" reseller and I just need Caller ID to work. If Voip.ms wasn't 90% "WIRELESS CALLER" I wouldn't even be here.

I'm fully willing to believe you build custom integrations for 3CX all the time. I bow before your pendulous expertise but I don't want to have to pay you (or anyone like you) $150 every time something burps because this shouldn't be a "write a custom integration" issue. This should be a "works as advertised" issue.

 

[SweetAction]

1. You should tone down your aggression in your posts. Most of us here are helping you freely.
2. Regarding this

Except C'MON MAN

View attachment 19810



Schroedinger's Phonebook - it's in there once without a plus sign as a 3CX contact, once with a plus sign as a CRM contact (made in the last 10 minutes!). I'll betcha I got hit for that lookup.

I'll betcha I continue to get hit for that lookup.

And all future lookups.

You gotta come up with a solution to this. My dumb workaround can't out-dumb your dumb implementation. And that's pathetic.

You can solve this + / non plus a couple of ways. One way: https://www.3cx.com/docs/cid-reformatting/
3. Regarding the lookup on every outbound call - answer in post #3
4. Regarding lookup on every inbound CRM contact - 3CX's reason of ensuring information is up to date is a good reason. If they change it I am sure people would complain the other way. You have a workaround (export/import so that all contacts are not CRM), yes it's "dumb", but you are unwilling to build your own integration / hire someone to do it for you. Maybe 3CX isn't the right software for your needs, maybe this should have been caught in your testing/demo before buying into this product, etc. Maybe 3CX can find a middle ground for this "CRM" in a future update.

 

[SethTalley]

1) Thanks for chipping in, SweetAction. You're actually the first person who has ever tried to help me. To this point, my interactions on this forum have been "this thing isn't working the way I understand it to be working" followed by Ernesto either saying "there's this weird parameter that shouldn't affect this, but it does" or "that's because something is broken, we will pick it up at some point." Literally all the interactions I've had. I have yet to ask a question about anything other than EveryoneAPI, and if you look up EveryoneAPI, there's only one other person who has even tried to get EveryoneAPI running so frankly, the only way I've been able to muster help other then Ernesto is by using an aggressive, condescending tone.

2) Does not work because EveryoneAPI integrates as CRM, not Caller ID. 3CX's EveryoneAPI integration ypasses Caller ID entirely. If I could hit EveryoneAPI through the CID stack I imagine I would have none of these problems but my understanding is that 3CX cannot do that for reasons of antitrust. Thanks anyway.

3) staunches a leak, it doesn't fix it. It takes me from bleeding out $20 a month to bleeding out $10 a month when really, once the contact is in the phone book it should look only when I ask it to. Or at the very least, allow me to flag it as permanent. That's the real issue here: this isn't a CRM problem, it's a CallerID problem that can't be dealt with as a CallerID problem because it interferes with 3CX's business model. So I'm asking how to make it work within 3CX's business model and the answer has typically been "it doesn't, here's a fix" but this time around the answer is "it doesn't, and it won't."

4) With a CRM, it makes sense to query the database every time the phone rings. With a phone directory it doesn't. It has been established by 3CX, however, that CallerID through 3CX will be handled as CRM. There is clearly an attempt to work around this: An option to "only query CRM if contact is not found in 3CX phonebook." However, while 3CX will import CRM contacts into its phonebook, it will never actually import CRM contacts into its phonebook, instead internally flagging them with "CRM." Note that this flag is not editable, operable, exportable or importable.

Clearly, this is a "contacts" problem. Just as clearly, there is no mechanism by which to raise "contacts" issues - there isn't even a subforum for it. It's thunderously easy to delete the entire 3CX phone book. Importing a new one? Welll.... 3CX is pretty fussy about the way it wants things formatted. Been there, done that. Which is why this situation is so odious - 3CX is clearly tracking the date the contact was added, as well as the contact's source but it neither lists the date nor allows any operation on the source other than filtering.

And to be clear: I'm not unwilling to build my own integration. I'm actually stuck using two different CRMs and 3CX has assured me in no uncertain terms that their software will never be able to integrate with more than one. Of those two CRMs, one of them has no API to integrate with at all. The other was willing to allow me access to their sandbox for $1000 and $250 an hour if I wanted to try and tie their integration in with Zoho... but then six months later paired up with a consultancy that now makes them exclusively SalesForce. And again, that would give me about half of my patient load, would require 3rd party integration, and would then tie my entire office into SalesForce when all I want is Caller ID.

Maybe 3CX CAN find a middle ground in a future update. So far, my every interaction has been "yeah it shouldn't do that, try this" or "yeah it shouldn't do that, we'll have an update for you" but here, the answer is basically "the problem is with another piece of 3CX, can't help you, can't tell you who can." And that's disappointing.

On the plus side, five of the top five google hits for "3cx EveryoneAPI" are me dealing with these problems so moving forward, the situation will be clear to other people before "gold partners" tell them they didn't do their research.

 

[SweetAction]

Reviewing, most of the issues appear to come back to trying to use "CRM" as "CID" (CRM and CID as defined in the 3CX world). The limits you are hitting are due to CRM integration (once again, CRM as envisioned by 3CX) not being designed to provide CallerID at it's core the way you want it, although it is able to be used that way (with these limits).

So it boils down to a few options...

1) Fix the root problem of "voip.ms 90% is wireless caller".
2) Accept the limits of the workarounds currently available. Ask for improvements, but don't expect them to be here today. Basically this whole thread.
3) Implement another workaround without these limits. For example, CRM can query a SQL database. Perhaps have CRM query the DB and feed the DB with EveryoneAPI (a caching layer of sorts). Hire a developer if needed.
4) Accept the issue with no workaround. Pay the $$$'s for using the current integration.
5) Something else.

In my line of work I often get to deal with the "I'm in a bad place and will take it out on you" people. Important to remember I didn't (nor anyone else here) put you in this situation - but we are/were trying to help you anyways.

Re:

On the plus side, five of the top five google hits for "3cx EveryoneAPI" are me dealing with these problems so moving forward, the situation will be clear to other people before "gold partners" tell them they didn't do their research.

I don't know what you did or didn't do. However, a properly managed project includes a testing phase before go-live. No matter what anyone says/writes about a products features, that testing phase should include verification that these features work as expected.

I appreciate the feedback that CID rewrites don't work on CRM Contacts - not something I had tested / knew.

 

[SethTalley]

Most of the issues come back to "does not perform as expected." I've been beta-testing since 1998. I've got three different Centercode logins. With the software packages I've used professionally, there's an expectation that "does not perform as expected" becomes a bug report becomes a closed beta becomes an open beta becomes a release note. My experience browsing the 3CX forums indicates that 3CX is no different than most prosumer networking packages: you can ask for a feature but if you're not a dedicated-rep enterprise customer you might as well shout into a hole (and if you are an enterprise customer you don't need to ask on forums).

I'd like to note that your signature offers to design and install my "large installation" phone system yet I'm here educating you about the way CID rewrites work. Had this been your system, you would have presumed the documentation represents the capabilities, worked up a proposal with your client and been left holding the bag. The only difference here is that I'm my own client. And it's been my experience that people in your "line of work" think you're helping when in fact, you're getting educated. I didn't take anything out on you - I took it out on Ernesto, who is defending the notion that the option "only query CRM if contact is not found in 3CX phonebook" querying the phonebook every time a call comes in is a syntax problem, not a performance problem.

I'd also like to note that I paid EveryoneAPI $10 on January 23rd and turned it on January 24. That lasted me until May - that's four months of calls in which every incoming call is a new number. EveryoneAPI updated to V1.5 and broke something, which required a fix from 3CX, as listed in the referenced thread at the top of this one. In looking over the billing records, that's also where things went from "$10 every four months" to "$15-$20 a month" despite the fact that a large bulk of numbers were already in the phone book. So it's not like this is something I didn't catch initially.

The fundamental issue is that LIDB has terrible data on cellular customers and that PBX implementations work around this through third party databases. 3CX has no agile way to work with a third party database, although they advertise that they do. You're suggesting I stand up some third-party middleware CRM to interact with EveryoneAPI, despite the fact that EveryoneAPI and 3CX advertise their interoperability. What CRM? I tried out Bitrix, Hubspot, Salesforce and Zoho as well as attempting to integrate with both of the EHRs I'm already paying for. What database? 3CX speaks to a single CRM of my choice and it speaks to Exchange... but it doesn't speak to Outlook AND Exchange AND Dynamics 365, you have to pick one. So I'm going to use a database as a caching layer between me and EveryoneAPI? Why don't I use the database that's already in 3CX, that 3CX advertises I can query to avoid CRM calls, that was working fine until July? And remember - I've got a medical practice where everyone is already on two different CRMs, they're just HIPAA-compliant medical CRMs called EHRs. I don't need another CRM, I need caller ID.

Caller ID wasn't expensive until July.

So fundamentally? I'm here reporting broken functionality and being called a whiny baby when my expense jumps 800%. How would you suggest I get this problem addressed?

 

[Evolute IT]

I'll just say it outright: if your hope is to get more help while being condescending to those who want to help, you won't get help at all.

At this point, just hire someone to do what you want, or change platform. 3CX won't change the way the integrations work for a loooong while, those a brand new from 2-3 years ago.

 

[SethTalley]

You're the one who swore at me, bro. Our first interaction so... I'm not sure what response you expected.

3CX won't change the way the integrations work for a loooong while, those a brand new from 2-3 years ago.

Things changed in July. I was invited to upgrade my API access by Telo on July 10. I declined because I figured it would break something. On July 27 Telo updated everyone and EveryoneAPI broke for everyone. I brought this to Telo's and 3CX's attention on July 27, provided log files to everyone who asked, patiently waited for a fix and thanked 3CX for the fix that was rolled out on July 31.

https://www.3cx.com/community/threads/everyoneapi-integration-not-processing-fully.75029/

Turns out that fix created a lot more server calls, which I didn't know until accounting asked me why were paying Telo $40 every couple of months. At which point I raised the issue and am being told that actually, it should have been costing me a lot of money all along.

You can't threaten to withhold help if you have yet to be, you know, helpful.

 

[SweetAction]

Most of the issues come back to "does not perform as expected."

Does not perform as you expected. The developers have made it clear it performs as they expect. Regardless of if it was documented correctly, worded right, etc - they have stated this is the current desired behavior. I'm not saying you are right or wrong, just the facts based on dev posts.

I've been beta-testing since 1998. I've got three different Centercode logins. With the software packages I've used professionally, there's an expectation that "does not perform as expected" becomes a bug report becomes a closed beta becomes an open beta becomes a release note. My experience browsing the 3CX forums indicates that 3CX is no different than most prosumer networking packages: you can ask for a feature but if you're not a dedicated-rep enterprise customer you might as well shout into a hole (and if you are an enterprise customer you don't need to ask on forums).

3CX's target audience likely drives this. I don't know, I don't work for 3CX, but that would be my guess. You'd have to ask them for their business plan.

I'd like to note that your signature offers to design and install my "large installation" phone system yet I'm here educating you about the way CID rewrites work. Had this been your system, you would have presumed the documentation represents the capabilities, worked up a proposal with your client and been left holding the bag.

Nope. I would have scoped the needs, scoped the correct solution, tested, confirmed, built proposals, presented, etc. All the standard items here. Don't for a second think that 3CX is some magical "fits every situation" solution - there isn't a piece of code on the planet that is. I've never been asked to do what you are doing with 3CX v16u7, but I am always glad to learn it won't work in advance.

The only difference here is that I'm my own client. And it's been my experience that people in your "line of work" think you're helping when in fact, you're getting educated.

I'm sad to hear that my postings did not help you/provide value. Unfortunately this happens sometimes. Like the above mentioned code, my posts are not always the correct fit/answer.

I didn't take anything out on you - I took it out on Ernesto, who is defending the notion that the option "only query CRM if contact is not found in 3CX phonebook" querying the phonebook every time a call comes in is a syntax problem, not a performance problem.

I'd also like to note that I paid EveryoneAPI $10 on January 23rd and turned it on January 24. That lasted me until May - that's four months of calls in which every incoming call is a new number. EveryoneAPI updated to V1.5 and broke something, which required a fix from 3CX, as listed in the referenced thread at the top of this one. In looking over the billing records, that's also where things went from "$10 every four months" to "$15-$20 a month" despite the fact that a large bulk of numbers were already in the phone book. So it's not like this is something I didn't catch initially.

So something broke in an update. I'm hoping you had a defined change management plan including rollback before the update was applied. Understanding you may not be able to control some system updates, I'm hoping you had a BCDR plan that covers this situation.

The fundamental issue is that LIDB has terrible data on cellular customers and that PBX implementations work around this through third party databases. 3CX has no agile way to work with a third party database, although they advertise that they do. You're suggesting I stand up some third-party middleware CRM to interact with EveryoneAPI, despite the fact that EveryoneAPI and 3CX advertise their interoperability. What CRM? I tried out Bitrix, Hubspot, Salesforce and Zoho as well as attempting to integrate with both of the EHRs I'm already paying for. What database? 3CX speaks to a single CRM of my choice and it speaks to Exchange... but it doesn't speak to Outlook AND Exchange AND Dynamics 365, you have to pick one. So I'm going to use a database as a caching layer between me and EveryoneAPI? Why don't I use the database that's already in 3CX, that 3CX advertises I can query to avoid CRM calls, that was working fine until July? And remember - I've got a medical practice where everyone is already on two different CRMs, they're just HIPAA-compliant medical CRMs called EHRs. I don't need another CRM, I need caller ID.

I'm not suggesting you stand up anything. I gave an example of what "Implement another workaround without these limits." would look like. An example of how I would maybe begin to solve this issue.

Caller ID wasn't expensive until July.

So fundamentally? I'm here reporting broken functionality and being called a whiny baby when my expense jumps 800%. How would you suggest I get this problem addressed?

I didn't call you any names. I gave 5 options the way I see it on how you can move forward towards resolution. It's up to you to decide what to do though.

 

[SethTalley]

Nope. I would have scoped the needs, scoped the correct solution, tested, confirmed, built proposals, presented, etc. All the standard items here. Don't for a second think that 3CX is some magical "fits every situation" solution - there isn't a piece of code on the planet that is. I've never been asked to do what you are doing with 3CX v16u7, but I am always glad to learn it won't work in advance.

Yeah no. Sorry. You would have done all your QAQC, rolled out a solution, had it work six months, had it break with a forced API update and be exactly where I am. You would likely attempt to work with 3CX to restore the functionality you sold. If you were then told that the functionality you were sold was never the intended functionality, you would wonder why that functionality was fixed the last time you asked.

It worked. It's now broken. It was fixed because I was able to document that it was broken. I am now documenting that it is still (albeit less) broken, and am being told that whatever it used to do was accidental and what it does now is intentional.