BLAZINGFAST — CATALOG DISCOVERY
Reviewed: 6 October 2026. SDK/CLI 0.1.17; contract 2026-10-06.5.
Production release: SDK/CLI 0.1.17; contract 2026-10-07.1. Check GET /v1/version and GET /v1/capabilities before using optional workflow features. Strict response validation is enforced.
Read-only authenticated customer discovery. Check /v1/version
and /v1/capabilities for deployed support; provider readiness and stock are separate.

HTTP CONTRACT
GET /v1/regions
GET /v1/products
GET /v1/products/{region}
GET /v1/products/{region}/list
GET /v1/products/{region}/list/{productCode}
GET /v1/products/{region}/{productCode}/{variantCode}
GET /v1/products/{region}/{productCode}/{variantCode}/prices
GET /v1/products/{region}/{productCode}/{variantCode}/options
GET /v1/vps/images
GET /v1/dedicated/images
GET /v1/ssh-keys

Discover regions, product codes, variants, compatible OS images and owned SSH keys
before building a deployment. Never invent IDs, SKU codes, regions or OS choices.
The same regional contract serves NL and PT; availability can differ. An empty or
partial catalog is not proof of zero provider stock. Catalog reads do not reserve
capacity or charge an account. Dedicated images require the discovered region and
configuration_code; preserve those selections when choosing an OS profile.

CLI
bf version
bf capabilities
bf regions
bf catalog list nl vps
bf catalog get nl vps DISCOVERED_VARIANT
bf catalog prices nl vps DISCOVERED_VARIANT
bf catalog options nl vps DISCOVERED_VARIANT
bf products --region nl --type vps
bf vps images --region nl
bf dedicated images --region pt --configuration DISCOVERED_CONFIGURATION

Python/Node/PHP: product_codes, product_get, product_prices, product_options.
Go: ProductCodes, ProductGet, ProductPrices, ProductOptions.
Hosted MCP: list_product_codes, list_family_product_codes, get_product_by_code,
get_product_prices_by_code, get_product_options_by_code.
Local MCP: bf_regions, bf_products, bf_product_codes, bf_product_get,
bf_product_prices, bf_product_options. Viewing tools are enabled by default.

AUTHENTICATION AND PAGINATION
Use billing.products.read for products/VPS images, dedicated.read for dedicated
images, and ssh.read for owned key metadata. Configure BF_API_BASE_URL without
/v1 and use signed credentials or a complete bearer token for that environment.
Keep TLS verification enabled. Never log secrets or put credentials in URLs.
Catalog lists use limit/offset and next_offset; follow pages before concluding
that a variant is absent. Prices are base-plan amounts; quote the complete
configuration to include add-ons, setup fees and tax. A quote reserves nothing.
Use max_total for a deployment ceiling and preserve its Idempotency-Key for retries.

SERVICES AND NEXT STEPS
GET /v1/services is the canonical owned-service list; /v1/my/services is a
compatibility alias. Active+suspended is the default. These are owned instances,
not products for sale. Use status/type/search filters before pagination.
A returned task/order means accepted, not completed. Poll operation status;
inspect unknown outcomes before retrying. See 14-integration-workflows.txt and
/docs/api-endpoints.html for canonical deployment, write keys and webhooks.

TYPE AND PRODUCT_CODE
type is the high-level normalized service family; product_code is the more
specific purchasable family. tcp-proxy -> other, waf -> dns, license -> other.
Use the returned product_code for purchases; do not put it into a type filter.
Read-only discovery stays in Catalog; quote and atomic deploy are Deployments.

Workflow metadata: discover purchase.draft_order / purchase.atomic_deploy, then
follow requirements_url/options_url for canonical deployment inputs and sources.
Quotes are optional and not price-locked. Approve quote.recommended_max_total and
send max_total; deployment_price_limit_exceeded refuses a higher final total.
Follow returned links.operation/service/invoice/order when present. Canonical
write receipts are opt-in with x-bf-response-format: operation and capability
support; default v1 fields remain compatible. After losing a tracked write
response, GET /v1/operations?idempotency_key=ORIGINAL_KEY without repeating it.
Missing or expired receipts never authorize a replacement key. Poll status/done,
then read the successful result's resource IDs. MCP approval is separate from
execution. DNSSEC retains its own polling contract. See the integration guide.