The right route to your data.
Bring your own proxy or choose an ApiClay pool. Manage rotation, bandwidth caps, and eligible fallback alongside your API.
- Private or platform proxy poolsBring a provider or choose a platform pool.
- Per-call bandwidth capsBound platform bandwidth per request.
- Rotation and optional fallbackConfigure recovery deliberately.
See how a backup connection reaches the source.
Follow a weather request through its configured proxy path. If the primary connection fails, try a configured backup. The app on the right can display weather only when a source responds.
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 request, a suitable proxy pool, and a route policy. Add fallback configurations only where they are useful for your upstream.
Workflow: Choose the primary proxy configuration and any backups, then test the route. Review how failures, response size, and proxy use affect the request.
Result: A centralized routing policy for your published API. Consumers use the API contract while the publisher controls the upstream proxy configuration.
Test the primary path and expected failure cases. Set the supported byte cap and review applicable infrastructure pricing before increasing traffic.
Choose the route your request takes.
Make ownership, limits, and fallback explicit before you send traffic.
- 1
Choose a provider
Use private credentials or an available ApiClay pool.
- 2
Set your limits
Select country, payer, and a per-call bandwidth cap.
- 3
Test your policy
Verify execution before enabling backup or paid fallback.
Make the connection policy explicit.
Choose who supplies the proxy and who pays before a request enters production.
- Residential, mobile, ISP, and datacenter pools have different rates.
- A byte cap bounds bandwidth; it does not guarantee completion.
- Private proxy costs remain with your external provider.
Example policy choices, not an API payload or price quote. Available countries and current pool rates are shown in configuration.
Primary: your private proxy
Backups: up to 9 additional proxies
Credentials: stored server-side
Eligible failure → rotate to a configured backup
Blocked proxy → temporary cooldownPool: Residential
Country: an available target region
Bandwidth cap: 2,000,000 bytes per call
Payer: vendor, under route settlement rules
Optional fallback: one eligible retry
Buyer fallback charge: only on successful rescueRotate when a proxy fails
Configure a primary proxy and up to nine backups for eligible failures.
Keep bandwidth bounded
Set a byte cap and review current pool rates before production.
A proxy policy that belongs with the API contract
Web-backed APIs need an explicit way to reach their sources. Proxy choice affects access, reliability, bandwidth, and route margins. ApiClay keeps that policy next to the route or aggregator source, so publishers can decide which proxy to use and who pays for the traffic before requests reach production.
Use a private proxy when you already have a provider relationship. Choose a vendor-paid platform pool when proxy costs belong in the route price, or a buyer-supplied policy when the caller should choose the connection. Each model has different billing responsibilities; inspect those responsibilities together with the source's expected response size.
Keep private proxy credentials server-side
Publishers can supply a primary private proxy and up to nine backups, or identify a rotating gateway.
How it works
Store reusable credentials in Vault blocks instead of copying them into public inputs. Failed or blocked proxies can be temporarily benched before the gateway retries an eligible request with another configured proxy.
Buy only the platform bandwidth used
ApiClay pools meter traffic at the wire level, including relevant request and response transport bytes.
How it works
A per-call cap bounds the permitted bandwidth for that policy. Estimate with representative live requests because compressed content, assets, redirects, and browser behavior can change usage between targets.
Protect vendor pricing against configured caps
For vendor-paid platform proxies, the publisher flow enforces a minimum route price that covers configured proxy caps plus the platform floor.
How it works
Aggregators must account for their platform-proxy sources together. This guard addresses configured successful-call proxy economics; it is not a forecast of revenue or an unconditional business profit guarantee.
Enable a rescuing fallback deliberately
Optional ApiClay fallback can retry an eligible proxy-related failure once through a platform pool.
How it works
It is designed for recoverable connection, quota, block, or timeout conditions, rather than every upstream error. Buyer fallback bandwidth is charged only when the retry succeeds and its response is used. Eligibility rules also distinguish trial and plan traffic.
Where this fits into your work.
Regional data retrieval
Select an available country pool for a source that responds differently by region, then test that the returned data matches the route's promised contract.
Existing proxy providers
Reuse a private proxy subscription while letting ApiClay handle the public API contract, secret injection, request limits, and buyer-facing metering.
Multi-source resilience
Combine each aggregator source's proxy policy with source failover. Inspect source cooldowns and charges when deciding whether a backup is effective.
Start with a focused test.
Use these steps to set up Proxy Infrastructure and review the result before making it part of a larger workflow.
Configure an API proxy policy →- 1
Choose who supplies the proxy
Select a vendor-owned private proxy, vendor-paid ApiClay pool, or buyer-supplied policy. Configure the policy independently for each relevant route or aggregator source.
- 2
Set pool, country, and limits
For platform pools, choose the available residential, mobile, ISP, or datacenter option and country. Set a per-call byte cap and review the resulting minimum route price.
- 3
Test rotation and fallback
Run a live request with the actual policy. Review usage and failure reasons before enabling backup proxies or optional paid fallback.
Understand each workflow’s cost.
Match the feature’s limits and billing model to the work you want to run.
Explore API listings →Vendor-paid platform proxy charges are deducted under the route's settlement rules. Buyer-selected pools and eligible successful fallback traffic are billed to the buyer. Private proxy costs remain subject to your external provider's terms.
ApiClay absorbs its documented failed-call platform-proxy bandwidth costs. This does not refund an external proxy provider's invoice. Pool rates and the selected cap determine platform bandwidth exposure, so inspect current values in the configuration and usage ledger.
Open an API listing for its Reference, Playground, and Pricing. Check the selected route’s allowances and applicable infrastructure charges before increasing usage.
FAQs
Can I bring my own proxy?
Yes. Configure a private proxy and optional backups, or use a rotating proxy gateway. ApiClay does not replace your agreement or billing relationship with that external provider.
Are ApiClay proxies free during an API trial?
Do not assume a listing's free route allowance includes platform infrastructure. Platform proxies are metered, and trial and plan eligibility rules restrict how fallback is used. Review the route's current configuration and pricing disclosures.
Does fallback retry every API error?
No. Fallback is optional and applies to eligible failures another proxy may resolve. Ordinary missing-resource or upstream application errors are not a reason to retry through a paid pool.
Does a bandwidth cap guarantee the request completes?
No. It limits permitted traffic. A response or browser workflow that needs more data may fail at the cap, so choose a cap using representative measurements and inspect data-cap events.
Make every connection deliberate.
Configure your proxy policy alongside the API it serves.