Custom Attributes

custom_attributes is a free-form string map you attach at create_bot. MeetStream never interprets it — it just echoes it back everywhere, which makes it the backbone of routing, attribution, and multi-tenant bookkeeping.

Set at create time

1
{
2
  "meeting_link": "https://meet.google.com/abc-defg-hij",
3
  "bot_name": "Notetaker",
4
  "custom_attributes": {
5
    "customer_id": "cus_8842",
6
    "environment": "production",
7
    "job_id": "meeting-sync-1234"
8
  }
9
}

CLI: meetstream bot create <link> --attr customer_id=cus_8842 --attr environment=production.

Where it comes back

1. Every webhook event. Each delivery carries your custom_attributes verbatim — route events to the right tenant handler without any lookup table:

1
{ "event": "bot.stopped", "bot_id": "...", "bot_status": "Stopped",
2
  "custom_attributes": { "customer_id": "cus_8842", "environment": "production" } }

2. List Bots filtering. Query your fleet by attribute with custom_attr[...] params (conditions combine with AND):

$
curl "https://api.meetstream.ai/api/v1/bots?custom_attr[customer_id]=cus_8842&custom_attr[environment]=production" \
>
  -H "Authorization: Token <YOUR_API_KEY>"

3. Status and detail endpoints return them alongside the bot’s state.

4. The Usage dashboard shows per-bot metadata in its cost breakdown — so per-customer usage attribution falls out for free. See Usage & Retention.

Patterns that work well

• Multi-tenant routing: customer_id on every bot; webhook handlers dispatch on it with zero database reads.
• Idempotent job tracking: put your queue’s job_id in attributes, and pair with a deduplication_key so retries never double-book the meeting.
• Environment separation: tag environment: staging|production and filter List Bots per environment — or go further and use separate workspaces with separate keys.