Retrieve fx settings
How this store ROUNDS a price it converted out of its own currency. A SINGLETON: one rule per store, so there is no page block and no id in the path. exact leaves the converted number alone, nearest_whole rounds to a whole major unit, and nearest_99 and nearest_95 round to a whole major unit and then sit just below it. On a ZERO-DECIMAL currency such as JPY there is no fraction to sit below, so both charm rules behave as nearest_whole; read this together with the currency’s decimal_digits under read_currencies. A store that has never set a rule has no row, and this answers with the default (exact) and a NULL updated_at rather than a 404. Send that null back as expected_updated_at on your first write; it is how a first write names a version that does not exist yet. NO EXCHANGE RATE IS PUBLISHED HERE AND THERE IS NO CONVERSION ENDPOINT. Rates are platform-wide reference data refreshed from a third party for every store at once, not merchant data, so they are not served under a merchant’s key and a convert call would disclose them a digit at a time. This resource is the merchant’s presentation policy, and nothing else.
Authorizations
A secret API key. Publishable keys cannot reach this API. A key may carry an expiry, and an expired key is refused exactly like an unknown one, with a 401 that names no reason; check the key's expires_at in the dashboard rather than inferring it from a response. When a merchant rolls a key's secret they choose a grace window of up to 3 days, and for its duration BOTH the new secret and the one it replaced authenticate, so an integration moves over on its own deploy schedule instead of at the instant the button is pressed. Move before the window closes: after it, the old secret is refused. Nothing else about this contract moves with a roll. The key keeps its id and its scopes, so the only thing an integration updates is the credential itself.
Response
Success