Share the data. Protect the source.
Keep upstream credentials private. Define what buyers can access, set usage limits, and separate API execution from account management.
••••••••••- Encrypted stored source credentialsProtect supported stored secret values.
- Scoped buyer execution keysSeparate execution from administration.
- Private listings and team rolesChoose who can manage and access data.
Show a customer the order, not the private source.
The protected source is on the left. ApiClay checks the buyer key and selects the approved fields. The customer page on the right shows the permitted result or an access error. Try both states.
From your input to a useful result.
- Choose a sample input
- Apply the feature’s workflow
- Inspect the result
This example runs entirely in your browser with illustrative data. Use the real feature’s guide and listing to check supported inputs, access rules, and pricing.
Explore the example, then use the setup guide to try the real feature.
Project setup and what to check
Input: A source connection, an approved set of fields, and the route’s access policy. Decide who should consume the published contract and which limits apply.
Workflow: Configure server-side credentials and route controls. Have the consumer call with a buyer API key, then review the resulting response and usage.
Result: A governed integration boundary: the consumer receives the published output while the upstream credentials remain outside its client code and prompts.
Test allowed and denied requests, inspect the exposed fields, and keep keys in protected application settings. Execution keys do not grant dashboard administration.
A clear boundary between source and consumer.
Protect private configuration while exposing the contract your buyers need.
- 1
Protect the source
Keep credentials and private values in protected configuration.
- 2
Define the contract
Choose public inputs, exposed fields, and usage limits.
- 3
Review access
Issue buyer keys and control owner/admin membership.
Expose a contract, not a credential.
Define the public surface while keeping private execution values on the server.
- Supported stored secrets use AES-256-GCM encryption.
- Buyer API keys are stored as hashes and stripped before upstream calls.
- Owners and admins manage listings and private session profiles.
An example of access boundaries, not a certification claim. The publisher selects which source fields and inputs to expose.
Public inputs: sku, page, limit
Public fields: id, title, price
Authentication: buyer apiclay_* key
Apply row limits, trial caps, and usage rules.
Review the actual response before sharing.Database connection → private
Upstream authorization → private
Proxy credentials → private
Saved session profile → private
Buyer keys authorize gateway execution.
They do not grant dashboard administration.Encrypted stored secrets
Supported values use AES-256-GCM encryption with tenant binding.
Keys for execution
Buyer keys are stored as hashes and do not grant dashboard administration.
Governed data access across publishing and execution
A data product should expose the information a buyer is entitled to use without handing over the underlying database connection, service token, or login profile. ApiClay separates the published contract from private execution configuration and provides controls at the account, listing, route, and datasource levels.
These controls support a reviewed API-sharing workflow; they do not decide which business data you are allowed to disclose. Publishers choose the source fields, query options, limits, and visibility. Teams should review the route's actual response and source permissions before making a listing public or inviting another administrator.
Encrypt stored secrets with tenant binding
Stored secret values use AES-256-GCM envelope encryption with tenant-bound authenticated data.
How it works
The protection covers supported credentials, private request values, proxy secrets, sessions, and cloud drafts. Encryption reduces plaintext exposure in stored records, while key management and account security remain essential to the overall control model.
Separate buyer keys from account administration
Buyer apiclay_* keys are stored as SHA-256 hashes and are limited to gateway execution.
How it works
They do not authorize dashboard account management and are stripped before upstream requests. Use separate workload keys where appropriate, keep their full values out of public clients and logs, and revoke them when access is no longer needed.
Publish only the data contract you intend
Datasource settings let publishers project columns, allow query fields, and cap returned rows and daily buyer usage.
How it works
Route configuration distinguishes public buyer inputs from private injected values. Private listing visibility restricts access to authorized company operators; public listings provide the sanitized documentation contract for marketplace buyers.
Isolate untrusted browser execution
Browser execution runs in an isolated plane with customer separation, restricted process environments, and Linux sandbox layers.
How it works
Company owners and admins manage private route actions and encrypted session profiles, so team membership deserves careful review. These technical controls are security mechanisms rather than claims of a particular regulatory certification.
Where this fits into your work.
Partner data access
Offer an approved table slice through an authenticated API instead of distributing a database connection string to each partner.
Credential-safe API wrappers
Keep an upstream service token private and expose only the inputs and mapped fields needed for a particular application workflow.
Controlled agent tools
Give an AI application a scoped gateway credential and a published route contract. Apply the application's own approval controls to consequential tool actions.
Start with a focused test.
Use these steps to set up Security & Governance and review the result before making it part of a larger workflow.
Discuss your security requirements →- 1
Restrict the source configuration
Use appropriate source credentials, mark private fields correctly, and keep reusable tokens or session details in encrypted Vault blocks.
- 2
Define the allowed contract
Choose exposed columns, public inputs, query fields, row caps, trial limits, and listing visibility. Validate the returned response in a private test.
- 3
Review execution and team access
Issue buyer API keys for workloads, restrict owner/admin membership to trusted operators, and review usage, charges, and source changes over time.
Understand each workflow’s cost.
Match the feature’s limits and billing model to the work you want to run.
Explore API listings →Governance settings and billing settings work together: row caps bound data exposure, while trial limits, quotas, and route charges govern consumption. Neither replaces authorization to use the underlying data.
Inspect each API listing's Reference and Pricing tabs for its public inputs and commercial terms. Use the support center for account or route issues, and the contact page for security questions that require a private discussion.
Open an API listing for its Reference, Playground, and Pricing. Check the selected route’s allowances and applicable infrastructure charges before increasing usage.
FAQs
Do buyers receive my database password or upstream token?
Private source credentials are held server-side and are not part of the public contract. Test your own route outputs as well: a source response can contain sensitive business data even when its authentication values stay private.
Can a buyer API key change my dashboard settings?
No. Buyer API keys are for gateway execution rather than dashboard administration. Protect and revoke keys appropriately because a valid execution key can still authorize paid requests within its access.
Does private visibility make API execution free?
No. Private visibility controls who can access a listing. Live tests and calls can still incur applicable route and infrastructure costs.
Who can manage a company's API listings?
Company owners and admins can co-manage listings, private route credentials, and saved session profiles. Review membership carefully because those roles can work with private route configuration and authorized source sessions.
Build access around a clear contract.
Discuss your requirements and choose the right controls for your workflow.