Topolo Docs Topolo Platform
Open workspace

Approve booking — Calendar

Confirm a pending booking after checking its intended commitment.

Confirm a pending booking after checking its intended commitment.

Action: app_topolo_calendar.bookings.approve · POST /api/admin/bookings/{bookingId}/approve

Declared permission: app_topolo_calendar.bookings:write. For authorized Calendar users; permissions and resource access still apply.

Before you start

  • Use the current credential to confirm the production organization and inspect this exact action before preparing a call.
  • Declared permission: app_topolo_calendar.bookings:write. Permission discovery is not a grant.
  • Discover the authorized Calendar workspace and pass it as resourceType=workspace/resourceId separately from this action input. Calendar records and IDs are scoped to the selected host/workspace.
  • Validate and plan the exact payload, obtain effect-specific authorization, then execute unchanged only in a separately authorized operational task. Do not run these synthetic inputs.

Inputs and field meanings

FieldPresenceDeclared constraintMeaning
bookingIdrequiredstringBooking ID discovered through bookings.list/get for this host; never a public manage token.

Worked request and response

Source-reviewed illustration only. Nothing below was executed; all identifiers, counts, states, credentials and URLs are synthetic. Replace identifiers through discovery before any separately authorized call.

Resource context: workspace; it is not an extra action input field.

Illustrative action input:

{
  "bookingId": "bkg_example"
}

Illustrative HTTP 200 source response:

{
  "booking": {
    "id": "bkg_example",
    "hostId": "hst_example",
    "eventTypeId": "evt_example",
    "calendarUid": "bkg_example@calendar.topolo.app",
    "sequence": 1,
    "startAt": "2026-11-23T06:00:00.000Z",
    "endAt": "2026-11-23T06:30:00.000Z",
    "status": "confirmed",
    "inviteeName": "Example Invitee",
    "inviteeEmail": "invitee@example.com",
    "inviteeTimezone": "Asia/Dubai",
    "inviteeNotes": null,
    "meetingProvider": null,
    "meetingProviderRef": null,
    "createdAt": "2026-11-01T00:00:00.000Z",
    "updatedAt": "2026-11-01T00:00:00.000Z",
    "cancelledAt": null,
    "cancellationReason": null,
    "recurrenceSeriesId": null,
    "recurrenceInstanceStart": null,
    "attendees": [
      {
        "id": "att_example",
        "bookingId": "bkg_example",
        "email": "invitee@example.com",
        "name": "Example Invitee",
        "role": "invitee",
        "responseStatus": "needs_action",
        "createdAt": "2026-11-01T00:00:00.000Z",
        "updatedAt": null
      }
    ]
  }
}

The precondition for this illustration is the same ID previously had pending status on an approval-required type. The returned confirmed state is the commitment; its notification request is a separate delivery concern. This illustration starts from sequence 0 and returns sequence 1 after the source update; attendees describes the stored invitee row.

The illustrative response passes the declared structural schema. This establishes only schema compatibility, not deployed shape, values, authorization or business outcome.

Effects and verification

  • Moves a pending booking to confirmed and can create meeting references plus invitation/reminder requests.
  1. Read bookings.get for confirmed status, intended time/invitee and any delivery/provider evidence.

Refusals and recovery

Selected source refusals are listed below; runtime middleware can return additional structured errors.

HTTPErrorSupported response
403forbiddenReconcile the declared permission, organization and verified resource grant with the legitimate access owner; do not switch context to bypass a refusal.
404no_hostRead host.get; if it returns host:null, create the intended workspace host through host.update before retrying.
404not_foundList records in the selected workspace and discover the identifier again. Do not probe another workspace by guessing IDs.
409not_pendingRe-read the booking state; do not repeat approval of an already settled record.

Recovery: No action restores pending approval. Cancellation is a new effect with potential notification; it is not undo of an approval.

After an uncertain mutation, reconcile the named records and provider/delivery evidence before repeating it.

  • app_topolo_calendar.bookings.get: Read a booking and its related event type and delivery receipts.
  • app_topolo_calendar.bookings.cancel: Cancel one booking and release its slot.

Declared schemas and provenance

The hidden action guide carries these exact current declared schemas. They are not rewritten to make the illustrations pass.

Input schema:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "properties": {
    "bookingId": {
      "type": "string",
      "minLength": 1
    }
  },
  "required": [
    "bookingId"
  ],
  "additionalProperties": false
}

Output schema:

{
  "type": "object",
  "title": "Approve booking response",
  "description": "Operation result returned by bookings.approve.",
  "properties": {
    "success": {
      "type": "boolean"
    },
    "id": {
      "type": "string"
    },
    "data": {
      "oneOf": [
        {
          "type": "object",
          "title": "booking record",
          "properties": {
            "id": {
              "type": "string",
              "description": "Stable identifier when the booking exposes one."
            }
          },
          "additionalProperties": true
        },
        {
          "type": "object",
          "additionalProperties": true
        }
      ]
    },
    "result": {
      "type": "object",
      "additionalProperties": true
    },
    "message": {
      "type": "string"
    }
  },
  "additionalProperties": true,
  "x-topolo-contract-source": "derived-action-metadata",
  "x-topolo-contract-precision": "structural"
}

Source: TopoloCalendar@b378ceb73800ee1d1e6c4ff6f0b4179918cf632c, apps/api/src/routes/admin-bookings.ts. Current catalog metadata and source were compared without executing the application.

  • Source-reviewed synthetic input/response; not captured or executed.
  • Source revision is not proof of current deployment, caller access, provider connection or notification delivery.
  • The illustrative response passes the declared structural schema. This establishes only schema compatibility, not deployed shape, values, authorization or business outcome.