A head start for your next API.
Start with one of 12 editable recipes. Add your source, replace the placeholders, and test before you publish.
- 12 editable recipe patternsStart from a focused configuration.
- API and aggregator workflowsPick the pattern that fits your source.
- Your own credentials and pricingReplace placeholders before testing.
See what a recipe prepares—and what you still supply.
Choose an actual recipe from the catalog. See how it provides a starting configuration and which placeholders you must replace in the studio. A recipe prepares the form; it does not test or publish the API for you.
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 recipe from the gallery below and access to its required source. API recipes and aggregator recipes open in their corresponding studio workflows.
Workflow: Read the recipe JSON, open the studio, and adapt the configuration. Replace example inputs and credential placeholders before running a test.
Result: A working starting point you understand and can extend. Use the recipe to learn the route structure, mapping, or composition pattern rather than starting from a blank form.
Review dependencies, output fields, and execution costs. Test your customized configuration before publishing it for consumers.
A proven pattern. Your own configuration.
Start with editable JSON and make the contract yours.
- 1
Choose a pattern
Pick an API or aggregator recipe from the catalog.
- 2
Make it yours
Add your source, credentials, fields, and limits.
- 3
Test the contract
Review a real response before publishing.
One pattern. Your own source.
A recipe makes the starting configuration visible. Replace its placeholders and validate the parts your buyers will depend on.
- Choose among 12 editable API and aggregator recipes.
- Inspect the recipe JSON in the gallery below.
- Recipes provide configuration, not credentials or provider subscriptions.
Illustrative failover workflow. Select “Failover pair” in the aggregator studio and configure both upstream providers.
Primary source → mapped response
↓ eligible failure
Backup source → same public fields
Both sources must answer the same buyer question.Replace source URLs and private credentials.
Map both responses into the same public fields.
Test each source independently.
Review rate limits, proxy policy, and cost.
Publish only after a successful private test.Configuration you can inspect
Every recipe is editable JSON with visible inputs and mappings.
Bring your own source
Recipes include patterns, not credentials or provider subscriptions.
Explore all 12 starter recipes
REST API with API-key auth
One aggregator route backed by a single REST source that authenticates with an API key header. The most common shape.
RapidAPI upstream
Resell a RapidAPI-hosted API: source pre-wired with X-RapidAPI-Key and X-RapidAPI-Host headers.
Apify actor (scraped data)
Sell fresh scraped data from an Apify actor: buyers send a URL, the actor runs behind the scenes and returns its dataset items.
Weather API (key in query string)
Upstream that authenticates via a query parameter (OpenWeatherMap-style); buyer's city header is mapped into the query automatically.
News headlines (header auth)
NewsAPI-style upstream with a private X-Api-Key header; buyer's country code is injected as a query parameter.
AI completion (OpenAI-compatible)
Resell an LLM endpoint: buyers send messages, your model choice and Bearer key stay private, response is unified to a clean answer field.
Failover pair (primary + backup)
Two sources for the same data: the backup answers only when the primary fails or hits its rate limit. Includes schema mapping so both return identical fields.
Paginated list endpoint (custom HTTP API)
A custom HTTP route exposing a paginated upstream list: public page/limit query params for buyers, private auth header for you.
Sell a database table
Expose one MySQL/PostgreSQL table as a paid data API with per-request row limits and a trial cap.
JavaScript-rendered page as Markdown
Open one JS-rendered page in a real browser and sell its main content as clean Markdown; buyers can switch the rendering per call with X-ApiClay-Html.
Gated portal data (session bootstrap)
Sell data from a portal that needs a session: the gateway opens its landing page first, harvests the session cookie and CSRF token, and reuses them for 15 minutes.
API templates that keep the configuration visible
A blank route form makes it harder to see how authentication, public inputs, private values, response mapping, and proxy policies fit together. ApiClay recipes provide examples of those relationships inside the same Publisher Studio used for manual configuration. They prefill a starting state instead of hiding the underlying settings.
Choose a recipe based on the shape of your source, not just its name. A REST-key wrapper can fit many services; a failover pair needs compatible outputs from two providers. Every recipe requires your own valid inputs and live testing. Third-party accounts, source permissions, and external provider costs remain your responsibility.
Wrap existing API services
REST header-key, query-key, news, and pagination recipes show how to accept clean buyer inputs while injecting upstream credentials privately.
How it works
The RapidAPI and Apify examples demonstrate provider-specific request shapes. They are integration starting points; check your provider agreement before offering access or data to other buyers.
Productize a model or database
The OpenAI-compatible completion pattern keeps a provider key and model choice private while exposing a simpler response.
How it works
The database-table recipe starts with table selection and row limits for MySQL or PostgreSQL. In both cases, inspect the actual schema and avoid exposing fields your buyers do not need.
Reuse live-web execution patterns
JavaScript-to-Markdown, hidden XHR, and gated-portal recipes demonstrate three different web sources.
How it works
Some pages only need rendering; others are better represented by a background JSON request or an authorized session. Test which pattern matches the target before expanding it to more routes.
Build a predictable backup contract
The failover-pair recipe connects a primary source and a backup with normalized output fields.
How it works
The backup helps only if it can answer the same buyer question. Validate both sources independently, including their authentication, proxy settings, rate limits, and response mapping, before relying on the pair.
Where this fits into your work.
First-time API publishers
Use a small REST or table-backed example to learn the studio's contract, secret handling, and live testing before adding more complex routes.
Existing data-service owners
Bring an approved upstream service into a documented marketplace listing while keeping the provider's authentication outside buyer-visible inputs.
Repeatable agency delivery
Use recipes to standardize the first configuration pass, then adapt the source, policies, and schema to each client's actual requirements.
Start with a focused test.
Use these steps to set up Starter Recipes and review the result before making it part of a larger workflow.
Choose a starter recipe →- 1
Pick a suitable pattern
Review the gallery below, then open the matching Add API or Add Aggregator studio. Choose that recipe in the studio's recipe picker.
- 2
Replace the placeholders
Supply the required source URL, credentials, database details, model, or proxy settings. Review public and private fields and replace all marked placeholder values.
- 3
Test and customize
Run the route against your source, inspect the response mapping, choose limits and pricing, and keep the listing private until it behaves as intended.
Understand each workflow’s cost.
Match the feature’s limits and billing model to the work you want to run.
Explore API listings →A recipe supplies configuration, not paid credits or a third-party subscription. Its upstream calls, model usage, proxy traffic, and browser execution can each have costs that depend on your chosen providers and route settings.
Use live tests to estimate the complete successful-call cost. Configure route pricing and trial allowances only after replacing sample values and checking source behavior. The recipe does not submit or publish a listing automatically.
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 recipes create a live API automatically?
No. A recipe prefills editable wizard fields. You must supply valid source details, replace placeholders, test the route, and complete the normal save and publication workflow.
Where do I choose a recipe?
Open Add API for a direct datasource or Custom HTTP recipe, or Add Aggregator for a multi-source or wrapper recipe. Select the named recipe from that studio's picker.
Are real API keys included?
No. Credential fields contain placeholders. Provide your own authorized credentials, keep them private, and account for the upstream provider's usage charges.
Can I modify a recipe after loading it?
Yes. Recipes use the same editable configuration as manually created routes. Change inputs, secrets, mappings, limits, and pricing to match your actual product, then test the result.
Skip the blank canvas.
Choose a recipe, customize it, and test your first API.