Platform Partners

Connect to merchant-authorized business information built for conversational discovery.

CRSTBL gives approved applications access to structured business information through defined Cumae access policies and supported integration methods. Businesses authorize what is shared; CRSTBL records the source and the applicable access policy.

Who we partner with.

CRSTBL’s business knowledge network is designed to feed the AI systems and platforms where customers actually search, shop, and book.

LLM providersGround answers about real businesses in merchant-authorized data, not stale crawl.
AI assistants & chatbotsAnswer multi-criteria questions — dish-level, dietary, location, hours, availability.
Search platformsReturn current business detail instead of a link to a homepage.
Marketplace platformsEnrich listings with catalog and location detail sellers maintain themselves.
Delivery / Local ServicesKeep menus, service areas, and availability current at the source.
Loyalty ProgramsSurface participating merchants, eligible offers, and location-level benefits.
Travel & local sitesAnswer visitor questions about restaurants, retailers, attractions, and services.

Why the CRSTBL Business Knowledge Network is valuable.

Traditional web search, public directories, and general-purpose datasets frequently lack the depth, freshness, and context needed for accurate business discovery. CRSTBL fills that gap.

01

Merchant-authorized

Information originates from participating businesses through their approved content, uploads, and authorized data sources.

02

Richer than listings

Captures information that’s typically fragmented, outdated, or absent from conventional directories and search results.

03

Conversationally structured

Organized so AI systems can answer natural-language questions with multiple criteria, preferences, and use cases.

04

Semantically mapped

Connects products, services, attributes, industries, use cases, and customer needs across the whole network.

05

Location-specific

For chains, franchises, and distributors, CRSTBL distinguishes information by location, territory, catalog, or operating unit.

06

Updateable at source

Businesses update their approved Cumae records directly. Registered and allowlisted applications retrieve the current approved version according to the integration’s refresh terms. Open web and external AI systems refresh on their own schedules.

07

Governed & attributable

Data can include merchant attribution, source controls, permitted-use rules, and refresh policies where appropriate.

08

Freshness

CRSTA conversations can identify new questions, customer interests and possible information gaps. Businesses review and approve changes before information is added to or updated in Cumae.

Cumae access policies

What a platform can access is set by policy, not by connection.

Each participating business configures which policy applies to which information. Your integration operates within the policies those businesses have authorized.

PolicyRelevance to a platform partner
OpenLimited public identity record. No registration required.
RegisteredFull general Cumae record, for an identified application subject to CRSTBL terms.
AllowlistedPartner-specific view, approved individually by the participating business.
PrivateNot available to external platform partners.

Delivery method and access policy are separate decisions. MCP, APIs and feeds are delivery methods. Open, Registered, Allowlisted and Private are authorization policies. A technical connection does not determine what information an application is permitted to access — CRSTBL confirms both the delivery method and the authorized scope during pilot scoping.

Integration methods.

CRSTBL supports multiple delivery patterns. Each is labelled with its current status — we do not describe a method as generally supported because it is part of the planned architecture.

Planned

MCP access

Compatible LLMs and AI agents retrieve approved business knowledge through Model Context Protocol connections.

Planned

API access

Structured endpoints for products, menus, services, locations, attributes, availability, and related entities.

Planned

Structured data feeds

Scheduled or continuous data feeds for high-volume partners that ingest bulk business information.

Status key. Available means in production today. Pilot means running with named partners under pilot terms. Planned means specified and on the roadmap, not yet open for connection. Timelines are discussed during pilot scoping.

How partnerships start.

Every platform partnership is scoped to the specific integration. There’s no one-size-fits-all rate card.

Step 1

Define the use case

Identify your product, industry, geography, information needs, and user workflow.

Step 2

Define the knowledge scope

Determine which businesses, verticals, attributes, locations, or datasets are required.

Step 3

Select the access method

MCP, API, or structured data feed.

Step 4

Establish governance & commercial terms

Authentication, permitted use, attribution, refresh frequency, query limits, data rights, data exchange and reporting, privacy, and pricing.

Step 5

Launch a constrained pilot

Start with one vertical, market, merchant cohort, workflow, or limited query volume.

Step 6

Expand based on validation

Increase coverage, depth, refresh frequency, or platform integration after pilot validation.

Commercial Model

Access is scoped per partnership.

Data access and integration terms are developed based on use case, coverage, volume, deployment requirements, and data governance needs. There’s no published rate card during the initial launch. Commercial terms are shaped by number of businesses, locations, industry and geographic coverage, query volume, retrieval and refresh frequency, integration complexity, exclusivity, and service-level requirements.

Future pricing may include platform access fees, API usage pricing, MCP access fees, query-based pricing, data licensing, industry-specific subscriptions, geographic packages, or enterprise minimum commitments — determined per partnership.

Platform partner questions.

What platform teams ask before scoping an integration.

Which access method should we use — MCP, API, or a data feed?

MCP suits LLMs and AI agents that retrieve approved business knowledge on demand. API access suits platforms querying specific entities — products, menus, services, locations, attributes, and availability. Structured feeds suit high-volume partners ingesting business information in bulk. The right one depends on your platform, volume, and integration timeline, and it’s selected at step 3 of the partnership process.

Where does the data come from?

Participating businesses, through their approved content, uploads, and authorized data sources. CRSTBL records the business source and the applicable access policy. Merchant authorization means the business approved the information — it does not mean CRSTBL independently verified every product, price, claim or policy.

How current is the information?

Each Cumae record can carry version and update information. Businesses update their approved records through CRSTBL, and registered or allowlisted integrations retrieve according to agreed refresh terms. CRSTBL cannot guarantee how quickly a third-party platform updates information after it has been retrieved.

Does it handle chains, franchises, and multi-location businesses?

Yes. Information is distinguished by location, territory, catalog, or operating unit rather than collapsed into a single brand-level record, so location-specific detail stays intact for chains, franchises, and distributors.

Can we run a limited pilot before committing?

Yes — that’s the expected path. Pilots are deliberately constrained to one vertical, market, merchant cohort, workflow, or a capped query volume. Coverage, depth, refresh frequency, and integration scope expand after the pilot validates.

What gets agreed before a pilot starts?

Authentication, permitted use, attribution, refresh frequency, query limits, data rights, data exchange and reporting back to CRSTBL, privacy, and pricing. These are settled at step 4 of the partnership process, before any integration work begins.

On reporting: what CRSTBL is interested in is aggregated, de-identified demand data tied to a participating business’s own records — which information was retrieved, how often, and what categories of question it answered — so the business can see how it is being discovered. CRSTBL does not ask for raw end-user prompts, user identifiers or personal data. The scope and format of any reporting are agreed per partnership.

What does access cost?

There is no published rate card during the initial launch. Terms are built per partnership around the number of businesses and locations, industry and geographic coverage, query volume, retrieval and refresh frequency, integration complexity, exclusivity, and service-level requirements.

Is this the same as the CRSTBL referral or agency partner program?

No. Those are commission-based programs for partners who introduce businesses to CRSTBL, and they run on referral registration and attribution windows. Platform partnerships are data and integration agreements with entirely separate terms. For the referral track, see the Partner Program FAQ.

Discuss a platform partnership.

Whether you’re a new LLM, an established AI platform, or building the data infrastructure that connects businesses to AI — we want to talk.

Looking for the referral or agency programs instead? Those run on commissions and registered opportunities — see the Partner Program FAQ.