Local services & SaaS
Faire
Orders, inventory, reorders and messages for wholesale brands.
12 endpoints
Bookings, open times, guest profiles and the W8LIST of your ResDiary venue. Use it in ChatGPT, Claude or any AI agent over MCP, or in n8n, Make and scripts over REST.
12 tools Read and write
ResDiary has no MCP server, and its APIs are for approved integrations (checked 31 Oct 2026). A venue or developer applies, states a purpose and passes certification, and the API licence then covers that purpose only. Cotlet runs 12 ResDiary tools hosted, in your own venue login, over MCP for agents and REST for scripts.
| What you need | Approved API | GitHub server | Cotlet |
|---|---|---|---|
| Read the bookings of a date | After approval | No | Yes |
| Find open times and book | After approval | As a guest | Yes, after your OK |
| Move or cancel a booking | After approval | Cancel as a guest | Yes, after your OK |
| Read guest profiles and notes | After approval | No | Yes |
| Add guest notes and customer types | Not in the docs | No | Yes |
| Allowed by ResDiary's terms | Yes, official | Public widget | Second login |
Checked 31 Oct 2026. Sources: Access ResDiary API documentation · Explore and request your ResDiary API · ResDiary API License Terms · ResDiary Terms of Service
Use your own account in its Cotlet Cloud Browser.
Connect your agent or create a Cotlet API key.
Ask your agent or send an HTTP request.
We never keep your ResDiary password, and no booking change reaches a guest until you approve it. Who can see your session
Use MCP with your AI agent, or HTTP requests in n8n, Make, Zapier and scripts. Follow the MCP setup below or jump to the REST guide.
Turn on ResDiary for agents. Create a Cotlet account, sign in to ResDiary in its Cloud Browser with your venue login, then press Enable for agents.
Add the Cotlet address. Paste https://cotlet.dev/mcp/v1 into your agent as an MCP server or connector.
Allow the connection. Chat apps open a Cotlet sign-in. Code editors, n8n and scripts take an API key from the console.
The shared address https://cotlet.dev/mcp/v1 carries ResDiary next to the other apps you enable. Turned ResDiary on after you connected? Refresh the connector and its tools appear.
Settings > Connectors > Add custom connector
URL: https://cotlet.dev/mcp/v1/connect
Claude Code:
claude mcp add --transport http cotlet-resdiary \
https://cotlet.dev/mcp/v1 \
--header "Authorization: Bearer $COTLET_API_KEY" Settings > Apps & Connectors > Create
MCP server URL: https://cotlet.dev/mcp/v1/connect
Authentication: OAuth // ~/.cursor/mcp.json
{
"mcpServers": {
"cotlet-resdiary": {
"url": "https://cotlet.dev/mcp/v1",
"headers": { "Authorization": "Bearer ${env:COTLET_API_KEY}" }
}
}
} # ~/.codex/config.toml
[mcp_servers.cotlet-resdiary]
url = "https://cotlet.dev/mcp/v1"
bearer_token_env_var = "COTLET_API_KEY" MCP Client Tool (inside an AI Agent)
Transport: HTTP Streamable
URL: https://cotlet.dev/mcp/v1
Auth: Bearer, <your key>
Tool: resdiary_read Make: MCP Client > Call a tool
Zapier: MCP Client by Zapier > Run Tool
Server URL: https://cotlet.dev/mcp/v1
Token: <your key>
Tool: resdiary_write Create a Cotlet API key with access to ResDiary and its read operations. Store it as COTLET_API_KEY in your environment or automation platform's credential store.
Connect ResDiary in Cotlet and enable it for agents. Account access: your own ResDiary venue login with access to the diary and the customer database. No ResDiary API key is needed, and Cotlet never reads guest contact details.
curl "https://cotlet.dev/api/v1/resdiary/bookings?date=2026-10-31&status=Unconfirmed" \
-H "Authorization: Bearer $COTLET_API_KEY" A successful REST call puts the tool output in result. This illustrative response excerpt omits call IDs, messages and credit details.
{
"status": "success",
"app": "resdiary",
"tool": "list_bookings",
"result": {
"date": "2026-10-31",
"bookings": [
{
"booking_id": "bk_21047",
"reference": "BHCQ70M",
"time": "19:15",
"party_size": 4,
"status": "Unconfirmed",
"guest": "Sam Lee",
"customer_id": "cu_9120",
"booking_note": "Deposit due"
}
]
}
} Returns the bookings your diary shows for that date in time order, with party size, status, guest and the booking note. Walk-ins have no customer_id.
status is optional. Leave it out to read every booking of the date, including cancelled ones.
The call has a limit input and no cursor. Read one date at a time and compare changed statuses and notes as well as booking IDs when you refresh.
Replace the date with the day you need. A Bumped booking is one staff still have to put back on a table.
| Tool | Connect through | Example workflow |
|---|---|---|
| n8n | HTTP Request | Each morning, read the guest profile of every booking with get_customer and post the allergy notes to your team channel. |
| Make | HTTP > Make a request | Read the open times for a party of 4 with list_available_times and add the earliest to a shortlist your manager approves. |
| Python or Node.js | REST API | Read tomorrow's unconfirmed bookings with list_bookings and print a deposit chase list. |
Send Authorization: Bearer <your Cotlet API key> in request headers. You configure the schedule, destination and record comparisons.
Cotlet reads ResDiary; your workflow steps write to your chosen destination. These HTTP workflows do not require a native Cotlet connector or a prebuilt template.
Python and Node.js can use the same HTTP requests without an AI agent. Keep access keys in credentials, outside shared workflow exports.
The API and MCP reference lists operations and inputs. The REST API guide explains authentication, errors and approvals.
Reads of your diary and the times your venue would offer. Nothing is held until a booking is created.
Returns the bookings the diary shows for that date in time order, each with booking_id, reference, visit time, party size, status, guest name, customer_id and the booking note. Walk-ins appear without a customer_id. A Bumped booking is one a staff member still has to put back on a table. It changes nothing.
MCP callresdiary_read → list_bookings
REST endpointGET https://cotlet.dev/api/v1/resdiary/bookings
| Name | Type | Description |
|---|---|---|
| date string required | string | Visit date in YYYY-MM-DD. |
| status string | string | Booking status to keep, for example Booked, Confirmed, Unconfirmed, Cancelled or Bumped. Defaults to all. |
| limit integer | integer | How many bookings to return. |
{
"date": "date"
} {
"date": "2026-10-31",
"bookings": [
{
"booking_id": "bk_21041",
"reference": "BHCQ66D",
"time": "18:30",
"party_size": 2,
"status": "Confirmed",
"guest": "Alex Rivera",
"customer_id": "cu_8812",
"booking_note": "Anniversary"
},
{
"booking_id": "bk_21047",
"reference": "BHCQ70M",
"time": "19:15",
"party_size": 4,
"status": "Unconfirmed",
"guest": "Sam Lee",
"customer_id": "cu_9120",
"booking_note": "Deposit due"
},
{
"booking_id": "bk_21052",
"reference": "BHCQ74T",
"time": "20:00",
"party_size": 6,
"status": "Confirmed",
"guest": "Harper Lane",
"customer_id": "cu_7304",
"booking_note": ""
}
]
} Returns the booking as the diary shows it: visit date and time, party size, status, booking note, internal reminders with their due dates, and the guest with customer_id. Contact details are left out of the response. It changes nothing.
MCP callresdiary_read → get_booking
REST endpointGET https://cotlet.dev/api/v1/resdiary/bookings/{booking_id}
| Name | Type | Description |
|---|---|---|
| booking_id string required | string | A booking_id from list_bookings. |
{
"booking_id": "booking_8c41d2"
} {
"booking_id": "bk_21047",
"reference": "BHCQ70M",
"date": "2026-10-31",
"time": "19:15",
"party_size": 4,
"status": "Unconfirmed",
"booking_note": "Deposit due",
"reminders": [
{
"text": "Collect deposit",
"due": "2026-10-30"
}
],
"guest": {
"customer_id": "cu_9120",
"name": "Sam Lee"
}
} Returns the times your venue would offer for that party size on that date, as its online booking shows them, with the service name where there is one. It holds no table: a time can be gone by the time you book. Your own limits, such as maximum online covers, still apply.
MCP callresdiary_read → list_available_times
REST endpointGET https://cotlet.dev/api/v1/resdiary/available-times
| Name | Type | Description |
|---|---|---|
| date string required | string | Visit date in YYYY-MM-DD. |
| party_size integer required | integer | Number of guests. |
| time string | string | Time in HH:MM to search around. Defaults to 19:00. |
{
"date": "date",
"party_size": 1
} {
"date": "2026-11-07",
"party_size": 4,
"times": [
{
"time": "19:30",
"service": "Dinner"
},
{
"time": "20:00",
"service": "Dinner"
},
{
"time": "20:15",
"service": "Dinner"
}
]
} Returns each waiting party with its booking_id, guest name, party size, the time it asked for and its W8LIST status, in the order your diary shows them. It reads the queue only: it does not text anyone. It changes nothing.
MCP callresdiary_read → list_waitlist
REST endpointGET https://cotlet.dev/api/v1/resdiary/waitlists
| Name | Type | Description |
|---|---|---|
| date string required | string | Date in YYYY-MM-DD. |
{
"date": "date"
} {
"date": "2026-10-31",
"waitlist": [
{
"booking_id": "bk_21090",
"guest": "Jordan Park",
"party_size": 2,
"requested_time": "19:00",
"status": "Queued"
},
{
"booking_id": "bk_21093",
"guest": "Taylor Green",
"party_size": 5,
"requested_time": "19:30",
"status": "Queued"
}
]
} Creating, moving and cancelling reach the guest, so each waits for your OK. A booking that needs a deposit stays Unconfirmed until the guest completes it.
Adds the booking to the diary the way the Book button does, so the call waits for your approval. ResDiary sends the guest a confirmation email, and a booking that needs a deposit or a stored card stays Unconfirmed until the guest completes it. Returns the booking_id and the reference. By default you confirm each call; you can switch that off for this tool.
MCP callresdiary_write → create_booking
REST endpointPOST https://cotlet.dev/api/v1/resdiary/bookings
| Name | Type | Description |
|---|---|---|
| date string required | string | Visit date in YYYY-MM-DD. |
| time string required | string | A time from list_available_times, HH:MM. |
| party_size integer required | integer | Number of guests. |
| customer_id string | string | An existing profile from search_customers. Leave out for a new guest. |
| first_name string | string | Guest first name, for a new guest. |
| last_name string | string | Guest last name, for a new guest. |
| mobile string | string | Guest mobile number, for a new guest. |
| booking_note string | string | A note on the booking, for example "high chair" or "birthday". |
{
"date": "2026-11-07",
"time": "20:00",
"party_size": 4,
"first_name": "Chidi",
"last_name": "Okafor",
"mobile": "+447700900123",
"booking_note": "Birthday dinner"
} {
"booking_id": "bk_21107",
"reference": "BHCQ81K",
"date": "2026-11-07",
"time": "20:00",
"party_size": 4,
"status": "Confirmed",
"guest": "Chidi Okafor"
} Edits the booking in the diary and the guest sees the change, so the call waits for your approval. A new time must come from list_available_times for the new party size. When the change does not fit, the booking stays as it was and the call returns why. By default you confirm each call; you can switch that off for this tool.
MCP callresdiary_write → update_booking
REST endpointPATCH https://cotlet.dev/api/v1/resdiary/bookings/{booking_id}
| Name | Type | Description |
|---|---|---|
| booking_id string required | string | A booking_id from list_bookings. |
| time string | string | A new time from list_available_times, HH:MM. Leave out to keep the time. |
| party_size integer | integer | New number of guests. |
| booking_note string | string | New booking note. |
{
"booking_id": "booking_8c41d2"
} {
"booking_id": "bk_21052",
"reference": "BHCQ74T",
"date": "2026-10-31",
"time": "19:45",
"party_size": 6,
"status": "Confirmed"
} Sets the booking to Cancelled and frees the table, so the call waits for your approval. A cancelled booking cannot be restored by a tool; create a new booking instead. A deposit already paid is handled in ResDiary, not by this call. By default you confirm each call; you can switch that off for this tool.
MCP callresdiary_write → cancel_booking
REST endpointPOST https://cotlet.dev/api/v1/resdiary/bookings/{booking_id}/cancel
| Name | Type | Description |
|---|---|---|
| booking_id string required | string | A booking_id from list_bookings. |
{
"booking_id": "booking_8c41d2"
} {
"booking_id": "bk_21047",
"reference": "BHCQ70M",
"status": "Cancelled"
} Profiles, customer notes, customer types and internal reminders. Only your staff see the notes, types and reminders.
Returns matching profiles with customer_id, name, customer type and the date of the last visit, best match first. Email and mobile number are left out of the response; you search by them but do not read them back. It changes nothing.
MCP callresdiary_read → search_customers
REST endpointGET https://cotlet.dev/api/v1/resdiary/customers/search
| Name | Type | Description |
|---|---|---|
| query string required | string | Part of a name, an email address or a mobile number. |
| limit integer | integer | How many profiles to return. |
{
"query": "query"
} {
"customers": [
{
"customer_id": "cu_7304",
"name": "Harper Lane",
"customer_type": "Regular",
"last_visit": "2026-10-17"
},
{
"customer_id": "cu_7311",
"name": "Harper Lowe",
"customer_type": "",
"last_visit": "2026-06-02"
}
]
} Returns the guest's name, customer type, customer notes (the ones that show every time this guest books), the number of past visits and the last visits with date, party size and status. A profile has one customer type. Contact details are left out of the response.
MCP callresdiary_read → get_customer
REST endpointGET https://cotlet.dev/api/v1/resdiary/customers/{customer_id}
| Name | Type | Description |
|---|---|---|
| customer_id string required | string | A customer_id from list_bookings or search_customers. |
{
"customer_id": "customer_8c41d2"
} {
"customer_id": "cu_7304",
"name": "Harper Lane",
"customer_type": "Regular",
"notes": [
"Prefers the window table"
],
"visits": 11,
"last_visits": [
{
"date": "2026-10-17",
"party_size": 4,
"status": "Closed"
},
{
"date": "2026-09-05",
"party_size": 2,
"status": "Closed"
}
]
} Adds a customer note, the kind that shows every time this guest books. Notes are for your staff, the guest is not told, and you remove the note on the profile in one step, so it runs without asking you. Returns the profile's notes after the change.
MCP callresdiary_write → add_customer_note
REST endpointPOST https://cotlet.dev/api/v1/resdiary/customers/{customer_id}/note
| Name | Type | Description |
|---|---|---|
| customer_id string required | string | A customer_id from list_bookings or search_customers. |
| note string required | string | Note text, for example "Shellfish allergy" or "Prefers a quiet table". |
{
"customer_id": "customer_8c41d2",
"note": "note"
} {
"customer_id": "cu_9120",
"name": "Sam Lee",
"notes": [
"Shellfish allergy"
]
} Sets the profile's customer type, the tag your team sees every time that profile books and that you can segment marketing by. A profile has one customer type, so this replaces the old one; set the old name back to undo it. It only uses types that exist in your venue's list, and nobody outside your team sees it, so it runs without asking you.
MCP callresdiary_write → set_customer_type
REST endpointPUT https://cotlet.dev/api/v1/resdiary/customers/{customer_id}/type
| Name | Type | Description |
|---|---|---|
| customer_id string required | string | A customer_id from search_customers. |
| customer_type string required | string | A customer type your venue already has under Settings > Customer Types, for example "Regular". |
{
"customer_id": "customer_8c41d2",
"customer_type": "customer type"
} {
"customer_id": "cu_7311",
"name": "Harper Lowe",
"customer_type": "Regular",
"previous": ""
} Adds a reminder that only your staff see; it appears in the diary on the due date. The guest is not told, and you delete the reminder on the booking in one step, so it runs without asking you. Returns the reminders on the booking after the change.
MCP callresdiary_write → add_booking_reminder
REST endpointPOST https://cotlet.dev/api/v1/resdiary/bookings/{booking_id}/reminder
| Name | Type | Description |
|---|---|---|
| booking_id string required | string | A booking_id from list_bookings. |
| text string required | string | What staff should do, for example "Collect deposit". |
| due_date string required | string | Due date in YYYY-MM-DD. |
{
"booking_id": "booking_8c41d2",
"text": "text",
"due_date": "due date"
} {
"booking_id": "bk_21047",
"reminders": [
{
"text": "Collect deposit",
"due": "2026-10-30"
}
]
} Your signed-in ResDiary profile, AES-256-GCM encrypted, in Finland. No password.
The 12 ResDiary tools. Never the cookie itself.
The diary, customer database and W8LIST your venue login can open.
Card details, deposits and refunds, billing, user management and your password.
A code or a security question is typed by you. We never do.
Disable for agents, reset the browser, or change the password in ResDiary.
Make a ResDiary login for the agent if your venue allows more than one, and give it only the diary and customers. Our site scores A+ on Qualys SSL Labs, securityheaders.com and Mozilla Observatory (live results). There is no SOC 2 report or third-party pentest yet.
"Multiple logins from different devices or IP addresses with the same username and password are not permitted."
Cotlet signs in from its own Cloud Browser, a different IP address than your venue's. That fits the clause badly, so the risk is yours. The terms do not name bots, scripts or AI agents for the venue login; the only bot clause is "Accounts registered by 'bots' or other automated methods are not permitted", and Cotlet registers no ResDiary account. The terms also say you answer for all use of your login by third parties you authorise, and that ResDiary may alter, suspend or terminate an account for a breach. We found no public case of a venue cut off for automation (checked 31 Oct 2026).
Ask your ResDiary contact whether a second login for an assistant is fine. Written yes beats our reading of the clause.
When ResDiary renames a field or moves a screen, we change the tool and your prompts keep working. status.cotlet.dev checks the site, console and API every 3 minutes.
| Action | Undo |
|---|---|
| Add a customer note | Delete the note on the guest profile |
| Set a customer type | set_customer_type with the old type, one call |
| Add a booking reminder | Delete the reminder on the booking |
| Create or move a booking | update_booking or cancel_booking, after your OK |
| Cancel a booking | None by tool; create a new booking if the time is open |
3 of 12 tools ask first: create_booking, update_booking and cancel_booking. Each one changes what a guest holds. Reads, customer notes, customer types and reminders run at once, because only your staff see them and each is undone in one step. Switching the wait off is your choice, per tool.
A booking that needs a deposit or a stored card stays Unconfirmed until the guest completes it. Cotlet never types card numbers.
{
"name": "create_booking",
"arguments": {
"date": "2026-11-07",
"time": "20:00",
"party_size": 4,
"first_name": "Chidi",
"last_name": "Okafor",
"mobile": "+447700900123",
"booking_note": "Birthday dinner"
}
} curl -X POST https://cotlet.dev/api/v1/resdiary/bookings \
-H "Authorization: Bearer $COTLET_API_KEY" \
-H "Content-Type: application/json" \
-d '{"date":"2026-11-07","time":"20:00","party_size":4,"first_name":"Chidi","last_name":"Okafor","mobile":"+447700900123","booking_note":"Birthday dinner"}' {
"booking_id": "bk_21107",
"reference": "BHCQ81K",
"date": "2026-11-07",
"time": "20:00",
"party_size": 4,
"status": "Confirmed",
"guest": "Chidi Okafor"
} Scripts and cron jobs call the same tools over REST at /api/v1/resdiary, with the same key and price. A failed call costs nothing. Each tool in the list above shows its REST path.
About $25 a monthfor one venue with a daily floor briefing and a daily check of unconfirmed bookings, 4,240 credits. ResDiary itself is a separate subscription.
| Job | Calls | Credits |
|---|---|---|
| Brief the floor, daily | 3 × 30 | 900 |
| Copy allergies to guest notes, weekdays | 3 × 20 | 600 |
| Move a booking | 4 × 10 | 400 |
| Fill a gap in the diary | 3 × 8 | 240 |
| Chase unconfirmed bookings, daily | 2 × 30 | 600 |
| Cloud Browser, 30 days | 1,500 | |
| Total | 4,240 |
The month is our example: a daily floor briefing, guest notes on 20 weekdays, 10 moved bookings, 8 new bookings and a daily check of unconfirmed bookings. ResDiary publishes no figure for calls per venue, so the volume is our assumption. Your ResDiary plan is priced by bookings per month (resdiary.com/pricing) and is not part of this. Dollars at the $29 pack rate.
| Credits | Price, one time | Calls at 10 credits | Per 1,000 credits |
|---|---|---|---|
| 5,000 | $29 | 500 | $5.80 |
| 15,000 | $79 | 1,500 | $5.27 |
| 32,000 | $149 | 3,200 | $4.66 |
| 60,000 | $249 | 6,000 | $4.15 |
Only successful calls use credits; failed calls and timeouts cost nothing. At a balance of 0 calls pause, never a surprise charge. Authenticate with the Authorization: Bearer header.
| Option | What it does | Where it stops |
|---|---|---|
| matuspavliscak/resdiary-mcp | MCP server on the public booking widget: check availability, book and cancel as a guest at any ResDiary venue. MIT, last commit 16 Mar 2026. | Personal project, no stars. Guest side only: no diary, guest notes or W8LIST. You run it on your computer. |
| Thalvik/resdiary-api-client | PHP client for the ResDiary API. | Last commit 12 Apr 2018. Needs API credentials, which ResDiary gives by application. |
| ResDiary Consumer, Data Extract and EPOS APIs | Official: availability, bookings, customers and webhooks for approved integrations. | Needs an application, an agreed purpose and certification. The licence bans passing access to others. |
| ResPhone, ResDiary add-on | Takes bookings by phone when nobody picks up, £35 a month. | A phone line, not an agent that reads your diary or keeps guest notes. |
If you build a booking product for many venues, apply for the official API: it is the route ResDiary supports. Cotlet is for one venue or group whose manager wants an agent in the diary now, hosted, with approvals.
Take Group sp. z o.o. runs Cotlet, a software company registered in Poland, EU (VAT PL6342984273), working since 2019 and founded by Bart Krawczyk (Co-founder, CTO) and Jake Slugocki (Co-founder, SEO, sales and marketing). Questions about the ResDiary tools go to contact@cotlet.dev.
Create a free account at https://cotlet.dev, open ResDiary under Integrations in the console and sign in to ResDiary in its Cloud Browser. The trial starts with your first app, no card asked.
Sign up at cotlet.dev, log in to ResDiary once in its Cloud Browser and add Cotlet to ChatGPT or Claude, following the steps in your console. No API key is needed. ChatGPT and Claude then work in your ResDiary account through Cotlet, in their phone apps too.
With Cotlet, ChatGPT, Claude and other AI agents handle jobs like these in ResDiary: brief the floor on tonight\; copy allergies from booking notes to guest profiles; fill a gap in the diary. You ask in plain words, and anything that reaches other people waits for your OK first.
No. Cotlet works in your own venue login, so you do not apply for API access. ResDiary gives API access to approved integrations for one agreed purpose and forbids passing it on (ResDiary API License Terms, sections 2.1 and 4.1).
ResDiary's Terms of Service say multiple logins from different devices or IP addresses with the same username and password are not permitted. Cotlet signs in from its own Cloud Browser, which is another IP address than your venue's, so use a login you could give up if ResDiary objects, and keep your own use of that login in mind.
ResDiary says its plans carry the same core features and differ in the number of bookings (resdiary.com/pricing). Cotlet works in the web login of any plan; add-ons such as SMS or Order & Pay change what your venue has, not what the tools read.
No. search_customers takes a name, an email or a mobile number to find a profile, and no tool returns contact details.
Only the way in differs. Both carry the same 12 tools, inputs and answers, with one API key and one price. Agents use MCP; scripts and HTTP steps use REST.
No. Cotlet is independent and not affiliated with ResDiary or The Access Group.
Yes. Call Cotlet's REST API from a script or an HTTP step in n8n, Make or Zapier with your Cotlet key. MCP is the alternative for AI agents; you do not need to connect an agent to use REST.
Free 7-day trial with 2,000 credits, no card needed.
May we use Google Analytics to see which pages help people? It sets cookies only if you accept. No ads, and we never sell data. Cookie policy