How-to guides
How to keep your own documents in sync
Send documents from SharePoint, Google Drive, a network share, or your own machine into GPTree from your own code, retry safely, remove what your source removed, and hand over files too large to process on the spot.
If your documents live somewhere GPTree does not reach, you can send them yourself. This covers the four things a working sync has to do and the one that is easy to forget.
Send a document
Post the document with an identifier of your own choosing. Use the identifier your source system already uses: a file path, a SharePoint item id, a Drive file id. Send the same identifier again and GPTree updates that document rather than creating a second one, so you never keep a mapping table of your own.
You can send text you have already extracted, or upload the file and let GPTree read it. PDF, Word, Excel, Markdown, CSV, JSON and plain text are all handled, which means you do not need a document parser of your own before you can start.
Retry without wondering what happened
Send a header naming the delivery, and a retry after a timeout is free. The response tells you two things:
- whether this call did the work or found it already done
- where the delivery sits in your account's running sequence
Those two together are what let a sync stop guessing. Without them, a request that timed out leaves you unable to tell a successful retry from a second write, and the only safe move is to send everything again.
Base the delivery name on the document and its revision, not on its contents. GPTree already compares contents underneath, and contents cannot tell a retry apart from an edit that happened to produce the same words.
Remove what your source removed
This is the one that is easy to forget, and the only one that fails quietly.
A document you simply stop sending is not deleted. That is deliberate: a batch that is missing a document looks exactly like a filtered query, a partial run, or a job that crashed halfway, so GPTree will not conclude a document is gone from the fact that it did not arrive. If it did, one bad night would empty your library.
The cost is that your sync has to notice removals and say so explicitly. Skip that and everything looks fine: documents flow in, answers come back, and GPTree keeps quoting a policy your company withdrew months ago.
Deleting is safe to repeat, and the response says whether this call removed the document or found it already gone. An identifier GPTree has never been sent comes back as an error rather than a cheerful success, because "I never sent you that" is usually a bug on your side.
If the document reappears in your source and you send it again, it comes back. A delete is not permanent erasure; passages you already cited keep resolving.
Hand over the large ones
A long contract is not processed while you wait. Large documents and every file upload are accepted for background work and come back with a job reference, which you check until it says it finished or failed. Failures always carry a reason, so you can tell an unreadable file from a temporary problem.
There is no third state to interpret. A job is queued, running, succeeded, or failed.
A job that stops making progress is closed out as failed rather than left waiting, so your sync never sits on an answer that is not coming. The reason tells you which kind of problem you have: a document GPTree could not read is yours to fix and worth looking at before you send it again, while a job that did not finish is ours and is worth simply retrying. Nothing is ever partly added, so sending the same identifier again is always safe.
Check what GPTree holds
You can list everything that arrived through your integration, filtered to just your own documents rather than mixed in with your chats and uploads. Each entry carries the identifier you sent, so comparing your source against GPTree is a straight comparison of two lists.
What you need
A token with permission to add documents, created in Account on the Developer tab. Sending text you have already extracted works on every plan. Uploading a file for GPTree to read needs a Pro or Team plan, because reading a large file takes a background worker for several minutes. A worked example with real requests and responses is published alongside the full API reference.