Calendar Event Confirmations

Reference for the calendar_event_confirmations resource. Requests follow the conventions in Requests and Responses; fields you receive and may write are filtered by your user's permissions, so responses can contain a subset of the fields below.

Operations

Not available as a standard REST operation for this resource: create, update, delete — such requests return 402 feature_not_enabled or 403 permission_denied (see the actions above for this resource's write path).

How it works

calendar_event_confirmations record that an appointment was confirmed — each row pins a confirmation_status_id (Not Confirmed / Accepted / Cancelled) and a confirmation_type_id (Phone / Email / Direct) to an appointment, with optional notes. Confirmations are append-only: recording a confirmation writes a new row, and the most recent one is the appointment's current confirmation state. There is no update or delete.

Confirmations follow the appointment's permissions. Recording one is a modify on the appointment: tech appointments require the Scheduler permission at the customer's location; sales appointments require the Sale Scheduler (or Assign Sale Schedule To Self) permission.

The composite key (id, calendar_category) means confirmations aren't addressed at /{id}; recording one goes through the confirm collection action.

Recording a confirmation

curl -X POST "https://portal.securitytrax.com/acme/user/v4/calendar_event_confirmations/confirm" \
  -H "Authorization: Bearer stx_acme_..." \
  -H "Content-Type: application/json" \
  -d '{"data":{"attributes":{"calendar_event_id":314,"confirmation_status_id":2,"confirmation_type_id":1,"notes":"Customer confirmed by phone"}}}'

Recording a confirmation logs a "Set Confirmation Status …" activity on the appointment, exactly as the SecurityTrax scheduler does.

Listing confirmations

Filters: calendar_event_id (the appointment — the usual lens), calendar_category (tech_schedule / sale_schedule), confirmation_status_id. Sort by id, calendar_event_id, or created_at (default created_at, newest first); ?count_only=true for the total.

# The confirmation history for one appointment
curl "https://portal.securitytrax.com/acme/user/v4/calendar_event_confirmations?calendar_event_id=314&sort=-created_at" \
  -H "Authorization: Bearer stx_acme_..."

Fields

Fields are grouped by the permission that gates them. A group you may not view is absent from responses; a group you may not write is rejected with 422 when sent in a write.

Tech Confirmation

View: customers — the standard canViewTechSchedule rules; leads — Lead Scheduler. Create: the standard canConfirmTechAppointment rules.

Sales Confirmation

View: any of: Sale Scheduler; Assign Sale Schedule To Self. Create: any of: Sale Scheduler; Assign Sale Schedule To Self.

Pagination

The list endpoint uses client-controlled offset pagination: ?page= (1-based) and ?per_page= (default 25, max 100). The response mirrors meta.pagination (page, per_page, total, last_page) and sends an RFC5988 Link header; follow rel="next" to walk pages. See Pagination.

Filters

The list endpoint accepts these query-param filters: calendar_event_id, calendar_category, confirmation_status_id. An unsupported filter parameter returns 422. See Filtering collections for matching semantics.

Sorting

GET .../calendar_event_confirmations?sort= orders the list by: id, calendar_event_id, created_at. Prefix a field with - for descending; comma-separate for tie-breakers. An unsupported field returns 422. See Sorting collections.

Related

• Requests and Responses — envelope, errors, pagination, and rate limits.
• Authentication — tokens and the Authorization header.