Add Basic API to InvoicePlane v1


I am interested in adding a basic API to InvoicePlane v1.

I thought to add the following idea to the controllers of some modules:

public function api($action = "")
switch (action) {
    case "create":
       //create something
      return $json; // or error
    // etc... Whatever the module requires

I thought of using HTTP_POST for inputs and JSON outputs.
A method will also have to be exposed in the authentication to allow API access.

Let me know what is your thoughts on this, I am just thinking.


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.

1 Like

Additional Controllers would be a better approach. What is the ETA on IP2?

We’re just finishing the planning for IP2 so it will may take some months.

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,

1 Like


I am also interested in a time tracking/registration system.
@Kovah Any idea when you will make the planning for V2 available?


I’m also looking forward an API integration to be able to connect other apps.

Any news, sticky threads or blogs on the topic or about an ETA for InvoicePlane 2?

Keep up the excellent work!

Thanks & Regards

Hello, before saying anything or aporting any idea about creating the API for IP1. Do I have to know somthing?

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?

Hello, well.

  1. I think it should cover at least the basic needed functions such as adding new invoices, clients and payments.

  2. 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.

  3. 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?

API is completely “on the back burner”?


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.

Link to my project :