Provide an API

[lewebsimple]

Is some kind of API planned in the future ?
Basic CRUD for projects / components could be useful for workflow pipelines.

[niwinz]

Hello @lewebsimple
We already have an API that the frontend uses to communicate with backend; but for now is not documented. That api is RPC based, not HTTP REST.

In the near future, we will evaluate the option of document the current api or expose a specific public api.
Thanks.

[12people]

The Figma and Sketch APIs might serve as useful inspiration here: https://www.figma.com/developers, https://developer.sketch.com

[lallenfrancisl]

When this feature gets implemented, compatibility with figma plugins would be great as it allows the plugins to be reused here too

[VladimirLevadnij]

Hello! @niwinz Здравейте! Can you please tell me if there is any information about the implementation of API RPC in penpot?

First of all, I want to get data in the Vue web application on my localhost from the penpot backend in order to display statistics on projects that the user has in penpot.

[VladimirLevadnij]

After that, I want to understand how to make an import in the SVG format in a third-party application through the API from the backend? Is it possible to read about it somewhere?

It's all complicated for me, but I want to understand :-) Като си се хванал на хорото, ще го играеш до края 😸

[niwinz]

Hello @VladimirLevadnij

Здравейте Здравейте, аз не съм българин, но го разбирам доста добре и също говоря малко.

I think I have many questions here and I try to answer separatelly:

1. What do you mean information about implementation? We have no documentation right now about API. It is implemented using clasical RPC style, and does not uses REST semantics. The backend requires input and output to be encoded using transit format. You probably can found all available methods here but they can be considered "stable" (in form that they can change without previous notice).

2. Right now you can't download "SVG" from backend, because backend only know about structured data, I mean the backend saves data structures which serves to build SVG on frontend; they are not svg but they are pretty equivalent. You probably can retrieve that data and use it to feed a third party renderer or whatever. Maybe in a future we implement backend rendering for SVG, but right now is not our first priority on current project status.

If you have more concrete questions, feel free to ask them here or sending us an email.

[VladimirLevadnij]

@niwinz Thank you very much for your response! At the moment, everything related to Clojure and ClojureScript is difficult for me :-) Taiga, as far as I remember, has a Django backend, I worked with this framework and made changes to the local version of Taiga.

I have also mainly worked with GraphQL and REST. RPC is an unknown technology for me. It turns out a lot of new things at once, but my friends and I want to understand the project, so we will gradually do it, thanks to the fact that you find time for consultation :-)

As part of our technological experiment, we would like to receive data from Penpot in some format, preferably in JSON format, in order to then convert them to other formats. User @KlausSchaefers wrote the issue here #1333

It turns out we need something the same. But if now there is no possibility of issuing data in the JSON format, then it is possible in any format. I realized that the backend does not know about SVG, but knows about "structured data". As I understand it, this is an extended JSON, which is called "transit format". This format suits us.

Tell me, please, is there an example somewhere of how you can turn to the backend and get some data from the Penpot project (I'm talking about local deployment of Penpot) from a familiar JavaScript framework, for example, from Vue or React? To see how this is done, including understanding what mechanism is used to authorize in order to confirm the right to receive data from the project. Is it possible to receive and send some kind of token similar to a JWT token?

[VladimirLevadnij]

I have a user. This user has a project "New Project 1". In this project, a drawing of a button.

My question I wrote above was how can I get this project's data from the backend (I need to know how to get the data, how to log in to verify the right to access this project, and so on).

But also I'm wondering if I can somehow add some custom metadata to this button image? I want to indicate in this metadata that this image is the button, and other specialized options for this button.

[VladimirLevadnij]

Right now I see only one way. It is in the name of the main component to write a code identifier. For example, instead of "Buttons / contained-enabled", you could write "Material Design Buttons / contained-enabled". But you can’t write too many parameters here, otherwise it will turn out that this name will be difficult to read.

You can write "Material Design / Buttons / contained-enabled" in this case, another nesting level is created in the assets.

As I understand it, having received data in the "transit" format from the backend, it will be possible to get the connection of the Button with its main component and through this set the necessary transformation.

But there is a problem here, if the user intentionally or accidentally renames the main component or detaches the component from the main component, then we will lose the necessary links.

Therefore, the correct solution, as I see it, is to find opportunities for components to enter additional metadata. In this case, of course, the user will be able to enter the desired form, see this metadata and edit or even delete them, but this will be a specific action that goes beyond the usual design creation paradigm. Well, that is, you will need to specifically climb into this field and specifically break everything, this will already be the user's right :-)

So my question is, is there such a field that can already be used to store metadata that will be available in the backend via the RPC API? And if there is no such field, then what is the possibility to create this field?

[VladimirLevadnij]

If we talk about how I see this field for metadata, then it can be a kind of text field that can store arbitrary information, where each line will be a separate parameter, if necessary, this parameter can be written in the key: value format. Well, that is, this field is for free use, in various assets it will be possible to use this field at will. So that you can then process these additional metadata in different ways.

Perhaps such a field already exists, I just didn’t see it, or didn’t understand that this is exactly what I’m looking for :-)

[VladimirLevadnij]

A more complex, yet more functionally more promising approach, it seems to me, is to make it possible to create in assets a kind of library of entities that can be associated with components.

Thus, it will be possible to pre-associate the main component in the assets with entities that define what it refers to "Material Design", refers to "Buttons" and so on. Or, when the user draws their own button, they can define that button as a component for which they can create their own metadata links. For example, that this is a button from the library, which he himself has now invented and drawn.

This entity library can simply be called "Metadata". That is, in addition to Component, Graphics, Colors and Typographies, there will also be Metadata.

Metadata, if simple, will have a name and a data field. Here you can make the necessary metadata, and then go to the components and through the menu item with the name, for example, "Bind metadata" or simply "Metadata", open a form with a list of available metadata and add or remove previously selected metadata.

[VladimirLevadnij]

@niwinz Do I need to create a separate issue on the topic of metadata?

[niwinz]

@niwinz Do I need to create a separate issue on the topic of metadata?

Please, do it. I think is very useful. I Have have thought something similar but didn't created a proposal for it.

I'll try to answer the other questions on monday :D

[VladimirLevadnij]

Please, do it. I think is very useful. I Have have thought something similar but didn't created a proposal for it.

I'll try to answer the other questions on monday :D

@niwinz I have created issues. It turns out the following threads of discussion:

1. In this discussion, we can continue the discussion of the RPC API, what I asked above, including, please show examples.

2. This issue is about the functionality of custom metadata Make functionality for adding custom metadata #1610

3. Here I suggested thinking about whether it is possible to use NocoDB to quickly create the first version of the REST API and GraphQL API functionality for Penpot The ability to quickly create REST API and GraphQL API using special engines #1611

Also, I would like to understand in more detail if you have a plan to create a plugin system? If so, do you have an understanding of how you plan to implement the plugin system, do you have an understanding of the architecture of the plugin system that you want to implement?

[VladimirLevadnij]

@niwinz Can you tell me where to see an example of how to carry out authorization through the Penpot RPC API? Is it possible to somehow receive and somehow transfer some kind of user token? Or are there other mechanisms?

[niwinz]

Currently the penpot authentication uses the /api/rpc/mutation/login endpoint. You will need to send here the email and password as POST:

{"~:email": "[email protected]", "~:password": "supersecret"}

This will return the response with current user, and will set the cookie auth-token that will be used for the next call for maintain the request authenticated. As cookies mechanism already works as expected, I mean the browser will maintain it until you clear it.

The simplicity of the cookie is that in browser you don't need to store anything, just make the request and wait 200 OK response, the rest of requests will send cookies automatically. Any other similar mechanism that uses some kind of token in a custom header just reinvents the wheel and reimplements what browser cookies already do automatically.

[niwinz]

You can observe all this, opening browser dev console on the network tab and look the requests we made. It is an easy way to understand how the requests are done.

[VladimirLevadnij]

Thanks, I'll study it!

[andreincu]

Watching this request. 👀

I'll gladly try to adapt some of my plugins for Figma to penpot.

While Styler and Pagger may not be easily adaptable, Automater is a collection of scripts which will be useful on penpot as well. (advanced copy, paste, randomizer, selection, and other goodies)

Ping me if you have questions regarding Figma API, and I'll do may best to answer them. ✌️

[higorpo]

Is there any plan to do that in the future?

[niwinz]

#3034

[svallory]

Hey guys, I just discovered Penpot and haven't tried it yet, but it looks fantastic! I'm about to launch a Figma plugin and found out about you guys looking for places to promote my plugin.

I'm glad you guys are working on an API and plugin support. Developing a plugin for Figma has been a nightmare. And I would be happy to help you guys avoid some of Figma's mistakes. Just so you have an idea, it took me an entire week to figure out how to debug my plugin from VS Code. Something I believe should be straightforward or, at least, well documented. The process is so cumbersome I wrote a how-to article to make sure I don't forget how to do it.

Let me know where would be the proper place to raise concerns (like an RFC or community meeting). Btw, I've created several frameworks and I recommend open but small architectural design meetings with future plugin developers. I know I'm eager to port my Figma plugin to Penpot :)

[GBKS]

There is a working API now (docs). We're experimenting with it for porting the Bitcoin UI Kit from Figma to Penpot. We have a really rough demo set up that loads in file data and renders colors, text styles and components (rendering those very poorly). If you'd like to see how it works, the preview is here, and the code here. The code for loading a file from the API via an access token is in this file.

A huge helper for API usage would be some type of open-sourced library for rendering Penpot components on the web from API data. This is really intricate, and I am sure a ton of future tools based on the API would benefit from this.

[Manueljlin]

Any plans on having user facing plugins inside the editor itself, and not just a regular API?

I'm exploring the possibility of using Penpot to streamline the icon creation process for KDE contributors. Right now, the current workflow is:

• Create icon using Inkscape, Penpot, Figma etc
• Optimize it to remove unnecessary data (mostly a byproduct of inkscape adding custom metadata)
• Embed a custom stylesheet so that the system color palette gets applied at runtime

The Breeze icon theme has thousands upon thousands of icons. Sometimes we add more in the order of hundreds, with each icon going through the same process by hand.

The thing is, Penpot has color tokens, so we can map the color to a name. A designer can create these tokens, say ColorScheme-Highlight and ColorScheme-Text. A hypothetical plugin would be able to:

• Process each icon to remove unnecessary metadata
• Get used color tokens to automatically create and associate defs
• Export .svg/.zip with all of them, ready to ship directly
  That's so much nicer :D

I have a basic implementation made for Figma (icon-jetpack), but KDE being a FOSS-centric community, we'd prefer to have more choices.

I guess theoretically it should be possible to do the same with the existing API using an external program. The icon would have to be marked for optimization by appending a specific substring to the name of the group/frame, as the API has no access to the currently selected groups by the user (at least I haven't found it). The user would also have to either manually run it each time or to have the app poll every once in a while.

Thank you guys as always, we're rooting for you <3