This quickstart gets you authenticated and making real calls against the Future Demand Client API. It’s deliberately product-agnostic — it works for both Lookout and Wave.

​
What you’ll need

1

Credentials

Request access at support.future-demand.com to get a service-account username/password bound to your partner (your tenant) on staging.
2

A base URL

Always integrate against staging first. See Environments for the host. The version prefix is /v3.
3

curl, Postman, or the [TypeScript client](/sdk/typescript-client)

Anything that can speak HTTPS and set headers.

​
1. Sign in and capture a token

BASE=https://client-api.stg.future-demand.com/api/v3

curl -s -X POST "$BASE/auth" \
  -H "Content-Type: application/json" \
  -d '{ "username": "you@partner.com", "password": "..." }'
Response (abbreviated — see Authentication for all branches including MFA and forced password change): 
{
  "AccessToken":  "eyJraWQ...",
  "IdToken":      "eyJraWQ...",
  "RefreshToken": "eyJjdHkiOiJKV1Q...",
  "ExpiresIn":    3600,
  "TokenType":    "Bearer"
}
Stash the tokens: 
export FD_ACCESS_TOKEN="eyJraWQ..."
export FD_REFRESH_TOKEN="eyJjdHkiOiJKV1Q..."

​
2. Find your partner_id

Decode the IdToken (it’s a standard JWT) and read cognito:groups. Whichever entry matches partner-id-* or fd<digits> is a partner you can act as. If you have only one, use it; if multiple, your UI should let the user choose. 
# Quick decode (jq + base64):
echo "$FD_ID_TOKEN" | cut -d. -f2 | base64 -d | jq '."cognito:groups"'
# → ["partner-id-acme", "webapp-access-group-2"]

export FD_PARTNER_ID="partner-id-acme"

​
3. Make your first authenticated calls

Every authenticated request carries two headers: 
Authorization: Bearer <AccessToken>
X-Preferred-Partner-Id: <partner_id>

# Health check — no auth needed
curl -s "$BASE/status/"

# Confirm your token + partner header are right
curl -s "$BASE/partners/" \
  -H "Authorization: Bearer $FD_ACCESS_TOKEN" \
  -H "X-Preferred-Partner-Id: $FD_PARTNER_ID"
A 200 from /partners/ returning your partner record means both your token and your X-Preferred-Partner-Id are valid.

​
4. List events (Lookout)

Events are the centre of gravity in Lookout. List the upcoming ones: 
curl -s "$BASE/events/?limit=5&descending=false" \
  -H "Authorization: Bearer $FD_ACCESS_TOKEN" \
  -H "X-Preferred-Partner-Id: $FD_PARTNER_ID"
Expected envelope (page+limit, 1-indexed): 
{
  "total": 423,
  "limit": 5,
  "page": 1,
  "pages": 85,
  "nextPage": 2,
  "prevPage": null,
  "items": [
    {
      "id": "evt_abc123",
      "name": "Concert at Olympiahalle",
      "start_at": "2026-06-12T18:30:00Z",
      "venue": "Olympiahalle München",
      "status": "active",
      "currency": "EUR"
    }
  ]
}
See Events list for the full payload, filters, and exactly how the reference Lookout webapp pages call this endpoint.

​
5. Fetch a recommendation (Affinity)

Pick one event and ask Affinity which taste clusters to target: 
EID=evt_abc123
curl -s "$BASE/events/$EID/suggested_tcs?budget=5000&goal=tickets" \
  -H "Authorization: Bearer $FD_ACCESS_TOKEN" \
  -H "X-Preferred-Partner-Id: $FD_PARTNER_ID"
This is the same call that powers Lookout’s “Suggested Targeting” card — see Recommendation Detail.

​
6. Create a campaign (Wave)

To move from insight to activation, kick off the campaign setup process: 
curl -s -X POST "$BASE/setup_processes/$EID" \
  -H "Authorization: Bearer $FD_ACCESS_TOKEN" \
  -H "X-Preferred-Partner-Id: $FD_PARTNER_ID" \
  -H "Content-Type: application/json" \
  -d '{ "goal": "tickets", "budget": 5000 }'
setup_processes/{eid} is the state-machine row that owns the Wave campaign setup for a given event. See Wave Campaigns Lifecycle for the full state model.

​
Next steps

Authentication

Token refresh, MFA, user provisioning, error codes.

Platform Model

The partner / client / event / campaign hierarchy you need in your head.

Your First Integration

A 30-minute walk-through that renders a Lookout recommendation in React.

API Reference

Every endpoint, auto-generated from OpenAPI.