If you are not working on an API on your own I would advice you to wait for InvoicePlane 2 which will ship with a complete API.
However, I don’t think that a switch statement would be the best approach to implement an API. Either create additional controllers for each module.
It would be great if InvoicePlane had an API so it can integrate with other systems.
I am planning to integrate InvoicPlane with a time tracking system.
I understand InvoicePlane V2 might contain an API. Do you have more info on when V2 will be available?
Let me know,
Bert-Jan
Hi
I think we should discuss 1) what the API should cover, 2) how users or other applications are authenticated and 3) how it should be implemented before starting. Any ideas or suggestions?
I think it should cover at least the basic needed functions such as adding new invoices, clients and payments.
The authentication, maybe something classic and simple, now there are two kind of users (admin and guest), I was thinking creating a third kind of users might be the best idea.
And answering the how, something modular and non destructive that interact with the current code. IP1 is already here, modifying the code maybe is not a good idea at all, and sooner or later we will have IP2 with a real API. aren’t we?
I think an API is needed for IP whenever you want it to be integrated with some other apps. That’s why I started to implement a .NET Core server to be plugged over your IP DB, to serve your entities as is through a REST API (Tested with IP 1.5.x). I’m planning to add an API Token authorization system to secure all these.
I hope it can also help you dealing with IP exposure through a REST API.