API

[KlausSchaefers]

Is your feature request related to a problem? Please describe.
I would like to download design through an API, very much like Figma. This would allow me support Penpot with https://github.com/KlausSchaefers/vue-low-code

Describe the solution you'd like
I need an API that allows do download the design (and images)

Describe alternatives you've considered
none

Additional context

[hirunatan]

This could be awesome, thanks! Unfortunately, although it's in our roadmap, having an API to interact with penpot files has not any scheduled date yet.

I don't know if there could be some shortcut for this. What data would you exactly need to do the connection?

[furkanmustafa]

Hello!

This is an area of interest for us as well.

Main priorities for us would be,

• listing libraries / files of a team
• listing versions of a library or a file
• being able to download a version of a shared library or a file (SVG is fine)
• most importantly, a webhook config, that can send a POST to a custom endpoint for "update" or "version-publish" kind of events. So we don't poll the list/download endpoints.

We can introspect SVG on our side, introspection APIs are not priority IMO.

Would be nice to have (but not priority) APIs would be,

• being able to upload updates (replacement as "new version") to existing files and libraries
  • or even create them through the API
• design introspection APIs as spoken above (read-only first I guess)

[KlausSchaefers]

Hi,

sorry for the late reply. I would need some "get File" endpoint where:

• I can download the design. I assume it is all SVG? Some JSON would be also fine...
• Get binary artefacts as images, or are they inline base64?
• Get the remaining prototyping meta data, e.g. links between the elements.

Cheers,

Klaus

[niwinz]

Thanks for the feedback, it is very interesting.

Having API that returns SVG it a bit complicated right now, because all the svg is generated on the browser side; but returning a json with all the components structure (practically the same as the penpot frontend consumes it) it is pretty easy task. Also, returning all the "links" and all images is also possible (probably direct links).

[KlausSchaefers]

Hi,

JSON would be most likely easier for me. I assume curves and paths are somehow encoded in the JSON as SVG d strings?
So, if the SVG would be

<svg viewBox="0 0 100 100" xmlns="http://www.w3.org/2000/svg">
  <path fill="none" stroke="red"
    d="M 10,30
       A 20,20 0,0,1 50,30
       A 20,20 0,0,1 90,30
       Q 90,60 50,90
       Q 10,60 10,30 z" />
</svg>

The JSON would be something like

{
...
 "d": "M 10,30 A 20,20 0,0,1 50,30 A 20,20 0,0,1 90,30 Q 90,60 50,90 Q 10,60 10,30 z"
}

[furkanmustafa]

Having API that returns SVG it a bit complicated right now, because all the svg is generated on the browser side; but returning a json with all the components structure (practically the same as the penpot frontend consumes it) it is pretty easy task. Also, returning all the "links" and all images is also possible (probably direct links).

Oh! Interesting.

I think "json with all the components structure" is better than SVG anyway, for purposes like extracting info from designs.

SVG wouldn't be a priority I think, only good to have in long term, for external archival purposes, etc.

[niwinz]

This is a pretty-printed example of a portion of internal data structure we use. As we need to handle and modify on the fly the path data, they are parsed to an internal structure. In any case, converting it back to SVG "d" strings it is pretty easy and we probably enable some option on api for return it already in "d" strings format for make it easy in integrations.

[niwinz]

The pasted image shows the verbose (and prettyprinted) data encoded using transit (https://github.com/cognitect/transit-js)
transit allows us send using json compatible data but with richier types.

[ndroo]

Jumping in her and linking to a semi related issue I've just created - I am able to update images using the API (I've integrated with "api/rpc/command/upload-file-media-object" and "api/rpc/command/update-file" to make this work, but text is a whole other kettle of fish.

The challenge I've been running into (outlined in the issue) is that I don't know how to reasonably calculate the position data. Introspecting the code and trying to reverse engineer the approach the app takes, it appears it uses the DOM to calculate this on the frontend and then sends this data too the backend.

I'm successful in updating the content of a textbox via the API, but in order for that to "work" i need to either a) have that page open in my browser when i execute the API to update the content (this results in my browser being triggered to make the subsequent calls to trigger the position data updates) OR i need to send position data (this is my preference, if i can figure out how to accurately calculate it) in order to see these updates take effect without needing to have the page open while the content update occurs via API.

My end goal here is to automate the creation of fairly standard design files and update them via API so i can pump them out automatically. I feel like editing text/images is fairly simple in terms of a requirement, and im 90% of the way there, but as always the final 10% is very trick in this instance as calculating the position data (especially for custom fonts feels impossible via the backend)