Skip to main content
Rock API processes your API credentials and request content to authenticate, route, and bill model calls. The gateway forwards request content to an upstream service for inference. Before sending sensitive data, review both gateway handling and the terms that apply to the actual upstream route. This page describes verified implementation behavior and actions you can take. Production settings, operational retention schedules, and upstream contracts require separate confirmation; implementation alone does not establish those policies.

​
Where request data goes

  1. Your application sends its API key and request to the HTTPS endpoint https://rockapi.ai/v1. Keep this call on your backend; see Authentication.
  2. The gateway checks the key and account, applies configured restrictions, and selects an upstream channel. Depending on the endpoint and channel settings, it can map model names, convert request formats, apply parameter overrides, or forward the request body in passthrough mode.
  3. The upstream service receives the content needed for inference, including messages, tool inputs, and supplied media or media references. The gateway processes the response and usage information and returns the result to your client.
  4. Usage and error records support billing and troubleshooting. Asynchronous media tasks can also store task inputs, status, provider data, and result URLs; their records differ from text request logs.
Passthrough mode is a forwarding option, not anonymization. Standard upstream adapters use the channel’s configured credentials. Wildcard and regex header forwarding exclude cookies and common credential headers, but explicit channel header overrides can change forwarding behavior. Avoid placing secrets or personal identifiers in custom headers.

​
Protect and revoke API keys

Create separate API keys for each application and environment. Where available in the key editor, set an expiry, a limited quota, permitted models, and an IP allowlist. The implementation checks key status, expiry, available quota, and configured IP restrictions before model relay; model restrictions constrain routing. Test allowlists from your application’s actual outbound IP. Store keys in a server-side secret manager or protected runtime configuration. Keep them out of browser bundles, mobile apps, repositories, URLs, screenshots, and shared request traces. Prefer the documented authentication header over a query-string credential. Key list and detail responses mask the key, while a separate authenticated operation can retrieve its full value. Masking is a display control; it does not establish irreversible hashing or encryption at rest. For routine rotation, create a replacement key, update the application, verify a request, then disable or delete the old key. If a key leaks, disable or delete it first, replace it, and inspect usage logs for unexpected calls. Verify that the old key is rejected; contact support if it remains usable. Revoking a key does not delete historical records.

​
What logs can contain

Consumption logging and usage aggregation are configurable. User-facing log views remove some administrative details, so a dashboard view does not enumerate every stored field. Turning off one log category or IP preference does not disable all access, security, task, or infrastructure records. See Pricing and billing for reconciling consumption.

​
Minimize the data you send

Send only the conversation turns, document excerpts, tool results, and media required for the task. Remove passwords, access tokens, payment details, and unrelated personal information. Replace customer identities with internal pseudonyms and keep the mapping in your own system. Review filenames, media metadata, custom headers, and signed URLs as well as prompt text. Use synthetic data while validating a new integration. For support, start with the request or task ID, timestamp with timezone, model ID, endpoint path, HTTP status, and key label. Add a short redacted error or minimal reproducible example if needed. Do not send the full API key, authorization header, private conversation, or an unredacted signed media URL.

​
Retention, training use, and compliance

The implementation establishes processing and logging capabilities. It does not establish a blanket zero-retention policy, a no-training commitment, or a fixed deletion period for Rock API or every upstream. Before using sensitive data, contact support through the main site’s About page and confirm:
  • Retention and access: Which request bodies, outputs, task files, usage logs, access logs, and backups are retained? For how long, who can access them, and what exceptions apply?
  • Training and other uses: Do Rock API or the actual upstream use inputs or outputs for model training, evaluation, abuse review, or other purposes? What exclusions or opt-outs apply to your account and route?
  • Upstream and location: Which processors and regions handle the selected model, including retries or fallback routing? Are regional restrictions enforceable for your workload?
  • Contractual evidence: Is a data processing agreement (DPA) available? What transfer safeguards, security certifications, and audit reports apply to the contracted service and scope?
Obtain confirmation for the specific model, route, account, and data category before proceeding; a model name alone does not establish these terms.

​
Request account or data deletion

Stop the affected integration and revoke its keys when access should end. The account deletion operation uses a soft-delete mechanism; it does not demonstrate erasure of logs, backups, task outputs, or copies held upstream. Use the support channel on the About page to request deletion or a privacy review. Provide your account identifier, the data categories and time range, relevant request or task IDs, and whether the request covers upstream copies. Ask support to confirm the verification procedure, deletion scope, completion timeframe, backup handling, and any legally required retention. Share additional identity evidence only through the channel support specifies.