create_booking
shallowcom.pinsvit/api · Verify this server
Books a time at a place: for the signed-in user, or, by staff of the place, for a customer. First confirm with the user the place, the time, the services and, when it matters, the stream (a table, a chair or a specialist). Take startsAt and streamIds from find_booking_times, and send either the durationMinutes it answered for or an endsAt; with services, book exactly one stream. The result's status is CONFIRMED when the time is held, or PENDING when the business must accept it first — tell the user which. Retries: make up an idempotencyKey and resend it if the call fails or times out, so a retry cannot book twice. On a CONFLICT saying a booking is already in progress, call list_my_bookings before retrying: the first attempt may have succeeded without answering. Limits: each customer is limited in open bookings and requests per place and per day, and in bookings per 10 minutes and per day; a refusal names the limit. Moving a booking: book the new time with previousBookingId, then cancel the old one. The old booking still counts against those limits, so if the new time is refused, ask the user before cancelling first. Walk-in or phone booking, by staff at their own place: (1) list_my_places gives the place's geoHash and placeId; (2) find_booking_times with forCustomer true; (3) create_booking with a start and stream from that answer plus who it is for: customerName, and customerContacts (a phone) or customerEmail. Any of those three makes the booking the customer's. It is CONFIRMED at once, skips the minimum notice and the customer limits, and is refused with BOOKING_NOT_ALLOWED unless the caller works at the place; staff are limited to 30 such bookings per 10 minutes and 300 per day. Without customer arguments the booking is the caller's own, even when the caller is staff.
1 trials · measured 15 days ago
create_booking scores 100.0/100 on Vouch's measured behaviour index, from 1 real invocation trials against com.pinsvit/api, measured 23 Sept 2026 under methodology v0.2.0. Every measured component scored 100.
Component breakdown
| Component | Weight | Value |
|---|---|---|
| Reliability | 35% | not applicable |
| Schema integrity | 25% | 100.0 |
| Failure behaviour | 15% | not applicable |
| Latency | 15% | not applicable |
| Concurrency | 10% | not applicable |
Tool details
- Transport
- remote
- Credential class
- open
- Input schema
- not declared
- Output schema
- not declared
- Side-effect classification
- unclassified
Score history
| Day | Score | Tier | Methodology |
|---|---|---|---|
| 2026-09-23 | 100.0 | shallow | v0.2.0 |
Probe evidence
| Probe | Outcomes |
|---|---|
| schema_integrity | pass: 1 |
Raw request/response logs are not archived yet — the outcome counts above are drawn directly from every recorded trial.
Embed this score
Available for every tool, scored or not — not a verification perk. Always links back to this page.
[](https://vouch.tools/tools/9c3e8731-99d7-4f2a-82c4-7e41e6e3cde2)