TL;DR
For a project that will create bookings through Calendly’s API, ask for evidence about the actual account, event type, permissions, payload and failure behavior. A successful demonstration on a vendor’s account does not establish that your proposed configuration works. Name the owner who will maintain it after launch.
Establish what the proposal must prove
Use the agent-booking action brief to settle the visitor’s choices, authorization and definition of completion. This worksheet starts after the team has identified a real need for programmatic booking. Use it to assess the specific Calendly integration described in the proposal.
The requirements below were checked against Calendly’s documentation on October 17, 2026. Recheck them when commissioning the work. Use the worksheet to collect implementation evidence for the proposed account. A business-consultation example also does not establish that the system is appropriate for patient scheduling; qualified reviewers must assess the intended data and jurisdiction.
Confirm account access before commissioning the build
Calendly’s Create Event Invitee reference limits this booking endpoint to paid plans, Standard and above, and lists the scheduled_events:write scope. Its availability endpoint lists availability:read. A public calendar link is not evidence of either permission.
The authentication guide distinguishes an internal/private integration for one account using a personal access token from OAuth for applications accessing customers’ accounts. Have the implementer identify the arrangement that fits the proposed application and verify it for the intended account. Do not accept a developer’s personal test credentials as the production ownership plan.
| Procurement decision | Evidence the account owner should receive |
|---|---|
| Is this account entitled to use the booking endpoint? | Verified current plan and access for the actual account |
| Whose Calendly data will the application access? | Named account/organization and an appropriate authorization design |
| Can it read availability and create the intended booking? | A controlled demonstration with the required access and a sanitized result |
| Who can revoke or replace access? | Named owner and a tested administrative handoff procedure |
Keep secrets out of proposals, screenshots and browser code. The security reviewer should approve credential storage, access and revocation; the worksheet does not prescribe a particular secret-management product.
Approve one event mapping at a time
Ask for a mapping record that connects the visitor’s selected service or consultation to the intended Calendly event type. Include the host or scheduling group, meeting location, display time zone and confirmation destination. Verify those choices against the event’s actual configuration rather than a similar-looking demonstration calendar.
The vendor documentation establishes several boundaries:
- An availability request requires a date range no greater than 31 days. A longer search needs appropriately bounded requests; an empty window does not prove there are no later appointments.
- Calendly’s agent scheduling guide uses a UTC start time and IANA time zones, with confirmation displayed in the visitor’s local zone.
- The booking endpoint reference requires supplied location data to match the event type and include its kind; it says to omit the location object for round-robin event types. Have the implementer demonstrate the appropriate payload for the actual configuration rather than copying one generic example.
If the proposed consultation is offered at multiple offices, ask the vendor to show the selected office in the mapping record, the correct event type in the test and the same destination in the confirmation. A successful booking into the wrong office is a failed acceptance case.
Ask for a failure demonstration and its evidence
Use authorized synthetic data and a controlled test arrangement. Agree on test-event cleanup and who may receive test notifications before running the demonstration. The following are proposed acceptance cases; they are not claims that a particular implementation already handles them.
| Demonstration | Evidence required to close the case |
|---|---|
| Selected slot becomes unavailable | A new valid choice is requested; no silent substitution or false confirmation |
| Required input or location is invalid | Actionable correction, with the original office/event selection still clear |
| Authorization is missing, expired or insufficient | The failure reaches the responsible owner and the visitor gets an accurate fallback |
| Result of submission is uncertain | The system checks the outcome before a retry that could duplicate the booking |
| Booking succeeds | The scheduler record and visitor confirmation agree; returned management links work where supplied |
Calendly’s guide documents validation, authorization and server-error handling and a QA checklist. Ask the developer to map observed failures to the actual API response. A fabricated error screen alone does not demonstrate the integration’s recovery behavior.
Keep the evidence packet small: account and event configuration, test setup, expected result, sanitized observed result, defect owner and retest. Avoid retaining tokens or unnecessary personal details in logs or screenshots.
Make maintenance part of the purchase decision
Name who approves event changes, updates mappings, maintains account access and investigates an uncertain booking. Record what happens when that person leaves or the practice changes its calendar setup. Include the support work in the proposal rather than assuming the prototype’s author will remain available.
If the account prerequisites, mapping or recovery evidence are missing, leave that acceptance item open. Resolve it before promoting direct automated booking. The purchase decision should rest on the configuration the practice can operate and support, not the phrase “AI booking.”
Frequently asked questions
Is a paid plan enough to approve the project?
No. It is one access prerequisite. The actual authorization, event mapping, supported payload, confirmation and operational ownership still need evidence.
Does a 31-day request limit prohibit booking further into the future?
The cited limit is the span of one availability request. It is not, by itself, the event’s booking horizon. Verify the event’s configured availability and any other applicable constraints.