Download OpenAPI specification:Download
The FileOnion Document AI API provides a powerful set of tools for processing and analyzing documents.
This documentation outlines the available endpoints and their usage. The API supports multiple
file formats and provides detailed content extraction, including text and image analysis.
This API is particularly useful for applications that require document processing, content extraction, and text analysis.
The API uses JWT-based authentication. To access the endpoints, you need to provide a valid JWT token in the Authorization header.
Note: The JWT token should be prefixed with 'Bearer'. If you don't have a JWT token, please contact the FileOnion team at support@fileonion.com obtain one.
This endpoint enables you to upload documents to the FileOnion system. You can specify a callback URL to receive notifications regarding the storage process, and provide a list of document URLs. In response, you'll receive details about each stored document, including its assigned URL, collection ID, original size, and processing time.
| callbackUrl | string <uri> The URL where the system will send a notification upon successful storage. |
| documentUrls required | Array of strings <uri> [ items <uri > ] A list of URLs pointing to the documents to be stored. |
{
}[- {
- "collection": "395d8207-c910-4705-9e88-5eb00b24a324",
- "size": 0.184292,
- "durationInSec": 2.559
}
]This endpoint utilizes AI to search through previously uploaded documents for content that aligns with the specified prompt. The endpoint processes the query against the documents in the designated collection and returns results that match the query's intent.
| collection required | string The name of the collection containing the documents to search. |
| query required | string The prompt or query to search for. |
| stream | boolean Whether to stream results as they are found (default false). |
{- "collection": "395d8207-c910-4705-9e88-5eb00b24a324",
- "query": "Give me a list of questions to ask",
- "stream": false
}{- "answer": "Based on the provided context, here are some questions you might consider asking:\n\n1. How does the proposed system maintain privacy while announcing all transactions publicly?\n2. What role do public keys play in maintaining anonymity in the transaction process?\n3. Why should a new key pair be used for each transaction?\n4. What are the potential risks associated with multi-input transactions in terms of privacy?\n5. How does the system prevent double-spending without a trusted third party?\n6. What is the role of the timestamp server in this electronic cash system?\n7. How does the proof-of-work mechanism contribute to the security of the network?\n8. What does it mean for the network to be robust in its unstructured simplicity?\n9. How do nodes express their acceptance of valid blocks?\n10. What are the potential consequences if an attacker generates an alternate chain faster than the honest chain?\n11. How does the probability of an attacker catching up with the honest chain change with the number of blocks?\n12. Why is it important for the majority of CPU power to be controlled by honest nodes?\n13. What are the weaknesses of the traditional trust-based model of online commerce?\n14. How does the proposed system address the issue of non-reversible transactions?\n15. What are the advantages of using a peer-to-peer network for electronic transactions?",
- "sourceDocuments": [
- {
- "pageContent": "pageContent: >- 10.Privacy\nThe traditional banking model achieves a level of privacy by limiting access to information to the \nparties involved and the trusted third party. The necessity to announce all transactions publicly \nprecludes this method, but privacy can still be maintained by breaking the flow of information in \nanother place: by keeping public keys anonymous. The public can see that someone is sending \nan amount to someone else, but without information linking the transaction to anyone. This is \nsimilar to the level of information released by stock exchanges, where the time and size of \nindividual trades, the tape, is made public, but without telling who the parties were.\nAs an additional firewall, a new key pair should be used for each transaction to keep them \nfrom being linked to a common owner. Some linking is still unavoidable with multi-input \ntransactions, which necessarily reveal that their inputs were owned by the same owner. The risk \nis that if the owner of a key is revealed, linking could reveal other transactions that belonged to \nthe same owner.\n11.Calculations\nWe consider the scenario of an attacker trying to generate an alternate chain faster than the honest \nchain. Even if this is accomplished, it does not throw the system open to arbitrary changes, such \nas creating value out of thin air or taking money that never belonged to the attacker. Nodes are \nnot going to accept an invalid transaction as payment, and honest nodes will never accept a block \ncontaining them. An attacker can only try to change one of his own transactions to take back \nmoney he recently spent.\nThe race between the honest chain and an attacker chain can be characterized as a Binomial \nRandom Walk. The success event is the honest chain being extended by one block, increasing its \nlead by +1, and the failure event is the attacker's chain being extended by one block, reducing the \ngap by -1.\nThe probability of an attacker catching up from a given deficit is analogous to a Gambler's \nRuin problem. Suppose a gambler with unlimited credit starts at a deficit and plays potentially an \ninfinite number of trials to try to reach breakeven. We can calculate the probability he ever \nreaches breakeven, or that an attacker ever catches up with the honest chain, as follows [8]:\np = probability an honest node finds the next block\nq = probability the attacker finds the next block\nqz = probability the attacker will ever catch up from z blocks behind\nqz={1ifp≤q\nq/pzifpq}\n6IdentitiesTransactionsTrustedThird PartyCounterpartyPublic\nIdentitiesTransactionsPublicNew Privacy ModelTraditional Privacy Model metadata: pageNumber: 6 "
}
]
}This endpoint enables you to delete documents from the FileOnion system. The endpoint will process the request, remove the specified documents from the specified collections, and send a notification to the provided callback URL (if specified) when the process is complete. If no callback URL is provided, the results will be returned in JSON format.
| callbackUrl | string <uri> The URL where the system will send a notification upon successful removal. |
| collections required | Array of strings A list of collection names to delete. |
{- "collections": [
- "395d8207-c910-4705-9e88-5eb00b24a324"
]
}[- {
- "collection": "395d8207-c910-4705-9e88-5eb00b24a324",
- "durationInSec": 0.025
}
]This endpoint enables you to submit documents for analysis. The endpoint will process the documents, generate detailed summaries, identify relevant tags, and provide information about the original document size and processing time. The results will be sent to the specified callback URL (if provided) or returned in JSON format.
| callbackUrl | string <uri> The URL where the system will send a notification upon successful analysis. |
| documentUrls required | Array of strings <uri> [ items <uri > ] A list of URLs pointing to the documents to be analyzed. |
{
}[- {
- "result": {
- "summary": "The document presents a proposal for a peer-to-peer electronic cash system, Bitcoin, which allows direct online payments without the need for a trusted third party. It addresses the double-spending problem through a distributed timestamp server that uses proof-of-work to establish a secure, chronological order of transactions. The system's security relies on the majority of CPU power being controlled by honest nodes, and it includes mechanisms for transaction privacy, incentive structures, and simplified payment verification. The document also discusses the technical aspects of proof-of-work, network operations, and the probability of an attacker's success in altering the transaction history.",
- "tags": [
- [
- "Bitcoin",
- "Cryptocurrency",
- "Blockchain",
- "Proof-of-Work",
- "Decentralization"
]
]
}, - "size": 0.184292,
- "durationInSec": 5.616
}
]This endpoint enables you to submit images for analysis. The endpoint will process uploaded images, generate detailed summaries, identify relevant tags, and provide information about the original document size and processing time. The results will be sent to the specified callback URL (if provided) or returned in JSON format.
| callbackUrl | string <uri> The URL where the system will send a notification upon successful analysis. |
| imageUrls required | Array of strings <uri> [ items <uri > ] A list of URLs pointing to the images to be analyzed. |
{
}[- {
- "result": {
- "summary": "The image shows a military draft registration card for Howard da Silva, detailing his personal information, place of residence, employment, and physical characteristics for the U.S. government documentation.",
- "tags": [
- [
- "draft card",
- "Howard da Silva,",
- "military registration,",
- "1940s document,",
- "personal information"
]
]
}, - "size": 2.142714,
- "durationInSec": 4.205
}
]