Skip to content
Bloomod
Sign inGet started

Event API

Planned

A planned API for connected event workflows.

API and webhooks are planned capabilities for connecting Events, attendees, calendar invitations and RSVP updates. No production API is available yet.

Get started freeSee example structure

Embedded registration forms are included on every plan.

curl
curl https://api.bloomod.com/v1/events/evt_0182/invitations \
  -H "Authorization: Bearer $BLOOMOD_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "attendee_id": "att_0182",
    "requires_approval": true
  }'

# Planned example only
# No production endpoint is available
node
const res = await fetch("https://api.bloomod.com/v1/events/evt_0182/invitations", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${process.env.BLOOMOD_KEY}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    attendee_id: "att_0182",
    requires_approval: true
  })
});

const invite = await res.json();
python
import os, requests

res = requests.post(
    "https://api.bloomod.com/v1/events/evt_0182/invitations",
    headers={"Authorization": f"Bearer {os.environ['BLOOMOD_KEY']}"},
    json={
        "attendee_id": "att_0182",
        "requires_approval": True,
    },
)

invite = res.json()

Planned API example. Names and paths may change before early access.

Example API structure

Proposed resources follow the event workflow.

Planned example API resources
MethodPathDoesApproval
POST/v1/eventsCreate an eventn/a
POST/v1/events/{event}/attendeesAdd an attendee to one eventn/a
PATCH/v1/events/{event}/attendees/{attendee}Update attendee or verification statusn/a
POST/v1/events/{event}/invitationsQueue a calendar invitationRequired
GET/v1/events/{event}/invitationsRead delivery and RSVP statusn/a
DELETE/v1/events/{event}/invitations/{invitation}Request an event cancellation updateRequired
In the proposed model, invitation writes enter a review queue. This is an example design, not a promise of final paths, response codes or production availability.

Planned authentication

Proposed scoped keys limit each integration.

Early-access credentials are expected to carry narrow scopes, so attendee access, invitation writes and webhook management can be separated.

  • Bearer-style authentication is proposed
  • Separate test and live access is planned
  • Per-key scopes and rotation are planned
  • Credential use should appear in account activity

  • Scope

    attendees:write

    Create and update event attendees and verification status.

  • Scope

    invites:write

    Queue Event invitations for approval.

  • Scope

    invites:read

    Read lifecycle stage and RSVP state.

  • Scope

    webhooks:manage

    Register endpoints for RSVP and delivery events.

Planned webhooks

Event and RSVP updates, without polling.

Proposed webhooks would let integrations receive selected Event, attendee, invitation and RSVP changes. No live webhook service is attached today.

event.createdattendee.registeredattendee.verifiedinvitation.sentrsvp.updated

POST your-endpoint

{
  "type": "rsvp.updated",
  "created": "2026-08-13T05:12:44Z",
  "data": {
    "event_id": "evt_0182",
    "attendee_id": "att_0182",
    "invitation_id": "inv_7Kq2",
    "rsvp_status": "accepted",
    "calendar": "google"
  }
}

Planned operating model

Operational limits will be published before launch.

Scoped
Access by integration purpose
Queued
Invitation writes enter review
Signed
Webhook verification is planned
Published
Limits documented before availability

Final authentication, paths, rate limits and webhook behavior will be documented when early access opens. Calendar providers may also apply their own quotas and anti-abuse limits.

The planned API, answered.

Something not covered here? Write to [email protected].

Is the Bloomod API available now?

No. The API and webhooks described on this page are planned. There is no production API, no public endpoint and no sandbox yet, and nothing here should be built against as though it were live.

What will the API cover?

The resources follow the workflow the product already has: Events, attendees, calendar invitations and RSVP updates. Webhooks are planned so that event and RSVP changes can be received without polling.

How will access be controlled?

Through scoped keys, so an integration is granted only the access it needs rather than the whole workspace.

When will rate limits be published?

Operational limits will be published before launch rather than discovered in production. If an integration matters to you, tell us what it needs to do and it will inform what ships first.