Plan paid data actions with balance and freshness context

What the balance widget tells you

The balance widget shows the available EUR credit for the active organization and its visible usage context. Check the organization first. A balance belongs to the billing account, not to a keyword row, list, or metric, and switching workspaces or organizations can change which credit funds the action.

The widget is an operating control. It is not an invoice and does not replace the Billing area or provider-issued payment documents. Use it to decide whether the intended data operation fits the available credit before opening a large confirmation.

Actions that organize existing data

These actions normally work with records and fields already available in the workspace. They can still change team-visible state, so permissions and scope matter, but they do not by themselves ask a data provider for a new dataset.

• Search and filter keyword rows.
• Change visible columns, sort order, and presets.
• Create or update supported lists and tags.
• Move records through product status fields that are currently available.
• Read existing details, snapshots, or history.
• Export data already present in the selected scope.

Actions that can use organization balance

A paid action requests or processes external evidence. The exact quote depends on the operation and the confirmation shown at that time. Keyword count alone is not a complete price model because packages, routes, market, frequency, and reusable data can differ.

• Keyword-data enrichment such as Essentials or selected deeper packages.
• Fresh volume, intent, historical, or other supported keyword datasets.
• Requested SERP snapshots or deeper SERP evidence.
• Supported domain, competitor, backlink, or research operations.
• Configured recurring position tracking and its selected data work.
• Larger provider-backed batches that explicitly display a paid confirmation.

Estimate, reservation, and settlement are different stages

The estimate lets you review the selected action before execution. When the operation starts, Crawl Foundry uses the billing flow for the active organization to secure the required balance for the job. This prevents a paid request from being treated as funded merely because the interface accepted a click.

After the recorded outcome, the billing flow settles the applicable cost and releases balance that should not remain reserved. If settlement cannot finish immediately, the operation and its cost state still need a durable record rather than disappearing from the user's history.

Scope a paid action before confirming

For a new research request, review research setup and cost separately from refreshing existing database rows.

Refresh when stale data could change the decision

Freshness is contextual. A client-facing market comparison, tracking baseline, current SERP review, competitor investigation, or expensive campaign decision may justify a new request. Early brainstorming, taxonomy cleanup, and an initial relevance review may not.

Use the source date and the decision's risk, not a universal age threshold. A recently collected value can still be unsuitable when it came from another market or source definition. Older data can still be sufficient to exclude an obviously irrelevant term.

If balance is insufficient

• Do not interpret the submitted request as a completed data refresh.
• Reduce the selected scope or remove packages that the decision does not require.
• Confirm that the correct organization and billing account are active.
• Add credit through the supported Billing flow when the operation is still justified.
• Retry only after the previous attempt's Activity and reservation state are clear.

Handle partial and failed runs from their evidence

A batch can finish with fewer updated rows than requested. Check Activity for requested, completed, failed, skipped, or unavailable counts and any visible error reason. Then inspect whether the failure belongs to input, market support, provider response, balance, timeout, or another recorded state.

Retry the affected subset rather than the full list when the product makes that scope available. Repeating successful rows can spend balance without improving the decision and can obscure the original failure pattern.

If the outcome is partial or failed, follow the Activity investigation steps before buying the same data again.

Use the right record for the right question

Example: Refreshing only what changes the decision

Frequently asked questions