PassportCraft — EU Digital Product Passports

Name: PassportCraft — EU Digital Product Passports
Author: passportcraft

Create & manage EU Digital Product Passports (DPP) with PassportCraft: textiles, batteries, general goods.

От сообществаРаботаетБез входаГлобальныйБесплатноМожет изменять данные

Что умеет

List Passports: List the product passports in this workspace. Supports keyset pagination and filtering by status and category.
Get Passport: Read one product passport in full, including every field and its current status.
Get Category Schema: Read the field set for a product category — names, types, which are required to publish, and what each one means. Read this BEFORE drafting, rather than guessing field names.

Какие данные видит

Нужен ли аккаунт

Не нужен: сервер работает без входа

Create & manage EU Digital Product Passports (DPP) with PassportCraft: textiles, batteries, general goods.

Список инструментов сервера (14)

Технические названия из tools/list. Нужны только разработчикам.

list_passports	List the product passports in this workspace. Supports keyset pagination and filtering by status and category.
get_passport	Read one product passport in full, including every field and its current status.
get_category_schema	Read the field set for a product category — names, types, which are required to publish, and what each one means. Read this BEFORE drafting, rather than guessing field names.
validate_passport	List what is still missing or wrong on a passport. Use this before asking a person to publish, so the request you hand them is one they can act on.
create_passport	Create a new product passport. It is always created as a draft — this tool cannot create anything the public can see. The answer carries the `edit_url` of the new draft: give it to the person, every time, so they can open what you made.
update_passport	Change field values on a DRAFT passport. A passport the public can already see cannot be changed by an assistant: that request is refused and returns a link for a person to open. Fields written here are marked as assistant-written and are listed to a person before they publish. Changing a draft also withdraws any pending request to publish it, so this is how you act on "hold off on that one for now".
list_documents	List the documents attached to a passport.
list_library	List every file already in the workspace library, across all products. Check this BEFORE sending a file: one declaration of conformity usually covers a whole product family, so if it is already here, attach the existing file with attach_document rather than sending it again. Every copy you send spends one of the 50 file slots a workspace has, and only a person can clear them.
attach_document	Link a document already in the workspace library to a DRAFT passport. Get the id from list_library. Attaching to a passport the public can see is refused, because the public page serves attached documents live.
upload_document	Send a file you were given — a supplier declaration, a specification sheet, a photograph of a care label — into the workspace library and attach it to a DRAFT passport, in one step. Put the bytes in `content_base64`. READ THIS BEFORE SENDING ANYTHING. You do not transfer this file — you TYPE it, character by character, as part of this call. MEASURED ON A REAL CONNECTION: about 22 bytes of file a second. A 15 KB photograph took eight minutes. 30 KB takes over twenty. 1 MB would take half a day. The 3 MB the server would accept is unreachable through this door, and a smaller limit would not help — the RATE is the cost, not the size. SO THE PERSON UPLOADS IT, NOT YOU, FOR EVERYTHING EXCEPT A SMALL PICTURE. They already have the file. A passport you read ON ITS OWN carries `add_photo_url` and `add_document_url` — give them the one that fits. A passport in a LIST does not carry them, because nobody adds a file to a hundred products at once: read that one passport and the addresses come with it. DO NOT BUILD EITHER ADDRESS YOURSELF: they open the right part of the editor, and an address you assemble opens the wrong one. Each takes about 4 MB, re-encodes nothing, and is done in seconds. Name the file you mean. That is the FIRST thing to offer, not the fallback. IF YOU DO SEND IT YOURSELF, SAY SO FIRST AND SAY HOW LONG. A person watching a chat sit still for eight minutes cannot tell working from broken, and several have assumed it was broken. Tell them roughly how long it will take and let them choose the faster way. AIM FOR UNDER 30 KB, and treat that as the number to act on rather than as a preference. A photograph at about 640 pixels on its longest edge, saved as JPEG at quality 70, lands under 30 KB for ordinary product shots and at about 47 KB for a densely detailed one — measured. Check the size ONCE. If it is over 30 KB, halve the longest edge and send that without checking again. Do not hunt for the smallest possible file; the search costs more time than the bytes it saves. This copy is a working image, not the one a public page deserves — when a brand wants a good photograph on the published product, a person uploads it in the app at full size. NEVER re-encode anything a person will need to READ — a supplier declaration, a specification sheet, a photograph of a care label. Shrinking those destroys the small print, and what we store is meant to be the evidence they can open later, not a copy we degraded. Send such a file as it came; if it is too large for this channel, do not send a worse version — a person can add it themselves in the editor, where the limit is about 4 MB and nothing is re-encoded. Give them this passport’s `add_document_url`, and say which file you mean. If you DO re-encode a photograph, say `image/jpeg`, or the upload is refused for not being the type it claims; naming the file `.jpg` as well is a courtesy to whoever reads the library later. A PICTURE INSIDE A FILE THEY GAVE YOU — a product photograph printed in a datasheet — is worth OFFERING, because they have the datasheet and do not have the picture. This is the ONE exception to never re-encoding a specification sheet, and it is narrow: you are taking the photograph out of it, not shrinking the sheet. The sheet itself still goes as it came, or not at all. Offer it; do not do it unasked. If they say yes, send it yourself with this tool, so it is recorded as yours and named to whoever publishes. Do NOT hand it to them to upload: a file a person uploads is taken as theirs, and this one is not. Send ONLY the picture itself, cropped to it — never a whole page. A page of a datasheet is a page of small print, and shrinking that to fit destroys the thing that makes it worth keeping, which the rule above forbids. Send it as `type: image`, or it is filed as paperwork and nobody finds it among the photos. Say where it came from and do not present it as the manufacturer’s own photograph — pulling a picture out of a document often redraws it rather than copying it, so it can differ from the original in ways neither of you can see. And say what it is FOR: a working image so the draft is not empty. It is small, because you had to type it. TELL THEM TWO THINGS ABOUT IT. First, it becomes the product’s picture in the grid view of their product list, until they pick another one — the photos section of the editor has a chooser. Second, it stays restricted, so nobody outside their workspace sees it and it is not on the public product page. Leave it that way and let them replace it; the visibility rule further down says restricted files stay off the public page. PDF, PNG, JPEG and WebP only, and the content must really be that type. The file is stored as RESTRICTED. Publishing the passport does not change that: a restricted file is never shown on the public product page, and it cannot yet answer a passport field that expects a public document, such as a declaration of conformity. The same is true of a product photograph: it stays out of the public page until someone raises it. To use a file either way, a person has to raise that file’s visibility in the document library — so tell them, and give them the `library_url` this tool returns, which opens that library. It lists every file, so name the file you sent as well as the address. THIS DOES NOT APPLY TO A PICTURE YOU TOOK OUT OF ONE OF THEIR DOCUMENTS. That one stays restricted: it is a placeholder you made, not a file they asked you to store, and putting it on the public page would show a shopper an image a model produced. Attaching to a passport the public can already see is refused.
list_units	List the individual units recorded against a battery model passport.
create_unit	Record serial-numbered units against a battery model passport. A unit status must be one the regulation names; free text is refused and the refusal lists what is allowed.
request_publish	Ask a person to publish this passport. This NEVER publishes. It puts the passport in their list of things to approve and returns a link they open. Publishing is a declaration to a regulator, and it stays a human decision. When you report back, tell the person WHAT you wrote and hand them the link — they arrive in the editor with only your marked fields to go on, so your message is the context for their decision.
get_publish_approval	Read the outcome of an earlier publish request: still waiting, approved, expired, or withdrawn by a later change. There is no decline button in PassportCraft. If the person does not want it published, either leave the request to expire on its own, or withdraw it by making any further edit to the draft.