Prompts to connect your system
Copyable prompts that tell a coding agent how to connect a play venue POS, a restaurant POS or a booking app to FloorPlanCraft Live 3D.
Updated · View as Markdown
If your venue runs its own software and you use a coding agent on it, paste one of these prompts into the agent. Each one tells the agent which developer pages to read and what to build.
Before you paste
- Draw your venue in FloorPlanCraft and name each table, area or zone the way your system names it. A restaurant can also let FloorPlanCraft make the plan from its tables while connecting.
- Run the agent in your system's own code, so it can find where tables, bookings or check-ins are kept.
- You can connect before your workspace has Live 3D. The live view starts showing pushes once it does.
Warning: The connection secret works like a password for your venue's live data. Each prompt tells the agent to keep it on your server. Check that it never ends up in browser code, logs or your repository, and review the agent's work before you put it live.
Play venue POS
For a ticketing and check-in system that knows how many kids are in each play zone.
Connect this play venue's ticketing and check-in system (POS) to FloorPlanCraft Live 3D, so the venue's floor plan shows how many kids are in each play zone, live, and staff can open that 3D view inside this system.
Read these FloorPlanCraft developer pages first. They are the contract: follow them exactly, and do not guess fields, limits or error codes. The index of every docs page is https://floorplancraft.com/llms.txt.
https://floorplancraft.com/docs/developer-overview.md
https://floorplancraft.com/docs/connect-an-app.md
https://floorplancraft.com/docs/signing-requests.md
https://floorplancraft.com/docs/live-updates.md
https://floorplancraft.com/docs/backfill-and-exit-times.md
https://floorplancraft.com/docs/embed-the-live-view.md
https://floorplancraft.com/docs/table-clicks-and-highlights.md
https://floorplancraft.com/docs/disconnect-and-errors.md
Build:
1. A "Connect to FloorPlanCraft" action in settings that runs the connect flow with "app": "play": the connect request from our server, the venue owner's approval in the browser, and the code exchange with PKCE (S256). Send our play zones as "tables": "label" is the zone's name and "capacity" its kid capacity, from 1 to 999. Send no stations.
2. After the exchange, compare "zoneLabels" with our zone names and show the owner every zone that does not match.
3. A server job that pushes the floor: a feed push on every change, debounced to 5 seconds, and a heartbeat every 60 seconds. One row per play zone: "state" is "seated" when kids are in it, "free" when it is empty and "reset" when it is closed; "covers" is the number of kids in it now, 0 when it is free or closed. Send "server": null and "stations": []. Count each kid in one zone only. Send check-ins as events ("seated", "reservation_seated", "no_show") with stable ids and a "detail" such as "3 guests".
4. Handle every answer as the docs describe: needFullState, unmatchedLabels, 402 (show the owner the upgradeUrl), 403 connection_revoked (show "Disconnected" and offer to connect again) and 429 (wait retryAfterMs).
5. A "Live floor" screen that frames the live embed. Our server mints the embed address; the page asks our server for a new one when it receives fpc:embed-expired.
6. A "Disconnect" action that calls the signed disconnect endpoint, then deletes the stored secret.
Also:
- A nightly job that re-sends the previous service day with a backfill (POST /api/live/backfill: the floor at each change and the day's events), and the same for the range of any known outage.
- On every check-in event ("seated" or "reservation_seated"), send "exitAt" when we know when the party leaves, and send the event again, same id, with the real time if they leave early.
- After any failed push or a restart, send a feed push with the day's events before anything else.
Rules:
- The connectionSecret stays on our server. Store it encrypted; never send it to a browser, put it in a URL, log it or commit it. Every signed request is made by our server.
- Use our existing stack and conventions.
- Add tests for the request signing (use the test vectors on the signing page) and for the push body.
When you are done, tell me what you built, how to try it, and anything in our system that did not fit the docs.Restaurant POS
For a POS or table app that knows which tables are seated and what the kitchen is waiting on.
Connect this restaurant POS to FloorPlanCraft Live 3D, so the restaurant's floor plan shows live table status and kitchen queues, and staff can open that 3D view inside the POS.
Read these FloorPlanCraft developer pages first. They are the contract: follow them exactly, and do not guess fields, limits or error codes. The index of every docs page is https://floorplancraft.com/llms.txt.
https://floorplancraft.com/docs/developer-overview.md
https://floorplancraft.com/docs/connect-an-app.md
https://floorplancraft.com/docs/signing-requests.md
https://floorplancraft.com/docs/live-updates.md
https://floorplancraft.com/docs/backfill-and-exit-times.md
https://floorplancraft.com/docs/embed-the-live-view.md
https://floorplancraft.com/docs/table-clicks-and-highlights.md
https://floorplancraft.com/docs/disconnect-and-errors.md
Build:
1. A "Connect to FloorPlanCraft" action in settings that runs the connect flow with "app": "restaurant": the connect request from our server, the venue owner's approval in the browser, and the code exchange with PKCE (S256). Send our tables as "tables" (label, capacity from 1 to 99, room) and our kitchen or bar stations as "stations", so the owner can also let FloorPlanCraft create the plan from them.
2. After the exchange, compare "zoneLabels" with our table labels and station names and show the owner every one that does not match.
3. A server job that pushes the floor: a feed push on every change, debounced to 5 seconds, and a heartbeat every 60 seconds. Every table with "state" ("free", "seated" or "reset"), "covers" and "openMinutes"; every station with "queue" and "oldestMinutes"; events such as "seated", "paid", "ticket_fired" and "ticket_ready" with stable ids. Send "server": null.
4. When staff add tables in the POS, offer "Add to floor plan", which calls the signed table sync endpoint and shows what was added.
5. Handle every answer as the docs describe: needFullState, unmatchedLabels, 402 (show the owner the upgradeUrl), 403 connection_revoked (show "Disconnected" and offer to connect again) and 429 (wait retryAfterMs).
6. A "Live floor" screen that frames the live embed. Our server mints the embed address; the page asks our server for a new one when it receives fpc:embed-expired. When someone clicks a table in the 3D view (fpc:table-click), open our own card for that table.
7. A "Disconnect" action that calls the signed disconnect endpoint, then deletes the stored secret.
Also:
- A nightly job that re-sends the previous service day with a backfill (POST /api/live/backfill: the floor at each change and the day's events), and the same for the range of any known outage.
- On every check-in event ("seated" or "reservation_seated"), send "exitAt" when we know when the party leaves, and send the event again, same id, with the real time if they leave early.
- After any failed push or a restart, send a feed push with the day's events before anything else.
Rules:
- The connectionSecret stays on our server. Store it encrypted; never send it to a browser, put it in a URL, log it or commit it. Every signed request is made by our server.
- Use our existing stack and conventions.
- Add tests for the request signing (use the test vectors on the signing page) and for the push body.
When you are done, tell me what you built, how to try it, and anything in our system that did not fit the docs.Booking app
For a salon, clinic or gym booking app that knows which rooms, chairs and staff stations are in use.
Connect this booking app to FloorPlanCraft Live 3D, so the venue's floor plan shows which rooms, chairs and staff stations are in use, live, and staff can open that 3D view inside the app.
Read these FloorPlanCraft developer pages first. They are the contract: follow them exactly, and do not guess fields, limits or error codes. The index of every docs page is https://floorplancraft.com/llms.txt.
https://floorplancraft.com/docs/developer-overview.md
https://floorplancraft.com/docs/connect-an-app.md
https://floorplancraft.com/docs/signing-requests.md
https://floorplancraft.com/docs/live-updates.md
https://floorplancraft.com/docs/backfill-and-exit-times.md
https://floorplancraft.com/docs/embed-the-live-view.md
https://floorplancraft.com/docs/table-clicks-and-highlights.md
https://floorplancraft.com/docs/disconnect-and-errors.md
Build:
1. A "Connect to FloorPlanCraft" action in settings that runs the connect flow with "app": "booking": the connect request from our server, the venue owner's approval in the browser, and the code exchange with PKCE (S256). Send our bookable areas (rooms, chairs or basins, staff stations) as "tables": "label" is the area's name and "capacity" is 1 for appointments or the class size, from 1 to 99. Send no stations.
2. After the exchange, compare "zoneLabels" with our area names and show the owner every area that does not match.
3. A server job that pushes the floor: a feed push on every change, debounced to 5 seconds, and a heartbeat every 60 seconds. One row per area: "state" is "seated" while a booking is in progress, "free" when the area is free and "reset" during the cleaning time after a booking; "covers" is 1 for an appointment or the booked places for a class; "openMinutes" is the minutes since the booking started. Send "server": null, "stations": [] and one "longSeatedMinutes" for the venue, such as 90. Send events "seated" (a booking starts or the client arrives), "paid" and "no_show" with stable ids.
4. Handle every answer as the docs describe: needFullState, unmatchedLabels, 402 (show the owner the upgradeUrl), 403 connection_revoked (show "Disconnected" and offer to connect again) and 429 (wait retryAfterMs).
5. A "Live floor" screen that frames the live embed. Our server mints the embed address; the page asks our server for a new one when it receives fpc:embed-expired. When someone clicks an area in the 3D view (fpc:table-click), open our own view of that area's bookings.
6. A "Disconnect" action that calls the signed disconnect endpoint, then deletes the stored secret.
Also:
- A nightly job that re-sends the previous service day with a backfill (POST /api/live/backfill: the floor at each change and the day's events), and the same for the range of any known outage.
- On every check-in event ("seated" or "reservation_seated"), send "exitAt" when we know when the party leaves, and send the event again, same id, with the real time if they leave early.
- After any failed push or a restart, send a feed push with the day's events before anything else.
Rules:
- The connectionSecret stays on our server. Store it encrypted; never send it to a browser, put it in a URL, log it or commit it. Every signed request is made by our server.
- Use our existing stack and conventions.
- Add tests for the request signing (use the test vectors on the signing page) and for the push body.
When you are done, tell me what you built, how to try it, and anything in our system that did not fit the docs.After the agent is done
- Start the connection from your system's settings.
- On the FloorPlanCraft page that opens, sign in, choose your plan and press Approve and connect.
- Open your system's live floor screen and check that every table, area or zone shows its status.
- If a push reports
unmatchedLabels, rename the zone in the planner or the label in your system until they match.