Vendors

use a vendor type ingest endpoint to create and update vendor (exhibitor/sponsor) records within an event this enables third party systems such as crms, sponsorship management platforms, or partner portals to programmatically manage vendor data in jomablue typical use cases include syncing vendor/exhibitor records from a crm or sponsorship management system creating vendor records ahead of an event from an external partner database updating vendor contact details and display information as they change upstream how it works vendor ingest works the same way as people and session ingest you send a json payload to the ingest endpoint, and jomablue maps the fields based on the endpoint's configured mapping rules the endpoint, authentication, rate limits, and request format are identical the only difference is that the endpoint is configured as a vendor type, and the mapped fields correspond to vendor attributes existing vendors can be matched using a resource id (either a formatted identifier as used in the updates api, or a direct integer record id) if no match is found, a new vendor record is created mapped fields the following fields are available for mapping within a vendor ingest endpoint field type notes resource id string formatted identifiers (e g acme/vendor/123) generate by jomablue used for matching existing vendors organisation uid string an external unique identifier for the vendor name string the vendor's name display name string the vendor's public facing display name (may differ from name) description string vendor description text active boolean whether the vendor is active truthy/falsy values are automatically normalised email domain string the vendor's email domain (e g acmecorp com) website string the vendor's website url primary contact first name string first name of the vendor's primary contact person primary contact last name string last name of the vendor's primary contact person primary contact email string email address of the vendor's primary contact person example request post /api/webhook/ingest/123e4567 e89b 12d3 a456 426614174000 authorization bearer eyjhbgcioi content type application/json accept application/json { "vendor" { "resource id" "acme/vendor/501", "organisation uid" "ext vendor 99", "name" "acme corp", "display name" "acme corporation", "description" "leading provider of cloud infrastructure solutions ", "active" true, "email domain" "acmecorp com", "website" "https //www acmecorp com", "primary contact first name" "jane", "primary contact last name" "smith", "primary contact email" "jane smith\@acmecorp com" } } considerations the same general considerations as people ingest apply requests are processed asynchronously, a 200 accepted means queued (not yet processed), and event ordering is not guaranteed existing vendors are matched by resource id if no match is found, a new vendor is created the resource id field accepts both formatted identifiers (e g acme/vendor/123 as used in the updates api) and plain integer record ids