The Storefront API lets you retrieve and update your pricing configuration programmatically — TLD pricing, add-on pricing, currencies, default markup, price rounding, and tax rules — without logging into Storefront Manager. This is useful for feeding pricing data into your own billing or reporting systems, or managing pricing from your own tooling instead of the UI.
Shopco nameservers required for DNS managementDNS template and DNS record management only work for domains using Storefront's default Shopco nameservers (
a.ns.shopco.com,b.ns.shopco.com,c.ns.shopco.com). Domains using custom nameservers manage their own DNS outside of Storefront.
TLD catalogue
Returns your TLDs with their current pricing configuration.
Based on the spec's example response, entries look like:
| Field | Description |
|---|---|
name | The TLD, e.g. com |
true_tld | A separate underlying TLD identifier — not confirmed how or when this differs from name |
status | Pricing status, e.g. custom_pricing — the spec only shows this one example value, full set unconfirmed |
markup | Current markup percentage |
retail_price | Customer-facing price |
osrs_price | OpenSRS's underlying cost |
currency_code / currency_symbol | The currency this row is priced in |
TLD pricing
Get pricing for a single TLD (GET /v1/tld/{tld}/pricing) returns the pricing strategy for four operations — registration, transfer, renew, redemption — plus OpenSRS's underlying cost for each.
Each operation's strategy is one of:
default— use your storefront's default markupcustom_markup— a specific markup percentage for this TLD and operationcustom_final_price— a fixed price you set directly, as a USD price plus a list of prices in your other configured currenciessame_as_registration— for transfer, renew, and redemption only, mirror whatever registration is set to
There's no "time period" or term-length concept in the pricing model — the PRD's acceptance criteria mention pricing "by time period selected," but the spec prices per operation type and per currency, not per registration term. Flagging since that's a real gap between the two, not an oversight in this summary.
Set pricing (POST /v1/tlds/set_pricing) applies one pricing configuration — the same registration/transfer/renew/redemption strategy — across a list of TLDs in a single request. It doesn't accept different prices per TLD in one call; to set different pricing on different TLDs, send separate requests. An optional flag on the same request can also enable the given TLDs at the same time.
Enabling and disabling TLDs
POST /v1/tlds/set_enabled_status enables or disables a list of TLDs in one request. GET /v1/tld/{tld}/status returns a single TLD's current state as {"enabled": true|false}.
Add-on pricing
As of this spec, "add-on pricing" covers exactly one add-on: contact (WHOIS) privacy — a customer-facing price plus OpenSRS's underlying cost. The PRD's framing ("all add-on products active in their Storefront") implies more than one add-on exists or is planned.
Currencies
Currencies are modeled as exchange rates against USD (value_of_1_usd — units of that currency per US dollar), plus which one is your default and how many active customers are currently billed in it.
There's no separate create call — PUT /v1/currency/{code} creates or updates a currency in one operation. DELETE /v1/currency/{code} removes one.
See Selling in multiple currencies for the equivalent UI-based setup.
Default markup
A single percentage (0–999) applied storefront-wide as the default for any TLD/operation not set to custom_markup or custom_final_price. There's no separate "type" — it's always a percentage, unlike what the PRD's "markup type and value" language might suggest.
See Setting up your domain pricing for how markup and per-TLD pricing interact in the UI.
Price rounding
One setting for the whole storefront: rounding_off, rounding_to_dollar, or rounding_to_99. This is simpler than it might sound from the PRD — it's a single enum, not a per-TLD or per-currency rule set.
Tax rules
Each tax rule has a display name, a rate (as a fraction, e.g. 0.13 for 13%), a 2-letter country code, an optional state/province (null means the rule applies country-wide), and an optional tax registration ID. Full create, read, update, and delete by ID (a UUID assigned on creation).
There's also a usage lookup (GET /v1/tax_rule/tax_ids) that groups your tax rules by their shared tax_id value and reports how many rules use each one — useful for checking whether a tax registration ID is already attached to other rules before you change or remove it. This endpoint isn't mentioned in the PRD.
The PRD's "jurisdiction" and "type" language maps to country + state/province here — there's no separate type field (e.g. VAT vs. sales tax) in the spec.
See Collecting taxes for the equivalent UI-based setup.
Errors and conventions
Money values are decimals (e.g. 2.33 for $2.33), not integer cents. Beyond what's documented per endpoint, the API can return 403 (authenticated but not authorized for this resource), 404 (not found), 409 (already exists, on POST), 429 (rate limit exceeded), and 500 (contact support, quoting the x-error-id response header).