Data providers and costs

What the marketplace shows

Marketplace presents public product profiles rather than an execution catalog. Each profile has a name, category, optional category tags, an authentication type, a short description, setup guidance, limits, and examples. This helps a workspace choose the right provider family without claiming that a live operation is enabled for every workspace.

The profile categories include Agent/MCP, Social, CRM, Enrichment, Source, SEO, AI Visibility, Webhook, Analytics, Billing, CMS, Communication, and Outbound. A provider can have extra tags when it belongs to more than one category. LinkedIn, for example, is shown as Social with Source and Outbound tags, so the catalog describes its product roles without turning it into a generic source query outside a workbook.

In the Marketplace screen, the search field filters provider name, description, category, tags, provider aliases, source keys, column types, and configured search terms. The category controls show the current number of matching profiles, and sorting is by name in ascending or descending order. An empty search result is a marketplace filter result, not evidence that a provider cannot exist in the live workspace catalog.

Marketplace cards label each entry as a workspace product profile. That label is deliberate: public documentation has no authority to reveal capability availability, schemas, authorization, or run behavior. Use the active catalog after sign-in for those facts, because readiness depends on the selected workspace and its configured providers.

Read the connection label

The authentication label describes the connection model a profile uses. Dreamstate One API is labeled as a workspace API key, while Dreamstate MCP is labeled as OAuth or a workspace API key. Webhooks are labeled as signed HTTPS delivery. Those labels describe the connected product surface, not a capability identifier that can be passed directly to an agent.

LinkedIn uses a connected LinkedIn account. X uses OAuth. Google Search Console and Google Analytics 4 use Google OAuth. HubSpot uses HubSpot OAuth, Slack uses Slack OAuth, and mailboxes use mailbox OAuth. Instantly is marked as provider credentials, while DataForSEO is marked as a Dreamstate-managed provider. The profile for AI Visibility is marked as Dreamstate-managed measurement.

Some profiles intentionally remain more general. Attio and Salesforce say they can be connected where enabled for the workspace. Enrichment Waterfall says it uses methods currently available to the workspace. Sources and Imports uses source-specific setup, Signal Sources can use provider OAuth, an API key, or a webhook, and GitHub, WordPress, and Framer each show their own connector or CMS credential type.

Read those labels as a setup conversation starter. They do not disclose raw credentials, automatically authorize a new provider, or guarantee a price. For connection problems, use the Settings handoff described on Integrations. For sending identity, domain policy, and suppressions, use Senders and mailboxes instead.

Find the marketplace profiles relevant to CRM synchronization and Google analytics. For each one, show its connection label, then search the live catalog for the exact capability and readiness needed in this workspace.

From a profile to a runnable contract

Architect does not run a marketplace card. It starts with the shared tool contract: search for the outcome, read the matching tool descriptor, and run only a contract delivered in the current turn. Tool search returns a tool_turn_token and can include fetched runnable contracts. A run that does not have its contract from that turn is refused with capability_not_fetched and a repair instruction.

Search is the correct place to learn whether a provider-specific operation exists and whether it belongs to a particular pack. Use pack_id in Architect and MCP, or toolset on the REST search endpoint and CLI, when the task belongs to one pack. The two names express the same scope boundary on different product surfaces.

The exact fetched descriptor contains the input schema, output schema, required scopes, action policy, cost policy, asynchronous policy, and pack id. A marketplace profile cannot replace any of those fields. For example, the public page may say a source needs source-specific setup, while the live descriptor tells the client the actual fields, valid modes, and workspace conditions for one specific provider operation.

All mutating calls must specify a mode. The server never defaults to live and returns mode_required when the caller omits it. Use smoke_test for static schema and policy inspection without a write or audit record, dry_run to validate against workspace state without business writes, provider spend, or outward action, and live only when the fetched contract permits the intended execution.

Cost and provider effects

The catalog uses three credit classes only: free, action, and dynamic. The class is not a marketplace category and does not by itself describe the external consequence. Read the action policy and cost policy of the exact capability before deciding whether a provider-backed run is read-only, internally reversible, sending, publishing, enrolling, activating, or test-running.

A live run that needs a price returns quote_required and an estimate. Re-run the same request with unchanged parameters and a max_credits ceiling to bind the quote. The ceiling limits that Dreamstate run. A person's yes, when the server requires one, is the paid-run consent rule, not the ceiling. The ceiling does not erase any separate commercial relationship with the provider shown in the marketplace profile.

Provider connection and credential actions are owner actions because they change who can reach an external service. They require a signed-in session, a fresh approval at the applicable owner, workspace-admin, or current-member tier, and an Idempotency-Key. This security rule is distinct from the normal paid-run quote flow. See Owner actions for that boundary.

A missing provider connection can block only the provider-backed run. It does not stop a user from building a workbook, preparing a sequence, drafting a workflow, or saving another workspace system. Keep the draft work separate, finish it in the pack that owns it, then complete the provider connection before the external step is needed.

When it goes wrong

If marketplace search produces no card, clear the category filter or change the public-profile search. If the provider still does not appear, treat that as an absent public profile. It is not a license to claim a hidden capability, and it does not establish whether the active workspace can run the provider.

If the live catalog rejects a guessed provider or connection request with invalid_request, search the current capability catalog and use the returned provider identifier. A provider can be absent from the workspace catalog even when a similar public marketplace profile exists.

If a run is rejected with capability_not_fetched, search and get the exact contract again in the same turn, then run that returned capability. If the request is mutating and returns mode_required, choose the mode supported by the contract rather than assuming live.

If a live request returns quote_required, do not change its parameters while trying to accept the price. Reuse the request shape with a suitable max_credits ceiling. If the blocker is a connection, complete the authenticated Settings flow and rediscover the descriptor before retrying the provider-backed action.

If the task is actually outbound sending, a CRM record update, a social post, or a worksheet row operation, inspect the owning pack after connection readiness is confirmed. Marketplace helps classify a provider, while the owning pack is responsible for the result and its lifecycle.