My company has an integration with Genesys Cloud (Not an embeddable framework integration). I am being asked if our integration can work with Genesys Cloud embeddable framework customers. I don't know much about the embeddable framework, but it sounds like they can take a lot of forms and there may not be a one-size-fits-all blanket answer to that question.
Will I expect that for a customer who has an embedded framework integration to (for example) Salesforce, I should be able to get all the same data from the Genesys Cloud API as we get with Genesys Cloud? Such as accessing call details, agent state, knowing agents are set up into Business Units, etc. And how consistent might that answer be for customers using the embedded framework integrations with MS Dynamics, other CRM vendors, etc?
My concern is that some vendors may have created an integration with Genesys Cloud that only uses some of the Genesys Cloud features, but doesn't leave the same record of activity in Genesys Cloud data or maybe doesn't even rely on Genesys Cloud user accounts.. I'm not sure how much leeway developers of such integrations with the embeddable framework have to stray from the way Genesys Cloud manages users, Activity Codes, hierarchy, schedules, etc.
Can anyone correct my concern about this possibly not having a straight-forward answer, or provide more insight?
You can find documentation for the Embeddable Client's features here: https://developer.genesys.cloud/platform/embeddable-framework/. Presumably, you're not using all 2000+ API endpoints in your existing application, so you would need to identify the features that you are using and compare them to the features of the EF client to determine if it's a good fit for your requirements.
That's helpful Tim. These are now my take-aways. Are any of these incorrect?
EF has its own endpoints - simply pointing our existing integration at the EF API's root URL will not work because the endpoints and/or logic behind them may not be 1:1 with the Genesys Cloud API.
I believe you are saying that we need to check whether our integration can interop with the EF based on the available APIs/interfaces, and if so, then we'd need to publish a version using those endpoints.
If we can get our integration working with EF, then it should work for EF in Salesforce, EF in MS Dynamics, and EF in any other CRM - is this correct? The alternate would be that we need to investigate each of those scenarios independently.
I think you may be misunderstanding what the embeddable framework is. It does not have API endpoints that compete with the platform API; it's a self-contained client UI that implements the platform API, though it does have a programmable interface for you to interact with the UI app, per its documentation. Pointing your existing integration's REST API requests to make those requests to a webpage instead doesn't make sense because they're not at all the same kind of thing. Keep in mind that using the embeddable framework and making your own platform API requests are not mutually exclusive actions. Some integrations will choose to do both.
I can't tell you if the embeddable framework can replace the custom integration you've built; I don't have any knowledge of what it is or what it does. If the features offered by the embeddable framework meet your requirements, you could use it as a replacement for your current integration. If it doesn't meet your requirements, it isn't a suitable replacement for your integration.