Vero schemas out of date?

Hey!

I’ve tried implementing the Vero webhook available from R107 in the batch pipeline. I’m running R107 exactly.

It looks like the JSON schemas (and paths) might be out of date? Unless our instance is somehow special.

I’m noticing that the event property is within a context property while it’s expected to be at the root of the JSON in the schema. There’s also an unexpected ip property in the payload.

Here’s an example of an event we’re collecting (decoded from base64):

{  
   "opened_at":1544435051,
   "user_agent":"Mozilla/5.0 (...)",
   "ip":"X.X.X.X",
   "type":"opened",
   "user":{  
      "id":"111",
      "email":"random@email.com"
   },
   "campaign":{  
      "id":198720,
      "type":"behavioural",
      "name":"User onboarding",
      "subject":"Email subject line",
      "trigger-event":"sign-up",
      "permalink":"http://app.getvero.com/email/...",
      "variation":"Control",
      "tags":""
   },
   "context":{  
      "event":{  
         "triggered_at":1544094560,
         "data":{  
            "cache_bust":"2216404-9c501a80658e5025968ce57226308752"
         }
      }
   }
}

And here’s the link to the 1-0-0 schema for the opened event:

You can see that there’s no mention of the context and ip properties in the 1-0-0 schema.
This happens on 100% of the events and all the event types (delivered, bounced, clicked etc …). As a result, the enrichment step fails for all Vero events (schema validation failure).

1- First question: could anyone confirm this observation?

2- Second question: I can see that ids are usually integers in the payload but described as strings in the schema, is there any conversion happening that would let these integers be valid strings?

3- Third and side question: the schemas/paths for Vero aren’t available on iglucentral.com right?
I’m trying to fix the schemas and I’m wondering if I should make our own iglu server the #1 priority (to overwrite the schemas on iglucentral.com, which is the current #1).

Hi @Timmycarbone,

It seems that Vero changed the payload on their end as the “IP” field and the nested “event” object were not in the original payload when the schema was created. I’ve tested an “email_open” webhook and see that there is indeed now an “IP” field present in the payload.

As for the “campaign.id” field being strings in the schema, that is a breaking bug. A patch for the schema can be found here.

Peter

Thanks @peter!

Will get the schemas fixed on my side then. If they work fine I’ll submit a PR I guess.

Cheers!