Direct SDK/API Quickstart
Upload documents, wait for processing, then search them from your application using the GroundX SDKs or REST API. You can pass the search results to a language model as context for its answers.
To have Claude, Codex, or another agent run these operations, see Install GroundX Agent Harness.
This guide covers:
- How to get your GroundX API Key
- Setting up GroundX
- How to create a new bucket
- How to use an existing bucket
- How to upload content to a bucket
- How to check the status of your upload
- How to search for content
- How to use your search results to augment an LLM (i.e. RAG)
Step 1: Getting Your API Key
First, create an account.
Log into the GroundX Dashboard and navigate to API Keys.

Store your API key in the GROUNDX_API_KEY environment variable. Keep it out of source code and chat.

Step 2: Setting Up GroundX
Install the Python or TypeScript SDK:
Initialize the client using your GROUNDX_API_KEY environment variable:
For other languages, or without an SDK, use cURL or any HTTP client.
Step 3: Creating a New Bucket
GroundX identifies text, graphics, and tables, then converts them into text a language model can use. It adds context from elsewhere in the document to each section. These contextualized sections are called semantic objects.
A bucket stores the semantic objects from your documents and lets you search them with natural language queries. Create a bucket and save its unique ID for uploads and searches. Bucket names do not have to be unique:
Step 4: Using an Existing Bucket
List the buckets in your GroundX account:
Use the bucketId of the bucket you want to upload to or search.
Step 5: Upload Content
The Document Upload API processes local files or documents available at a URL and stores their semantic objects in a bucket.
To upload a local file:
/v1/ingest/documents/local accepts one file per call, up to 8MB, and does not support
callbackUrl/callbackData. For larger files, multiple files in one batch, or callback
support, use the client.ingest() SDK method shown above (it uploads via a pre-signed
URL behind the scenes) rather than calling this endpoint directly.
To upload a second file, send another request the same way:
To ingest a document from a URL:
See the Ingest API for all arguments.
Both local and remote ingest return a response with this shape:
The processId can be used to check the status of the upload.
Step 6: Check the Status of Your Upload
Check processing status:
Use the processId returned by ingest.
The response has this shape:
Poll while status is queued, training, or processing. Search after
complete; investigate error or cancelled before continuing.
Step 7: Search Your Content
Search the processed documents:
Use a bucketId to search one bucket, a groupId for a group of buckets, or a
documentId for one document. Set query to your search question.
The response has this shape:
Find groupId and bucketId values in the GroundX Dashboard or through the list APIs.
Step 8: Using Search Results to Augment an LLM
Use search.text as context for your language model. If you build your own
context from individual results, use search.results[n].suggestedText.
Read search.text from the response:
Combine your instructions and GroundX context, then submit them to OpenAI. For a system prompt example and guidance, see Prompting and Integration.
Set openaiModel to your model, instruction to your instructions, llmText
to the GroundX context, and query to your question. This is retrieval augmented
generation (RAG): the model answers using retrieved document content.
Errors and Rate Limits
HTTP status codes
All GroundX API endpoints use standard HTTP status codes. The two you’re most likely to encounter while integrating are:
For 401, check the X-API-Key header and the key’s resource access. For 400,
check the request body and path/query parameters. The response usually describes
the validation problem.
Ingest limits
Check file size and page count before uploading. Split documents above the recommended limits to keep searches focused. Batches of 20 leave room for retries and reduce timeout risk on slower connections.
Search limits
Queue or debounce search requests in your application to stay within these targets. If you fan out a single user query to multiple buckets or groups, count each search call separately toward the concurrency limit.
Handling HTTP 429
If you receive a 429 Too Many Requests response, back off and retry with exponential
delay: start at 1 second, double on each retry, cap at 60 seconds. Don’t retry
immediately.
Next Steps
See Prompting and Integration for guidance on producing consistent answers.

