​
Support portal

Submit a ticket at support.future-demand.com. The integrations queue is triaged daily during business hours (CET, Mon–Fri). For production incidents, see “Production incidents” below.

​
What to include

A good support ticket lets us resolve in minutes instead of days. Include:
  1. The x-request-id from any failing response header. This is the single most valuable piece of information.
  2. HTTP method + path that failed.
  3. Approximate timestamp in UTC.
  4. What you expected vs. what happened.
  5. Environment — staging vs production.
  6. Your partner_id — so we know which tenant to look at.
  7. Sample request body / query params (redacted).
  8. Any relevant client-side context — was a user in the middle of the campaign wizard? Mid-upload?
Template: 
Subject: [staging] 500 on POST /setup_processes/{eid}/boost

Environment: staging
Partner:     partner-id-acme
Timestamp:   2026-05-20T11:42:13Z
Request ID:  req_01HXX...
Endpoint:    POST /setup_processes/evt_abc123/boost

What happened:
  Publish returned 500 after autosave appeared to succeed.

Expected:
  201 Created with the boost task id.

Repro:
  1. Create draft via POST /setup_processes/evt_abc123
  2. PUT /setup_processes/evt_abc123 with payload below
  3. POST /setup_processes/evt_abc123/boost

Payload: (attached)

​
Production incidents

For severity-1 issues (production down, all calls failing, data loss):
  1. Open a ticket at support.future-demand.com with [P1] in the subject.
  2. Include the same fields as above.
  3. Check the Status page — if we already posted an incident, your report adds detail to ours.
For ongoing P1s we’ll open a shared Slack or Teams channel; ask in your first reply if you’d like one.

​
Office hours

Future Demand’s integrations team holds open office hours every two weeks — 30 minutes, no agenda, bring your questions. Ask your account contact for the calendar link.

​
Things we can help with

  • Auth problems, partner provisioning, MFA reset.
  • Endpoint behaviour clarifications (especially the undocumented endpoints the webapp uses).
  • Schema drift between this kit and your generated types.
  • Reviewing your integration design before you commit to it.

​
Things we can’t help with

  • Debugging your own code (we’ll point at our API behaviour, not your bug).
  • Generating ad-hoc credentials for unvetted use cases.
  • Pulling data exports manually — use the documented endpoints.

​
Feedback on this kit

Spotted something wrong, unclear, or missing in this documentation? Open an issue on the dev-kit repo or drop us a line — concrete suggestions ship within a week, usually.