[Feature Request] Public API Documentation for Third-Party Integrations #115

New issue

Open

opened 2026-02-28 01:28:40 -05:00 by deekerman · 0 comments

deekerman commented

2026-02-28 01:28:40 -05:00

Owner

Originally created by @foliefurieuse on GitHub (Jan 26, 2026).

Is your feature request related to a problem? Please describe.
Hello FluidCalendar Team,

First of all, thank you for creating such a fantastic and powerful open-source scheduling tool. The intelligent planning engine is a game-changer for productivity.

As a developer, I would love to integrate FluidCalendar with other tools in my workflow (custom scripts, other productivity apps, etc.). Currently, the primary way to interact with the service is through the web UI or by syncing with external calendar providers. While this is great for daily use, it limits the potential for automation and extensibility.

After exploring the project, it appears that an internal API is used by the front end to communicate with the back end. However, there is no public documentation for this API, which makes it difficult for third-party developers to build on top of the FluidCalendar platform.

Describe the solution you'd like
I would like to request the creation and publication of official API documentation. This would enable the community to build integrations and extend the functionality of FluidCalendar.

A comprehensive API documentation would ideally include:

Authentication: Clear instructions on how to authenticate with the API (e.g., API keys, OAuth tokens).
Endpoints List: A complete list of available endpoints for resources such as tasks, events, and settings.
CRUD Operations: Detailed examples for common operations:
- Creating, reading, updating, and deleting tasks.
- Listing scheduled events for a given period.
- Triggering a manual replan of the schedule.
Data Models: Clear definitions of the request and response objects (e.g., the structure of a Task object).
Error Handling: Information on status codes and error response formats.
Rate Limiting: Details on any API usage limits, if applicable.

Describe alternatives you've considered
The only current alternative is to reverse-engineer the internal API by inspecting the browser's network traffic or by analyzing the source code. This approach is brittle, time-consuming, and prone to breaking with any future updates.

Additional context
Providing a public API would unlock a host of new possibilities for FluidCalendar, such as:

Integrations with services like Zapier, IFTTT, or n8n.
The creation of custom mobile or desktop clients.
Command-line interface (CLI) tools for power users.
Custom reporting and dashboarding solutions.

Thank you for considering this request. I believe it would significantly increase the value and adoption of FluidCalendar within the developer community. I'd be happy to help with testing or even contribute to drafting the documentation if needed.

Originally created by @foliefurieuse on GitHub (Jan 26, 2026). **Is your feature request related to a problem? Please describe.** Hello FluidCalendar Team, First of all, thank you for creating such a fantastic and powerful open-source scheduling tool. The intelligent planning engine is a game-changer for productivity. As a developer, I would love to integrate FluidCalendar with other tools in my workflow (custom scripts, other productivity apps, etc.). Currently, the primary way to interact with the service is through the web UI or by syncing with external calendar providers. While this is great for daily use, it limits the potential for automation and extensibility. After exploring the project, it appears that an internal API is used by the front end to communicate with the back end. However, there is no public documentation for this API, which makes it difficult for third-party developers to build on top of the FluidCalendar platform. **Describe the solution you'd like** I would like to request the creation and publication of official API documentation. This would enable the community to build integrations and extend the functionality of FluidCalendar. A comprehensive API documentation would ideally include: * **Authentication:** Clear instructions on how to authenticate with the API (e.g., API keys, OAuth tokens). * **Endpoints List:** A complete list of available endpoints for resources such as tasks, events, and settings. * **CRUD Operations:** Detailed examples for common operations: * Creating, reading, updating, and deleting tasks. * Listing scheduled events for a given period. * Triggering a manual replan of the schedule. * **Data Models:** Clear definitions of the request and response objects (e.g., the structure of a `Task` object). * **Error Handling:** Information on status codes and error response formats. * **Rate Limiting:** Details on any API usage limits, if applicable. **Describe alternatives you've considered** The only current alternative is to reverse-engineer the internal API by inspecting the browser's network traffic or by analyzing the source code. This approach is brittle, time-consuming, and prone to breaking with any future updates. **Additional context** Providing a public API would unlock a host of new possibilities for FluidCalendar, such as: * Integrations with services like Zapier, IFTTT, or n8n. * The creation of custom mobile or desktop clients. * Command-line interface (CLI) tools for power users. * Custom reporting and dashboarding solutions. Thank you for considering this request. I believe it would significantly increase the value and adoption of FluidCalendar within the developer community. I'd be happy to help with testing or even contribute to drafting the documentation if needed.

No labels

enhancement

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/fluid-calendar#115

No description provided.

Rows
Columns