Developer
Sandbox access
For local development, evaluation and small proofs of concept.
- Test API keys
- Core enrichment schemas
- Request inspector
- Community documentation
- Usage dashboard preview
Planned usage and access tiers
Clear Enrich API Pricing for Every Stage
Start with a developer sandbox, move to transparent usage-based billing and add enterprise controls when governance or volume requires them.
Developer sandboxUsage basedBudgetsEnterprise controls
Plan structure
Choose the operating model that matches your workflow
This static site intentionally avoids fabricated price points. Add approved rates, quotas and billing terms before taking live orders.
Growth
Usage based
For production applications and recurring enrichment workloads.
- Production API keys
- Batch enrichment jobs
- Signed webhooks
- Routing policies
- Budget and rate-limit controls
Enterprise
Custom agreement
For higher volume, policy requirements and dedicated support.
- Custom volume planning
- Provider and region policies
- Role-based administration
- Review and audit workflows
- Commercial support options
Cost drivers
Understand what changes the cost of an enrichment
A useful pricing model connects usage to the actual work performed and makes retry or provider costs visible.
| Driver | Why it matters | Control |
|---|---|---|
| Input size | Long documents and large records require more processing. | Trim irrelevant content, chunk documents and set size limits. |
| Enrichment count | Each requested field or operation can add work. | Request only fields connected to a downstream use. |
| Model route | Provider and model choices have different costs and capabilities. | Use task-specific routing policies and approved provider lists. |
| Retries | Timeouts and invalid outputs can multiply cost. | Cap attempts, preserve idempotency and retry only eligible errors. |
| Retrieval and tools | External lookups add latency and service cost. | Enable retrieval only for schemas that require evidence. |
| Batch operations | Large jobs need queue, storage and webhook delivery. | Use predictable batch sizes and completion retention policies. |
Budget controls
Keep AI enrichment spend connected to accepted results
Track cost by record type, schema and route. A low request price is not useful if the result fails validation or requires manual repair.
Request budgets
Set a maximum route cost or token budget for each enrichment request.
Account budgets
Define daily or monthly limits with warning thresholds and hard stops.
Accepted-result cost
Measure cost per schema-valid result, not only cost per attempted request.
Route transparency
Return provider, model route, attempts and billable units in usage metadata.
Usage alerts
Notify operators when a schema, customer or route changes its normal usage pattern.
Exportable usage
Provide CSV or API exports for finance, product and capacity planning.
Pricing FAQ
Plan access without publishing unapproved numbers
The pricing page explains the commercial structure while staying honest about the current static launch state.
How will Enrich API pricing work?
The launch model is designed around usage-based enrichment with clear request or task units. Final prices should be published before accepting production customers.
Is there a developer sandbox?
The site proposes a limited sandbox for testing request contracts and schemas. Connect that plan to real limits and billing before launch.
What affects the cost of an enrichment?
Record size, selected enrichments, provider route, model usage, retries, retrieval and batch processing can all affect cost.
Can I set a cost ceiling?
A production implementation should support account budgets and request-level routing limits so a job cannot exceed an approved cost policy.
Are prices on this page final?
No numeric prices are published in this static launch package. The page explains plan structure without inventing rates that have not been approved.
Request access to the developer preview
Use the static sign-in page as a front-end starting point, then connect it to your approved identity, account and billing systems.