I am trying to retrieve the content of a document via api/documents endpoint as per Select rich text Field. All I am getting is
{"secret":"<requested document guid>","content":"<p data-guid=\"1c5882ad-b588-4f58-95cd-6f7fbdb18a9b\"></p>"}
The same data-guid seems to be returned for any document. What is it and how do I get the actual content?
Hello,
It is a default response even if document is not found you’ll get empty paragraph.
Please make sure you pass correct secret uuid as a part of the URL.
Suppose you’ve got an Entity with Description field via fibery.entity/query and the result looks like
{
"fibery/id": "c1ff9530-e57a-44af-8769-f59558d8672a",
"Feature/Description": {
"fibery/id": "ddff9530-e57a-400f-8769-f59558d86444",
"Collaboration~Documents/secret": "79a5d180-b9b1-41e1-82a5-397a7770ca30"
},
}
You should pass into /api/documents the value of Collaboration~Documents/secret
Hope this helps
Thanks for reaching back.
I find all this very confusing. To begin with, I referred to API docs expecting to find a ready answer on how to retrieve a document. Much to my surprise, Document doesn’t exist there as a concept (while it obviously exists in UI). I had to Ctrl-F through the lengthy page to find out that content-centric operations are buried down within “rich text Field”. Considering the use case, why should one care about such technical internals at all? The task is to get document content by id, as simple as that. While the endpoint is definitely simple, it seems (based on your reply) to come along with a clumsy prerequisite protocol. Then goes the “magic” with fibery/secret. Come on, didn’t you think to come up with some self-explaining name (let alone a meaningful concept)? In the end, after a few more attempts I’m still unable to get the content of a single document (see below on that).
This is important and useful information. However, I can’t believe one can consider it a good API pattern. In any case, if you decide to go with something subtle like this, it won’t hurt to put a big warning in the docs.
I think it’s a shining example of cognitive disconnect that API brings as concerns documents.
User: “How do I get a document?”
Developer: “Start with an entity.”
User: “Entity? What the freaking entity?”
I don’t have an entity (whereof I am aware). After reading your direction my first thought was: “Alright, as long as I am dealing with magic LISPy database, I should obtain secret id somehow”. So I fired
"query": {
"q/from": "Collaboration~Documents/Document",
"q/select": ["fibery/id", "Collaboration~Documents/secret"],
"q/where": ["=", ["fibery/id"], "$id"],
"q/limit": 1
},
"params": { "$id": "<my document id>" }
(I love these secret monikers Collaboration~Documents/Document and Collaboration~Documents/secret. No, in fact I don’t. Not in API at least).
I got
success: true
result: []
Moreover, I went through all Collaboration~Documents/Documents returned by the query API. Nope. Target document’s id is not in there. It suggests that the document is not of Collaboration~Documents/Document breed. This leaves me wondering what breed it is and how can I get to its content.
It’s fair that the documentation for the API is not optimal, but with limited resources, the Fibery team is focussing on implementing stuff/writing guides which benefit the broadest subset of users, and API users are in the minority (and are often more self-sufficient).
Unfortunately, the term ‘document’ can actually mean different things to different people in different contexts.
It can be a document view (an item in the left menu, in a specific space/folder), it can be a rich-text field (of an entity), or it can be one of a set of documents that ‘belong’ to an entity (attached via the document field)
(and possibly even something else entirely, but let’s not go there!)
I think @Viktar_Zhuk assumed you meant the second type given that you wrote
whereas it seems you probably meant something else, based on this:
…and to complicate matters, the majority of the content of the main API page relates to the ‘commands’ API (
https://YOUR_ACCOUNT.fibery.io/api/commands) with only a little bit about ‘views’ and ‘documents’ API calls.
Anyway, just to check, in the hope of figuring things out, where are you getting the document Id from?
Just for the context: I am self-sufficient (xx years of coding and former tech lead). I still can’t wrap my head around a basic task. I’m not expecting the documentation to be optimal. It shouldn’t be confusing in the first place.
I find this very unfortunate for such a technical subject as API.
I ended up with rich text field because it is the only place in the documentation that mentions documents.
“Press Alt to see UUID” in the document toolbar.
Actually, a document has a very strict definition from a technical perspective, it’s just that it’s used in many various different places, and may be named otherwise when seen from a ‘normal’ user’s perspective.
Hello,
You haven’t find it in the api description just because work with Documents View doesn’t has a public api yet. You may get a sneak pick here in the user guide . | Fibery ( How to work with Documents? section ).
We do not guarantee that API doesn’t change some day.
Thanks, this explains a lot.
For those that find this post trying to retrieve Document view content using the API let me make it really easy for you:
import requests
import os
# How to work with Documents views in Fibery API
# Note that as of 2023-08-23 this API is still undocumented and likely to change in the future. See also:
# https://the.fibery.io/@public/User_Guide/Guide/API---FAQ-179/anchor=How-to-work-with-Documents--c1401b93-73e5-4f91-a047-3d8403d41198
# https://community.fibery.io/t/retrieving-document-content/4772
# 1) Retrieve the document secret of the corresponding collaborative document.
# Base URL and headers
BASE_URL = 'https://YOUR_ACCOUNT.fibery.io/api'
HEADERS = {
'Authorization': f'Token {os.getenv("FIBERY_TOKEN")}',
'Content-Type': 'application/json',
}
# Data for the request
# The publicId of a document can be obtained from the URL of the document view in Fibery
# https://ecomanalyticsco.fibery.io/FAQs/About-Us-123 (where 123 is the public id of the document view)
query_payload = {
"jsonrpc": "2.0",
"method": "query-views",
"params": {
"filter": {
"publicIds": ["123"]
}
}
}
# Make the request, get the document secret uuid
response = requests.post(f'{BASE_URL}/views/json-rpc', headers=HEADERS, json=query_payload)
document_secret = response.json()['result'][0]['fibery/meta']['documentSecret']
# 2) Retrieve the document using the document secret.
# multiple formats are available: html, md (Markdown), json
# see also: https://api.fibery.io/?shell#select-fields
document_response = requests.get(f'{BASE_URL}/documents/{document_secret}?format=md', headers=HEADERS)
document_data = document_response.json()
# Print the document content
print(document_data['content'])
Okay, so the Fibery MCP also doesn’t support accessing document views.
It has been 5 years and I never knew about this limitation, but I think that this should be prominently featured in the docs re: views vs entities.
I don’t have much value for docs I can’t extract via API or interact with via MCP so… this sucks.
