Snipget.ai

Parse and normalize a money value

Exact
money_currency_normalize

Deterministic and authoritative — the canonical answer for this input.

Normalize a currency reference (ISO 4217 code, name, or symbol) to its ISO 4217 code. Ambiguous symbols like '$' return the full candidate list; a country_hint (ISO 3166-1 alpha-2) disambiguates. USD is preferred on ambiguous '$' without a hint. Processing multiple inputs? Use `money_currency_normalize_batch` to do up to 1000 in one call.

Parameters

valuestringrequired

Currency code, name, or symbol to normalize.

country_hintstringoptional

ISO 3166-1 alpha-2 country code to disambiguate shared symbols.

Call it

curl -X POST https://api.snipget.ai/v1/money/currency/normalize \
  -H "Authorization: Bearer sk_live_..." \
  -H "Content-Type: application/json" \
  -d '{"value":"yen"}'

The Batch tab sends up to 1000 inputs in one call via /v1/money/currency/normalize/batch.

Example response

{
  "input": "yen",
  "normalized": "JPY",
  "top_match": {
    "code": "JPY",
    "name": "Japanese Yen",
    "symbol": "¥",
    "minor_units": 0,
    "countries": [
      "JP"
    ],
    "kind": "fiat"
  },
  "candidates": [
    {
      "code": "JPY",
      "name": "Japanese Yen",
      "symbol": "¥",
      "minor_units": 0,
      "countries": [
        "JP"
      ],
      "kind": "fiat"
    }
  ],
  "is_ambiguous": false,
  "matched_via": "name",
  "is_valid": true
}

FAQ

What does this do?

It takes any loose way of naming money, a code, a full name, a nickname, or a symbol, and returns the official ISO 4217 code. So 'yen' and ¥ both become JPY, and 'dollar' becomes USD.

Why not just keep whatever the user typed?

Codes are what every payment system, spreadsheet, and report expects. Normalizing free-text money references up front means everything downstream lines up, and it accepts casual aliases like 'quid', 'loonie', or 'greenback' that a strict lookup would miss.

How does it handle a shared symbol like $?

It returns every currency that uses the symbol as candidates and picks the most likely default (USD for $) unless you pass a country_hint. If you want it to refuse to guess and flag the ambiguity instead, use the stricter symbol-resolve tool.

Is the answer authoritative?

Yes for a clean match. It is a deterministic lookup against the ISO 4217 catalog, and confidence is high. When the input is an ambiguous symbol it lowers the confidence and marks is_ambiguous true, so check that flag.

What if it cannot figure out the currency?

Unrecognized input returns confidence 0 with a reason, not an error. value is required; country_hint is optional and only matters for symbols that several countries share.

Related tools