Developer guide · Data
Build permitted work across your connections.
Identify who acts, define the scope and use the interface that supports the operation. People use the workspace, applications use enabled APIs, and assistants work inside Data from chat.
Use this architecture and interface reference to choose the right path. Request the current API access and authentication instructions for the operation you intend to build.
Request Data API access detailsAn enabled metadata request
A request. A scope. An attributable result.
An application requests permitted workspace metadata. Data checks the application and the granted operation, then returns the authorized result. This request does not move provider content.
Your application
The request names its authority.
- Identity
- The configured application
- Operation
- Enabled metadata request
- Scope
- Permitted resources in the selected workspace
Rhea Data
The result stays within the grant.
- Check the application, requested operation, resource and limits.
- Return only the metadata allowed by this interface and permission.
- Record the attributable Rhea activity and outcome.
Customer infrastructure remains separate: your accounts, provider-held content and storage billing. A content request uses its own supported execution and credential mode; it is not implied by this metadata example.
Who does the work
Three actors. One customer-controlled data layer.
Customers choose and pay for their storage. Rhea Data brings permitted work together across connected providers rather than selling replacement storage capacity.
- 01
People
Work directly in the Rhea Data workspace. Authorize the session once, then work within granted permissions.
- 02
Applications
Use enabled API operations across configured connections. Application identity, granted scope and usage limits determine the permitted result.
- 03
AI assistants
Review permitted document and folder metadata inside Data from chat after one explicit connection authorization. The documented interface excludes file contents. Review activity and disconnect to stop further access.
Operation scope
Use the interface that supports the work.
- People in the workspace
Open permitted files and manage supported file work.
Operations depend on connection permissions and product mode. Sensitive work can require explicit approval.
- Applications through the REST API
Use documented, enabled endpoints with application identity and scopes.
The public REST upload endpoint is disabled (410). Customer-authorized workspace uploads use a separate product pipeline.
- Assistants inside Data
List documents, folders and versions; review document metadata from chat.
The documented assistant interface is read-only metadata, scoped to the permitted organization and read grant. File contents and arbitrary provider mutations are not included.
- Provider request signing
Prepare authorized requests for the six storage families below.
Signing and a connection check do not establish upload/download or movement acceptance in your environment.
- Database connection settings
Configure PostgreSQL, MySQL and Microsoft SQL Server connection types.
Direct SQL query execution is disabled. Configuration is not live query access.
Authorization / transfer
Authority and execution have different jobs.
Selected content example: a person accesses permitted content from the workspace through an authorized-client path. Metadata API requests and assistant metadata review use their own interfaces.
1
Authorization
The person requests a permitted content operation from the workspace. Check the session, target, granted permissions and limits before preparing a provider request.
2
Request signing
Prepare the permitted provider request using the connection’s applicable signing path and credential-custody mode. Signing follows authorization; it does not replace it.
3
Content transfer
The authorized client uses the provider request to transfer permitted content. Client-side protected-file handling and ciphertext relay/copy fallback are distinct paths.
4
Attributable activity
Record who acted and what happened. Authorization, rate limits, billing and audit metadata still involve server-side responsibilities.
Storage integration reference
Implemented storage-signing paths
This describes request-signing implementations. Connector enablement, supported operations and live deployment are confirmed separately.
| Storage | Signing and path detail |
|---|---|
| Amazon S3 | SigV4 S3-compatible request signing. |
| Microsoft Azure Blob Storage | Service SAS Shared-path PUT adds x-ms-blob-type: BlockBlob. |
| Google Cloud Storage | GOOG4-RSA-SHA256 RSA-signed storage requests. |
| Oracle Object Storage | SigV4 Uses the S3-compatible access path. |
| MinIO / S3-compatible | SigV4 Uses S3-compatible request signing. |
| Cloudflare R2 | SigV4 Shared path uses the account endpoint, path-style addressing and region auto. |
Technical scope
Signing paths have different conditions.
- 01
Browser signing is conditional
The browser path dispatches GET / PUT / HEAD / DELETE only when credentials are held by the customer in that custody mode. This does not describe every product mode.
- 02
Shared signing path
The shared presigner dispatches signed GET / PUT / HEAD to S3-compatible storage, Azure and GCS. Browser DELETE dispatch does not establish DELETE in this shared path.
- 03
Multipart differs
The S3-style multipart helper rejects Azure and GCS with PART_URLS_UNSUPPORTED. This is a limit of that helper, not evidence that no other provider-specific upload path exists.
- 04
Scope beyond object storage
These signing implementations do not establish shipped database engines or consumer cloud-drive connectors. Confirm each integration’s available operations separately.
Integration responsibilities
Validate the path your application actually uses.
- Confirm the provider, endpoint/addressing requirements, credential-custody mode and permitted operations without placing production secrets in frontend examples.
- Enforce access before signing; keep routine permitted operations within the authorized session or assistant connection.
- Check provider-specific upload requirements, transfer outcomes, permissions and attributed activity in the intended deployment.
- Test real cloud transfers and deployment separately. Implemented signing code alone does not establish successful end-to-end integration.
Continue
Continue with Rhea Data.
Return to the product overview or explore the other integration guides.