Integration Consumers

an integration consumer represents a system that connects to the jomablue apis, for example your crm, registration platform, or an exhibitor database each consumer holds its own access scope and its own tokens, so you can connect several systems independently and grant each one only the access it needs this article walks through creating a consumer, configuring its scope and token validity, and generating a long lived token a single consumer can be granted access across the ingest api, the updates api, and the event discovery api you can create as many consumers as you need before you start you need portal access with the trusted admin integrator or owner role if you plan to scope the consumer to specific endpoints rather than all of them, any endpoints you want to grant already created step 1 open the integration consumers tab open the settings tab at the top of the page, then click the integration consumers tab step 2 add the consumer click new consumer , give the consumer a name, and click save the name is for your own reference, so use something that identifies the connecting system, for example "crm sync" or "registration platform" leave the consumer active so its tokens can authenticate setting a consumer to inactive stops all of its tokens from authenticating without deleting them step 3 configure access locate the consumer you just created and click edit all three apis are granted by default, so narrow the scope to only what the connecting system needs ingest api grant all ingest endpoints, or select specific endpoints updates api grant all updates endpoints, or select specific endpoints event discovery api grant on or off grant only what the connecting system needs for example, a registration platform that only sends data in might be granted a single ingest endpoint, while a crm that reads data back is granted specific updates endpoints step 4 set token validity (optional) the consumer issues two kinds of token a long lived token used to request access tokens, and the short lived access tokens sent on api requests you can set a custom validity period for each to suit your security requirements, or leave them at their defaults each has a maximum it cannot exceed click save when the consumer is configured step 5 generate a long lived token locate the consumer in the list and click manage tokens , then click generate new token give the token a client identifier that labels where it will be used, so you can tell your consumer's tokens apart later step 6 copy the token the token is displayed only once, so copy the value and store it securely before leaving the screen if you lose it, generate a new token rather than trying to recover the old one treat it like a password it grants access to the consumer's scope, so keep it out of source control and shared logs this is the long lived token you exchange for a short lived access token when calling the api see authentication for the token exchange, or the ingest api authentication article if you are posting payloads in managing tokens a consumer can hold more than one long lived token at a time each token is listed with its client identifier and expiry, so you can see what is in use to rotate a token, generate a new one, move your systems over to it, then revoke the old one revoking a token stops it authenticating immediately, so rotate before the old token expires to avoid an interruption verify confirm the consumer works end to end by exchanging its long lived token for a short lived access token curl request post \\ \ url https //your instance jomablue com/integration/api/auth \\ \ header 'authorization bearer \<long lived token>' \\ \ header 'user agent your system name' \\ \ header 'accept application/json' \\ \ header 'content type application/json' a successful response returns a short lived access token in the data field send that token as the bearer token on your api requests for the full flow, see authentication