Data Relationships

Most APIs give you isolated resources. You get a country, and if you want its currency details, you're on your own to figure out how. World Data API takes a different approach: resources reference each other using standard codes, and those codes work directly as endpoint parameters.

When you see a recognizable code in a response, you can usually fetch that resource directly.

Fetch Japan:

curl "https://worlddataapi.com/v1/countries/JP"

{
	"code": "JP",
	"name": "Japan",
	"currencies": ["JPY"],
	"languages": ["ja"],
	"timezones": ["Asia/Tokyo"],
	"continent": "Asia",
	// ...
}

Want the currency? Request /v1/currencies/JPY. The language? /v1/languages/ja. The timezone? /v1/timezones/Asia%2FTokyo. Codes you see in one response become parameters for the next request.

Where it makes sense, resources reference each other in both directions. A country lists its currencies, and a currency lists the countries that use it:

curl "https://worlddataapi.com/v1/currencies/EUR"

{
  "code": "EUR",
  "name": "Euro",
  "symbol": "€",
  "countries": ["AD", "AT", "BE", "CY", "DE", "EE", "ES", "FI", "FR", ...]
}

This is useful when your application's starting point varies. Sometimes you know the country and need the currency symbol. Sometimes you know the currency and need to list where it's used. The same data often supports both directions.

Note that not every data relationship is bidirectional — check the specific resource documentation to see what's available.

The natural question: should you fetch everything up front, or follow links as needed?

For most applications, fetch on demand. If you're displaying a country and the user clicks to see currency details, fetch the currency then. The API is fast, and this keeps your initial payloads small.

If you know you'll need related data immediately — say, you're showing a country with its currency symbol and language names on one screen — fetch them in parallel. A few small requests will often complete faster than one large bundled response would anyway.

There's no batch endpoint for fetching multiple resources at once. This is intentional: it keeps the API simple and predictable, and the individual endpoints are fast enough that parallelization handles most use cases well.