Returns all confirmed bookings for one date in the current organization, ordered by time slot. This endpoint powers the operator-facing daily booking calendar and is not available to widget visitors. The `date` query is required and must use `YYYY-MM-DD` format. Authenticate with an organization API key sent in `X-API-Key` or as a Bearer token and carrying the exact `scheduling:read` scope. API-key access also requires the Automation & API module (`automation_api`). Authorized dashboard sessions remain supported where the route already permits them. The request is isolated to the authenticated organization. Resource and site/project identifiers must belong to that organization; out-of-scope identifiers are not disclosed. `date` is required in `YYYY-MM-DD` form. Only `confirmed` bookings are returned, ordered by local `timeSlot`. This is an operator/customer API view and is not available to visitor bearer tokens. Retry behavior: This read-only operation is safe to retry.
/api/scheduling/bookings/dailyOrganization API key supplied as Authorization: Bearer convor_sk_....
In: header
application/json
application/json
application/json
application/json
application/json
application/json
application/json
application/json
application/json
{
"data": [
{
"id": "22222222-2222-4222-8222-222222222222",
"orgId": "33333333-3333-4333-8333-333333333333",
"visitorEmail": "[email protected]",
"visitorName": "Ada Lovelace",
"date": "2030-06-15",
"timeSlot": "10:00",
"timezone": "Europe/Warsaw",
"conversationId": "11111111-1111-4111-8111-111111111111",
"status": "confirmed",
"createdAt": "2030-05-01T08:00:00.000Z",
"updatedAt": "2030-05-01T08:00:00.000Z"
}
]
}{
"error": {
"code": "string",
"message": "string",
"fields": {
"property1": "string",
"property2": "string"
},
"details": {},
"correlationId": "string"
}
}{
"error": {
"code": "string",
"message": "string",
"fields": {
"property1": "string",
"property2": "string"
},
"details": {},
"correlationId": "string"
}
}{
"error": {
"code": "string",
"message": "string",
"fields": {
"property1": "string",
"property2": "string"
},
"details": {},
"correlationId": "string"
}
}{
"error": {
"code": "string",
"message": "string",
"fields": {
"property1": "string",
"property2": "string"
},
"details": {},
"correlationId": "string"
}
}{
"error": {
"code": "string",
"message": "string",
"fields": {
"property1": "string",
"property2": "string"
},
"details": {},
"correlationId": "string"
}
}{
"error": {
"code": "string",
"message": "string",
"fields": {
"property1": "string",
"property2": "string"
},
"details": {},
"correlationId": "string"
}
}{
"error": {
"code": "string",
"message": "string",
"fields": {
"property1": "string",
"property2": "string"
},
"details": {},
"correlationId": "string"
}
}{
"error": {
"code": "string",
"message": "string",
"fields": {
"property1": "string",
"property2": "string"
},
"details": {},
"correlationId": "string"
}
}curl --request GET \
'https://api.convor.io/api/scheduling/bookings/daily?date=2030-06-15' \
--header 'Accept: application/json' \
--header 'Authorization: Bearer convor_sk_...'const response = await fetch("https://api.convor.io/api/scheduling/bookings/daily?date=2030-06-15", {
method: "GET",
headers: {
"Accept": "application/json",
"Authorization": "Bearer convor_sk_..."
},
});
const contentType = response.headers.get("content-type") ?? "";
const data = response.status === 204
? null
: contentType.includes("json")
? await response.json()
: contentType.startsWith("text/")
? await response.text()
: await response.blob();
if (!response.ok) {
const message = typeof data === "object" && data !== null
&& "error" in data && typeof data.error === "object"
&& data.error !== null && "message" in data.error
? String(data.error.message)
: "Convor API request failed (" + response.status + ")";
throw new Error(message);
}
console.log(data);Was this page helpful?
List bookings for a conversation
Lists all bookings for one conversation in the current organization. The `conversationId` query is required. Widget visitors can only read bookings linked to their own conversation. The response includes both confirmed and cancelled bookings and is not paginated. Authenticate with an organization API key sent in `X-API-Key` or as a Bearer token and carrying the exact `scheduling:read` scope. API-key access also requires the Automation & API module (`automation_api`). Authorized dashboard sessions remain supported where the route already permits them. The request is isolated to the authenticated organization. Resource and site/project identifiers must belong to that organization; out-of-scope identifiers are not disclosed. `conversationId` is required. The response is not paginated and can contain bookings in any stable status: `confirmed`, `cancelled`, `completed`, or `no_show`. Visitor bearer callers can read only their own conversation; organization API keys and operator sessions remain isolated by both organization and conversation identifier. Retry behavior: This read-only operation is safe to retry.
Reschedule a booking to a new slot
Moves a confirmed booking to a new date and 30-minute time slot without creating a new booking record. The booking ID and conversation link stay the same. Only confirmed bookings can be rescheduled, and conflicting confirmed slots return `409`. Widget visitors may reschedule only bookings linked to their own conversation. The previous date and slot are stored in the booking's `rescheduledFrom` and `rescheduledFromSlot` fields. Authenticate with an organization API key sent in `X-API-Key` or as a Bearer token and carrying the exact `scheduling:write` scope. API-key access also requires the Automation & API module (`automation_api`). Authorized dashboard sessions remain supported where the route already permits them. The request is isolated to the authenticated organization. Resource and site/project identifiers must belong to that organization; out-of-scope identifiers are not disclosed. Only a `confirmed` booking can be moved. The booking ID and conversation link remain unchanged, while `rescheduledFrom`, `rescheduledFromSlot`, and `rescheduledAt` record the previous slot. The target must satisfy the same future/business-hour/increment rules as creation and must not collide with another confirmed booking. A repeated request can overwrite reschedule provenance, so read the booking before retrying after an ambiguous timeout. Visitor bearer callers may reschedule only bookings linked to their own conversation. Retry behavior: This operation is not idempotent. After an ambiguous timeout, read the resource state before retrying to avoid duplicate work, messages, files, bookings, exports, or events.