Hello, I understand that there is information for the top-level schema data and there is information about each EventBridge topic. However, they provide example data. Is there a link or location where I can actually get the json schema for the top-level and all of the event details. This would be really useful for schema validation.
Thanks!
Hello, please see https://developer.genesys.cloud/notificationsalerts/notifications/available-topics
Hello, Thanks!
Is there a schema definition for the "top-level" json? Perhaps, one that includes references to each event-body type?
The event schema is documented for each event:
If you're looking for the raw data that's used to generate that page, use the API endpoint referenced at the top.
Yep, understood about where I could get it for each event type. Was looking for the top-level one. However, pointing me to the API call definitely helped me get all the schemas in "one go". Thanks!
I suppose I don't fully understand what you're looking for; "top-level schema" isn't a specific term we use. What information or format are you trying to find that's not on the web page and not returned by the API?
So, I am trying to get all of these schemas loaded into an internal schema registry for Kafka ingestion. As you are aware, the eventbridge data can take many different formats. However, the payload will always have the following but the detail are different for each topic.
{
"version": "0",
"id": "12345678-2fc2-722c-43f3-54530b9f654b",
"detail-type": "v2.users.{id}.presence",
"source": "aws.partner/genesys.com/cloud/12345678-ea34-4e5e-aa41-0f45a4fd81c2/test-event-source",
"account": "123456789012",
"time": "2020-06-08T14:37:21Z",
"region": "us-east-1",
"resources": [],
"detail":
{
"topicName": "v2.users.12345678-d367-4bb3-a54a-454929aa4422.presence",
"timestamp": "2020-06-08T14:37:21.123Z",
"version": "2",
"eventBody": {
"source": "PURECLOUD",
"presenceDefinition": { "id": "12345678-942f-489d-9700-5f9bcdcdae9b", "systemPresence": "AVAILABLE" },
"primary": true,
"message": "",
"modifiedDate": "2020-06-08T14:37:19.061Z"
},
"metadata": { "CorrelationId": "12345678-80c1-41d0-af8f-c3028f517f82" }
}
}
I don't see a particular schema definition for what is outside of the event body node. Just schema definitions of what could be in the event body. Yes, I could possibly create a schema definition on my own. However, I am running into issues with Kafka and the "any" types as the JsonSchema serializer/deserializer I am using requires strongly-typed structure.
I was looking for the easiest/most straightforward way of defining all the possible event types I can receive from event bridge. utilizing what is in the base payload as well as what is inside the eventbody which contains the topic level json, as defined by the schema. As you can see this might could be pretty laborious if I needed to define all topics.
Just looking to make our journey from engage to cloud a little shorter. 
Ah, I see what you mean now. That top-level payload is defined by Amazon. We show an example here: https://developer.genesys.cloud/notificationsalerts/notifications/event-bridge#event-schema, and link out to AWS for details about their payload structure: Amazon EventBridge events - Amazon EventBridge. The detail object is where the payloads from /availabletopics will be used.
Hi Tim, thank you for the information. I have been trying to solve to get schema information for all of the Genesys events so I can do schema validation for the EventBridge messages that come in to our OnPrem Kafka cluster. You lead me down the path of looking into the EventBridge Schema service provided by AWS. I have wired everything up and did the logic. Everything looked great in local development but I quickly learned there were some events going to dead-letter. When I researched them I discovered that the event schema that AWS generates based on the GenesysCloud messages change way more frequent than I originally thought. For instance, in the past couple of days there are over 230 schema changes to the v2.telephony.providers.edges.trunks{id} topic alone. As a matter of fact, a new schema is created on almost every event received from Genesys Cloud.
The schema that AWS creates says that optionStateTime is a required field but every other event I get from Genesys Cloud doesn't have this field. When I look at the schema in the GC docs, I see that it is a string. This wasn't the only detail-event that had these inconsistencies.
With this "dynamic" payload structure, I cannot possibly validate what is coming from Genesys Cloud. Is this something that you guys have noticed or are aware of? Again, I'm trying to do this in a programmatic fashion so we do not have to rely on monitoring releases for when schemas change.
Thanks!
This is definitely not true from the Genesys side. I think what's happening is that many notification topics only include relevant parts of the schema in the payload when issuing notification events; this is considered a feature. If AWS is trying to reverse engineer a schema from the JSON payload on each event, I would expect it to generate varying schemas for the same topic over time. How much variance exists depends on the specific topic. For example, presence topics are likely pretty consistent since I believe they send nearly all of the schema on every update since there's not much extra in there. Conversation events, on the other hand, aggressively leave out parts of the conversation object that aren't relevant to the update to reduce payload size, allowing greater backend system throughput.
The notification schemas don't document which properties are required, which means that all should be considered optional. Your schema checking should be tolerant of this; the payload might have less data than the schema, but it won't have more.
That should virtually never happen. We go to great lengths to ensure that we don't make breaking changes in our public interfaces (i.e. take something away, we add things regularly). If there are breaks, they'll be announced in the announcement category on this forum. The policy for these changes can be found here: https://developer.genesys.cloud/platform/api/changemanagement.
OK, Thanks Tim. After going through all the schemas trying to determine which properties were optional and changing the type to be oneOf with an array that includes "null" type to get around the "optional" properties that Confluent Kafka restricts I have ran into a new concern. What should I do with inconsistencies. For example, the documentation says a property is one type:
"any" type is not a valid json schema type. Which leads to the question, what Json schema draft is Genesys adopting in these schema references? Thanks!
There's a little info lost when converting the avro schema provided by the API to an OpenAPI format that's used internally in the site to generate those JSON examples. OpenAPI doesn't support an "any" type and so it's getting mapped to a string. The avro schema is going to be the most pedantically correct.
Thanks for the info. I would love to get the avro schemas. I wouldn't have any conversions or problems if they were available. My front end is python and we use pydantic validation.
You are. That's what's in your second screenshot above.
I apologize for my confusion. I thought what I was getting from the API was OpenAPI format. That is what I was getting from AWS derived schemas and made a wrong assumption.
Hi. Tim, I hate to keep bringing you back to this topic but I don't see how this is in avro format. I don't see anything in the api nor in my screenshot relating to fields and the name definitions that are in an avro schema format. I know I am missing something I just don't know where.
