How to enable an account as a speaker

How to enable an account as a speaker

Use this guide when you need to grant the speaker role to a participant account for a given event. This is a prerequisite before the account can be assigned as a speaker on any session via POST /api/v2/sessions/set.


Request — enable speaker role

Bash
curl -X POST "https://your-event-domain.com/api/v2/account/set" \
  -H "Authorization: Bearer your_api_key_here" \
  -F "event_id=7" \
  -F "email=jane.doe@example.com" \
  -F "speaker=true"

Request — remove speaker role

Bash
curl -X POST "https://your-event-domain.com/api/v2/account/set" \
  -H "Authorization: Bearer your_api_key_here" \
  -F "event_id=7" \
  -F "email=jane.doe@example.com" \
  -F "speaker=false"

Response

JSON
{
  "code": 200,
  "errors": null,
  "data": {
    "id": 18860,
    "email": "jane.doe@example.com",
    "status": "updated",
    "external_id": null,
    "speaker": true
  }
}

The speaker: true field in the response confirms the role was attached.


What happens next

Once speaker=true is set on an account, the account becomes available in the speaker pool for this event. You can then:

  1. Assign them to specific sessions via POST /api/v2/sessions/set using the speakers[] parameter (pass the account's ID or email)

  2. Retrieve the full list of speakers for a session via GET /api/v2/sessions/getSpeakers

Note: Setting speaker=true registers the account as a speaker for the event — it does not automatically assign them to any session. Session assignment is a separate step via POST /api/v2/sessions/set.


Notes

  • speaker=true and speaker=false can be combined with other account/set fields in the same request

  • This is event-scoped — the same account can be a speaker on one event but not another