Skip to content
English
  • There are no suggestions because the search field is empty.

Future Demand Ticketing & CRM Integration Interface Specification

1 Purpose

This article defines the technical interface between Future Demand and third‑party ticketing/CRM platforms. It describes

  • how event, sales and customer data can be delivered to FD, and

  • how FD audience segments from Backhaul or Sentinel can be written back to a ticketing or CRM system.

2 Data model

2.1 Mandatory and recommended fields

Domain Field Type Format / example Mandatory
Event event_id string EVT‑12345
  title string Otello
  date date (ISO‑8601) 2025‑10‑03
  time time (HH:MM:SS) 19:30:00
  venue string State Opera
  hall string Main Hall
  capacity integer 1250
  city string Berlin
Sale invoice_number string A1234
  purchase_datetime datetime (UTC) 2025‑04‑15T11:08:42Z
  ticket_category enum regular, VIP, subscription, comp
  quantity integer 2
  sales_price decimal 89.00
  base_price decimal 75.00 recommended
  currency ISO 4217 EUR
Customer customer_id string C‑9988
  email string jane.doe@example.com
  salutation string Ms recommended
  first_name string Jane recommended
  last_name string Doe recommended
  street string Main St 12A recommended
  post_code string 10115 recommended
  ad_opt_out boolean true / false highly recommended

A full list of usable fields is available in the Help‑Center article Which data points are necessary to enable full functionality?

2.2 Program information

For opera, classical music or theatre repertoires please include work title, composer and cast information together with the event record.

2.3 Data relationships

  • Every sale must reference a valid event_id.

  • Anonymous sales are possible—use the customer_id ANON.

  • Duplicate detection: date + time + hall.

3 Transport options

Mode Direction Description Typical latency
HTTPS webhook Ticketing → FD Your system POSTs a transaction payload to our endpoint immediately. Real‑time (< 1 s)
REST API (pull) FD → Ticketing FD fetches data from your REST endpoints with cursor‑based pagination. Near real‑time / scheduled
XML / JSON feed FD → Ticketing FD consumes hourly or daily static files at a given URL. Batch
CSV via SFTP Ticketing → FD Your system drops CSV files on an agreed SFTP folder; FD collects and acknowledges. Batch

3.1 Endpoint overview

  • Webhook: POST https://api.future-demand.com/v1/{client_id}/ingest

All endpoints enforce TLS 1.2+.

4 Authentication and security

Transport Method Details
Webhook & REST Bearer API key One key per environment (TEST / PROD) sent in the Authorization header
SFTP User + Password Provided by Future Demand
Audience push App Key + Secure Token Headers X‑App‑Key and X‑Secure‑Token as provided by the ticketing/CRM system

5 Audience push (Backhaul / Sentinel)

When FD writes a segment back to your system the request contains:

  • segment_name – e.g. Verdi Lovers – Berlin

  • description – free‑text description of the goal

  • customers – list of customer_id and/or email pairs

The receiving endpoint should return HTTP 201 with a unique segment_id on success.

6 Error handling

Code Meaning Retry logic
202 Accepted, queued for processing
400 Validation error Correct payload, resend
401 / 403 Authentication / authorisation failed Refresh token
409 Duplicate invoice_number Perform update instead of insert
500 Internal error Exponential back‑off, max 6 attempts

7 Rate limits

  • Webhook: 500 requests per minute, burst up to 1000.

  • Audience push: 50 segments per hour. Higher limits on request.

8 Change management

Breaking changes are published under a new base path /v2/ and announced at least 60 days in advance. Additive, backward‑compatible extensions do not create a new major version.

9 Support & contacts

For technical questions please contact success@future-demand.com or reach out to your Customer Success Manager.


Appendix A — Mapping cheat‑sheet

Ticketing field FD field
EventNo event_id
EventDate date
EventTime time
TicketType ticket_category
PriceGross sales_price