...

Overview

doo provides a way to synchronize doo entities an event-driven API that allows synchronizing doo resources to external systems using webhooks. Webhooks are user-defined HTTP callbacks. Each time an entity a resource is changed, doo will call the respective API endpoint of the external system.Webhooks configurations will be attached to an entire organization with all its events. The payload of event and order webhooks will contain the event_id so you can decide which webhooks to process.

Basic webhook flow

1. A user creates/edits/remove an entity change resource in doo, which fires one or more triggerswebhooks

2. For each triggerwebhook, if an external webhook API endpoint has been configured:

   1. doo authenticates with the external authorization endpoint to retrieve an access token (optional);

   2. doo sends a POST request (optionally authorized) webhook request to the external endpoint with the entity resource in a its payload;

   3. external system processes webhook payload as required.

Typical system setup

A typical integration scenario consists of the customer's Content Management System (CMS), which uses doo widgets to enable attendees to book, and the customer's Customer Relationship Management (CRM) as an external system, which provides endpoints for doo webhooks (authorization, event, and order).

...

3.3. Webhook endpoints (to be provided by an external system) 

Curl example of the webhook HTTP POST request to external endpoint: 

...

...

...

<access_token> - should be provided by the external system for doo (before every webhook push to the external endpoint, optional)

...

<webhook_payload_json> - payload object provided by doo

...

The payload which doo will send with each webhook request depends on the entity: 

• Event - EventsIdEditGetResponse model

• Order - OrdersIdGetResponse model

• Attendee -

• Contact -

...

3.4. Webhook payload

3.4.1 Entity identification

Use these IDs in order to identify if a webhook refers to the same entity:

Event

• EventsIdEditGetResponse model → id and OrdersIdGetResponse model → event → id

• Available ticket categories

  • OrdersIdGetResponse model → ticket_categories → id

...

1. Event from doo can be bound to a user from an external system

   • For each user in doo, we can configure an external user ID and it will be included in the event payload (EventsIdEditGetResponse object, external_user_id property in the root scope of the JSON object)

2. Booker from doo can be bound to a customer from an external system

   1. A customer ID can be passed from the external CRM to doo via prefill in the widget snippet or through doo email campaigns (see more details in Widgets)

      1. doo will pass the ID back to the external system in webhooks (OrdersIdGetResponse object, external_customer_id in the root scope of the JSON object)

To get more information about bindings, contact doo (kundenservice@doo.net)

...