Skip to content

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

@foliefurieuse

Description

@foliefurieuse

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions