Migrating from API v1 to v3

API v3 is the partner (OEM) API for events and companies. It uses the same authentication as v1 and the same company access; only the base path changes from /api/v1 to /api/v3. v1 stays available, but its register endpoint is deprecated because it does not apply the event's registration settings.

Authentication (unchanged)

POST https://api.introvoke.com/api/oauth/token
Content-Type: application/json

{
  "client_id": "<your client id>",
  "client_secret": "<your client secret>",
  "audience": "https://www.introvoke.com/api",
  "grant_type": "client_credentials"
}

Send the token as Authorization: Bearer <token>. A token acts on its own company and every sub-company.

What changed

v1	v3	What is different
`POST /v1/event/{id}/registrant`	`POST /v3/event/{id}/registrant`	Registration modes are enforced exactly as on the registration form, and the reply tells you what happened (see below).
`GET /v1/event/{id}/registrants`	`GET /v3/event/{id}/registrants`	Every row carries a `status`: `registered`, `pending_approval`, `waitlisted`, `rejected`, `refunded`, `invited`, `declined`, `cancelled`.
`GET /v1/event/{id}`	`GET /v3/event/{id}`	Returns the full event, including the complete `registration` settings object and, for series sessions, `childEventSettings.visibility`.
`POST /v1/event/{id}`	`POST /v3/event/{id}`	Accepts every registration setting of the dashboard. Nested objects merge: sending one setting no longer clears the others. Unknown fields are rejected with 400.
`POST /v1/event/create`	`POST /v3/event/create`	Same required fields; any setting the update accepts can be set at creation.
–	`POST /v3/event/{parentId}/session`	New: create a session inside a series. Sessions are private until published.
`GET /v1/company/{id}/events`	`GET /v3/company/{id}/events`	Same filters. Unpublished sessions are left out unless `includePrivate=true`, so an in-app listing never shows a private session.

Registering an attendee

POST https://api.introvoke.com/api/v3/event/{eventId}/registrant
Authorization: Bearer <token>
Content-Type: application/json

{
  "name": "Ada Lovelace",
  "email": "[email protected]",
  "metadata": { "crmId": "0031" }
}

Read the response status and the status field:

HTTP	`status`	Meaning
200	absent	Registered. `join_url`, `joinCode` and `authToken` are set.
200	`approval_required`	Created, waiting for the organizer's approval. `join_url` is empty until approved.
200	`waitlisted`	The event is full; the attendee is on the waitlist.
200	`rejected` / `refunded`	An earlier registration for this email blocks a new one. Only `status` and `message` are returned.
204	–	This email is already registered. Send `"resendInvite": true` to get the registration back with a 200 instead.
400	–	Refused. The body is `{ "hasError": true, "path": "...", "errorMessage": "..." }` where `path` is `email` (invitation-only, blocked or not allowed domain, personal email), `maxRegistrationsCount` (full, no waitlist), `ticketTypeId` (ticket unavailable, or a paid ticket: tickets cannot be bought through the API, send the attendee to the registration page) or `name`. When registration is disabled or the event is cancelled the body is a plain message.
404	–	The event does not exist or is not in your company hierarchy.

message carries the organizer's own wording for the status, so you can show it to the attendee as-is.

Accepted body fields: name, email, firstName, lastName, metadata, customQuestionsAnswers, formUrl, ticketTypeId, registerFor, sessionEventIds, resendInvite, sendEmails. Required custom questions must be answered in customQuestionsAnswers; the API applies the same rules as the form.

Emails

Sequel sends no confirmation, approval or waitlist emails for OEM customers' events (partners send their own). To have Sequel send them for one registration, add "sendEmails": true.

Managing registration settings

Everything on the dashboard's Registration tab is on registration in GET /v3/event/{id}, and can be changed with POST /v3/event/{id}:

POST https://api.introvoke.com/api/v3/event/{eventId}
Authorization: Bearer <token>
Content-Type: application/json

{
  "registration": {
    "requireApproval": { "enabled": true, "message": "We review every registration." },
    "maxRegistrations": { "count": 200, "waitlistEnabled": true },
    "blockedEmails": { "allowOnlyBusinessEmails": true, "customDomains": ["competitor.com"] }
  }
}

Only the settings you send change; the rest of registration is kept. Other settings: enabled / outsideOfAppEnabled (registration mode), whitelistedEmails, inviteEmailsOnly, captchaEnabled, seriesRegistrationMode, customQuestions, terms, privacy, formText, ticketing.

Series and private sessions

Create a session in a series with POST /v3/event/{parentId}/session (childEventSessionName, startDate, endDate, timezone, optional defaultVisibility). A new session is private: it is not returned by GET /v3/company/{id}/events and cannot be joined. Publish it with "defaultVisibility": "public" at creation, or later:

POST https://api.introvoke.com/api/v3/event/{sessionId}
{ "childEventSettings": { "visibility": "public" } }

If your app lists events from the API, switch the listing to GET /v3/company/{id}/events so private sessions stop appearing. Pass includePrivate=true only where you need them (for example an admin tool).

Recommended order

Switch the registration call to v3 and handle status (this is what makes the registration cap, approval and business-email settings take effect).
Move the event listing to v3 so unpublished sessions disappear from your app.
Use POST /v3/event/{parentId}/session to create series sessions, publishing them when ready.
Use GET / POST /v3/event/{id} to read and manage registration settings instead of the dashboard.