Vendor Mapping

a vendor ingest creates or updates a vendor (exhibitor, sponsor, or partner) in an event from a json payload — usually a webhook from your crm or exhibitor system it's a small, flat mapping copy it, point the paths at your own payload, and you're done how it works a field map is a list of rules each rule reads a value from your payload (keymatch) and writes it to a jomablue vendor field (type) point each keymatch at wherever the value lives in your own payload, using dot notation (e g vendor primarycontact email) vendors are matched by resource id first, then by organisation uid if neither matches an existing vendor, a new one is created new vendors must have a name anything in the payload that no rule references is ignored the mapping \[ { "type" "resource id", "keymatch" "resource id" }, { "type" "organisation uid", "keymatch" "organisation uid" }, { "type" "name", "keymatch" "name" }, { "type" "display name", "keymatch" "display name" }, { "type" "description", "keymatch" "description" }, { "type" "active", "keymatch" "active" }, { "type" "email domain", "keymatch" "email domain" }, { "type" "website", "keymatch" "website" }, { "type" "primary contact first name", "keymatch" "primary contact first name" }, { "type" "primary contact last name", "keymatch" "primary contact last name" }, { "type" "primary contact email", "keymatch" "primary contact email" } ] the fields resource id — the vendor's internal id, and the primary way vendors are matched accepts a plain integer or a formatted string like app name/vendor/123 (the trailing number is used) organisation uid — your own identifier for the vendor used for matching when there's no resource id, and stored on the vendor either way name — the vendor name required to create a new vendor display name — the name shown publicly defaults to name for new vendors if you don't provide it description — a description of the vendor active — whether the vendor is active accepts true, 1, "yes", "true", "1" (case insensitive); anything else is false new vendors default to active if you don't map this email domain — the vendor's email domain (e g northwindlabs com) website — the vendor's website url primary contact first name / primary contact last name / primary contact email — the vendor's main point of contact in the example these read from a nested primary contact object in the payload worked example payload { "resource id" "expo/vendor/58", "organisation uid" "vendor 58", "name" "northwind labs", "display name" "northwind", "description" "cloud tooling for event teams ", "active" true, "email domain" "northwindlabs com", "website" "https //northwindlabs com", "primary contact" { "first name" "sam", "last name" "okafor", "email" "sam okafor\@northwindlabs com" } } result vendor 58 (matched by resource id, else created) named "northwind labs", shown as "northwind", active, with the given description, email domain, and website, and a primary contact of sam okafor send the same resource id again with new values and the vendor is updated in place validation you can validate the payload before it's mapped each rule targets a payload key and applies one or more checks separated by |; a payload that fails is rejected before anything is created { "resource id" "required without\ organisation uid", "organisation uid" "required without\ resource id|string", "name" "required|string", "primary contact first name" "nullable|string", "primary contact last name" "nullable|string", "primary contact email" "nullable|email" } required without — at least one identifier is needed resource id is required only when organisation uid is absent, and vice versa required — name must be present to create a vendor nullable — checked only when present the contact name fields must be strings, and the contact email must be a valid email match these keys to your own payload paths