Prepare meeting — Brigg developers

Access & visibility

Allow meetings.PrepareMeeting on your API key. Resource write permissions: core:Meeting, core:Company, core:Person.

Acting member required. Send Brigg-Act-As with an approved member account ID. The key supplies permissions; the member selects whose data is used.

The selected member must be active and approved by the credential. This selects whose private data is used; the credential supplies permissions. Private ownership and project boundaries still apply.

Set up authentication · Choose permissions

Request fields

Send a JSON object with the following fields. Required fields must be included; omit optional fields you do not need.

event_idstringRequired

ID of a synchronized CalendarEvent visible to the acting member. Find it with ListCalendarEvents. Use its Brigg record id, not the provider's event ID or a Meeting ID.

At least 1 character.

From calendar event to prepared meeting

Find the event with List calendar events under the same acting member. Connected events must have synchronized into Brigg first; this call does not connect an account or create a provider event.

Preparation creates or reuses a companion Meeting, links attendee contacts and companies, and starts background preparation and enrichment. It can therefore create customer records as well as a meeting. Existing contacts and companies are reused where matched. The credential’s grants and the selected member’s private and project data boundaries apply, along with the meeting-sharing settings.

A 200 response means the meeting identity is available. Briefs, agenda and enrichment can still be pending or fail independently, for example when background AI work cannot start. Read Get meeting for the published agenda, participants and linked records; inspect detailed preparation progress in Brigg. The public Meeting model does not expose a preparation-status field or the preparation brief. Its status is the meeting lifecycle, not preparation progress.

Retries reuse the companion rather than creating another meeting. Keep the same idempotency key for a lost response. A later deliberate preparation attempt is a new logical action and needs a new key; repeating the call is not a way to force regeneration of completed preparation.

Response

Returns 200 OK with a JSON body.

meeting_idstringRequired

ID of the companion Meeting record, which may already have existed. Read it with meetings.GetMeeting using the same member identity. This is not a preparation job ID or a signal that generated content is ready.

Errors & retries

Set BRIGG_REQUEST_ID once for each logical action. The samples send it as Idempotency-Key. Reuse the same value and body on retries, including after a timeout; a missing response does not prove the action failed.

For rate limits, follow the server’s retry guidance and back off. See HTTP errors and safe retries and limits.

HTTP status	Code	What to do
400	`invalid_json`	Send a JSON object with Content-Type: application/json.
400	`invalid_input`	Check the request fields and types. Supply a stable Idempotency-Key containing 1–200 characters.
401	`invalid_key`	The workspace API key is missing, invalid or revoked.
403	`forbidden`	Check the key’s operation and resource grants. Supply Brigg-Act-As with a member authorized by the key’s delegation grant. The selected member must be active and approved by the credential. This selects whose private data is used; the credential supplies permissions. Private ownership and project boundaries still apply.
404	`not_found`	The requested operation or resource is not available to this credential.
429	`rate_limited`	Wait for Retry-After before retrying. Reuse the original Idempotency-Key.
404	`calendar_event_not_found`	The synchronized event is missing or not visible to this acting member. Discover it with ListCalendarEvents under the same identity.

Next steps

Download OpenAPI · Versioning & retirement

JSON schemas

Use the complete schemas for validation or client generation.

Full request JSON schema

{
  "type": "object",
  "properties": {
    "event_id": {
      "type": "string",
      "minLength": 1,
      "description": "ID of a synchronized CalendarEvent visible to the acting member. Find it with ListCalendarEvents. Use its Brigg record id, not the provider's event ID or a Meeting ID."
    }
  },
  "required": [
    "event_id"
  ],
  "additionalProperties": false,
  "examples": [
    {
      "event_id": "e_calendar_kickoff"
    }
  ]
}

Full response JSON schema

{
  "type": "object",
  "properties": {
    "meeting_id": {
      "type": "string",
      "description": "ID of the companion Meeting record, which may already have existed. Read it with meetings.GetMeeting using the same member identity. This is not a preparation job ID or a signal that generated content is ready."
    }
  },
  "required": [
    "meeting_id"
  ],
  "additionalProperties": false,
  "examples": [
    {
      "meeting_id": "e_meeting_kickoff"
    }
  ]
}

Try the request

Use your API key in a server environment.

Requires BRIGG_ACT_AS: an approved member account ID.

Use a calendar event returned for this acting member. The returned meeting_id is a separate record identity.

Request

cURL

curl 'https://api.brigg.app/v1/operations/meetings.PrepareMeeting' \
  -H "Authorization: Bearer $BRIGG_API_KEY" \
  -H 'Content-Type: application/json' \
  -H "Brigg-Act-As: $BRIGG_ACT_AS" \
  -H "Idempotency-Key: $BRIGG_REQUEST_ID" \
  --data-raw '{
  "event_id": "e_calendar_kickoff"
}'

TypeScript

const actAs = process.env.BRIGG_ACT_AS;
if (!actAs) throw new Error("Set BRIGG_ACT_AS to an approved member account ID.");

const requestId = process.env.BRIGG_REQUEST_ID;
if (!requestId) throw new Error("Set BRIGG_REQUEST_ID once per action and reuse it on retries.");

const response = await fetch("https://api.brigg.app/v1/operations/meetings.PrepareMeeting", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${process.env.BRIGG_API_KEY}`,
    "Content-Type": "application/json",
    "Brigg-Act-As": actAs,
    "Idempotency-Key": requestId, // Create once per action; reuse on retries.
  },
  body: JSON.stringify({
    "event_id": "e_calendar_kickoff"
  }),
});
const result = await response.json();
if (!response.ok) throw new Error(`${response.status}: ${result.error} — ${result.message}`);
console.log(result);

Python

import json
import os
from urllib.request import Request, urlopen
from urllib.error import HTTPError

request_id = os.environ["BRIGG_REQUEST_ID"]  # Reuse for retries of this action.
payload = {
  "event_id": "e_calendar_kickoff"
}
request = Request(
    "https://api.brigg.app/v1/operations/meetings.PrepareMeeting",
    data=json.dumps(payload).encode("utf-8"),
    headers={
        "Authorization": f"Bearer {os.environ['BRIGG_API_KEY']}",
        "Content-Type": "application/json",
        "Brigg-Act-As": os.environ["BRIGG_ACT_AS"],
        "Idempotency-Key": request_id,  # Create once per action; reuse on retries.
    },
    method="POST",
)
try:
    with urlopen(request) as response:
        print(json.load(response))
except HTTPError as error:
    print(error.code, json.load(error))
    raise

200 OK Response example

{
  "meeting_id": "e_meeting_kickoff"
}

Illustrative values, not a live response.