[Bug] Search Conversations Query - Performance Issues

[i-am-rad]

🐛 Describe the Bug

Search conversations API
-"query" field
-accepts a phone or an email address
-used to find the conversationId

Performance issues. If you create a conversation and immediately search using its phone or email address it does not return the conversationId. Another conversation coming in will see no conversation on search, attempt to create conversation, then see errors the conversationId already exists.

📍 Location

https://marketplace.gohighlevel.com/docs/ghl/conversations/search-conversation

✅ Expected Behavior

Return the conversationId.

💻 Screenshots or Code Samples

Search Conversations: (locationId: DjpolQ8Je7u1t7OauwFL)

{
    "query": "+1757redacted",
    "contactId": "rTDJGD7SjqDamyzrk5UW"
}

Response:

{
    "conversations": [],
    "total": 0,
    "traceId": "3306f3ea-57c4-4aa6-99fb-bfa4275a62ed"
}

Create Conversation right after:

{
    "contactId": "rTDJGD7SjqDamyzrk5UW"
}

Response:
[400] HttpException Conversation with the contact id:rTDJGD7SjqDamyzrk5UW already exists! cbf699cb-28e6-42d8-b49b-f6731af2560b

🧠 Additional Context

Proposed solutions in the interim:

Create Conversation API
-If you return an error the conversationId already exists give us the conversationId in the response
-Treat it like "upsert" and don't return an error if it exists and just give us the output payload

[i-am-rad]

We also need some developer quality of life improvements on some of these apis and a reduction in API usage / optimization for conversation providers:

Search Conversations API:
Ideally you guys also return the contactId on this api. Current behavior is:

query: phone or email address

1. Search conversations -> Exists -> Returns payload with contactId
2. Search conversations -> Contact Exists but Conversation Doesn't exist -> Empty/Total zero (this needs update)
3. Search conversations -> Contact Doesn't exist and Conversation Doesn't exist -> Empty/Total zero

If you add the contactId to the search conversations result then it helps eliminate the need to do a follow on create/upsert the contact prior to creating the conversation. This saves us API calls and a lot of usage on your API.

Create Conversation API Issue:
-Create Conversation - Already Exists -> 400 Error message. ConversationId not returned.

Desired Behavior:
-Return 200 and payload conversationId if it exists
-Change "success" to false to indicate that its not a new conversationId or some other key. Upsert uses "new" true/false

{
"success": true,
"conversation": {
"id": "tDtDnQdgm2LXpyiqYvZ6",
"dateUpdated": "2023-10-01T12:00:00Z",
"dateAdded": "2023-10-01T12:00:00Z",
"deleted": false,
"contactId": "ve9EPM428kjkvShlRW1KT",
"locationId": "ve9EPM428kjkvShlRW1KT",
"lastMessageDate": "2023-10-01T12:00:00Z",
"assignedTo": "ve9EPM428kjkvShlRW1KT"
}
}

[rmajidy]

2nd this — same issue is happening to us as well (was going to make another issue but found this).

When searching for a specific conversation from a contact:

GET https://services.leadconnectorhq.com/conversations/search?contactId=nhuU85Di6mwPR5S3kE1I

...returns conversations with an empty array:

Conversations found: {
  "conversations": [],
  "total": 0,
  "traceId": "fae801c4-afa1-4071-a448-4c16b8d403f2"
}

We need to find the conversation ID, but we get a successful response without any object to grab the ID from.

So if we try to create a conversation:

Error creating conversation: Error: Failed to create conversation: 400, message: {
  "status": 400,
  "message": "Conversation with the contact id:nhuU85Di6mwPR5S3kE1I already exists!",
  "name": "HttpException",
  "traceId": "ce62a157-e689-49af-a9fc-88b0e95c3285"
}

[i-am-rad]

We also want it when you search conversations to return the contacts phone, email, firstName, lastName, and full name. This reduces the need to go and upsert/get the contact. This may result in dramatic reductions in API usage to eliminate unnecessary upserts so the more data you give back on search conversations the better. Same thing on create conversation. Give back that data to reduce developers hitting upsert.

[Cobeas]

We also want it when you search conversations to return the contacts phone, email, firstName, lastName, and full name. This reduces the need to go and upsert/get the contact. This may result in dramatic reductions in API usage to eliminate unnecessary upserts so the more data you give back on search conversations the better. Same thing on create conversation. Give back that data to reduce developers hitting upsert.

But please don't give the full contact as a response, sorry but some payloads are enormous. Know what you're asking them

[balaji-ghl]

@i-am-rad The delay in reflecting new conversations in the search results is expected, as it’s a limitation of inverted indexing. We’ve updated the Create Conversation API to include the conversationId in the response when an existing conversation is found.

[i-am-rad]

Excellent update. Can you include very basic contact info like: first/last, phone, and email when both search conversations and create conversation responds? Reason why:

Path A): Upsert / search conversations by contactId / exists. / add inbound message
Path B) Upsert / search conversations by contactId / doesnt exist. Create conversation / Add inbound message
Path C) Upsert / search conversations by contactId / doesnt exist. Create conversation (failed but fixed result) / Add inbound message
Path D) Search conversations by phone / exists / add inbound message
Path E) Search conversations by phone / doesnt exist / Upsert / create conversation, Add inbound message
Path F) Search conversations by phone / doesnt exist / create conversation (failed but fixed result) add inbound message

So on path E, you notice if search conversations found a contact record but does not find the conversation that can save a lot of upserts to give us a contact Id, first/last/phone/email to use to create conversation and update our db if we need to. If you add that little bit of contact info it can save an API call which at scale can be pretty big.

[i-am-rad]

This also means a path towards best practices. So by giving us this little bit of extra fields you can now publish a doc to tell people the least amount of api calls to facilitate messaging.