You're building a trip planning app. The feature list seems straightforward: show users the local time at their destination, tell them if they need a power adapter, display emergency numbers, warn them about holidays that might affect their plans.

Then you start looking for data sources.

Timezone data? There's TimezoneDB, or you could use WorldTimeAPI, or maybe just hardcode UTC offsets (you'll regret this when DST changes and Morocco announces they're abolishing it mid-year). Country basics like capitals and currencies? REST Countries is the go-to, but it went through ownership changes and suddenly started returning different response formats. Power plug types and voltage? Good luck—REST Countries doesn't have it, so you're either scraping Wikipedia or maintaining your own spreadsheet. Emergency numbers? Same story. Holiday calendars? Now you need Calendarific or Abstract or Nager.Date, each with different coverage and pricing.

Before you've written any actual trip planning logic, you've integrated five APIs, each with its own authentication scheme, rate limits, response format, and failure modes. Your code is full of adapter patterns. Your error handling is a mess. And you're paying for four separate subscriptions to get data that, conceptually, is all just "stuff about countries."

This is the reality of building travel apps in 2025.

Every travel app developer pays this tax. It's not visible in your codebase as a line item, but it's there:

Integration overhead. Each API has its own SDK (or doesn't), its own auth pattern (API key in header, in query param, in bearer token), its own pagination scheme, its own error codes. You write the same "fetch and cache country data" logic five times with five different interfaces.

Reliability multiplication. If you depend on five services and each has 99.9% uptime, your effective uptime for "complete country data" is 99.5%. One service going down means your adapter checker stops working, or your emergency numbers page shows a spinner forever.

Maintenance burden. Morocco abolishes DST. Samoa skips a day to switch timezone sides. The UK adds a new bank holiday for the King's coronation. South Sudan becomes independent. Each of these changes might affect one of your five data sources at different times, with different update cadences, and you need to know about all of them.

Cost complexity. Calendarific charges per request. TimezoneDB has a different pricing tier. REST Countries is free but you get what you pay for. Your monthly bill is spread across four dashboards and you're never quite sure what you're paying for.

We built World Data API because we were tired of paying this tax ourselves.

Let's be specific about what travel apps require. Not "country data" in the abstract—actual features that users expect:

Your user is planning a trip to Tokyo from New York. They want to know: when I land at 3 PM local time, what time will it be back home? Can I call my family, or will they be asleep?

This requires:

• Current UTC offset for both locations

• Whether DST is active in each location

• The IANA timezone identifier (not just "JST"—you need "Asia/Tokyo" to handle future conversions correctly)

The edge cases will get you. Japan doesn't observe DST, but your user's home might. And if they're flying from Arizona, which doesn't observe DST but is surrounded by states that do? Your naive offset math breaks.

Your user is going from the US to the UK. Will their phone charger work? What about their laptop? Their hair dryer?

This requires:

• Plug types at origin and destination (the US uses A/B; the UK uses G)

• Voltage (US is 120V; UK is 230V)

• Frequency (both 50/60 Hz, but this matters for some appliances)

Most travel apps either skip this feature entirely or link to an external site. The data exists, but it's scattered across electrical engineering references, not neatly packaged in an API.

Your user is traveling to Japan. They're not planning to have an emergency, but if they do, they need to know: it's not 911. It's 110 for police, 119 for fire and ambulance. Getting this wrong in a crisis is not a UX inconvenience.

This requires:

• Emergency numbers by category (police, fire, ambulance, general emergency)

• Per-country accuracy (the EU is standardizing on 112, but national numbers still work and may be more appropriate)

Your user is planning a trip to Germany over Easter. Will the museums be open? Can they do their Christmas market trip, or will everything be shut down on the 25th and 26th?

This requires:

• Public holiday calendars by country

• Regional holidays (Bavaria has different holidays than Berlin)

• "Observed" dates when holidays fall on weekends

Your user is going to Thailand in August. Should they expect rain? How hot will it be?

This requires:

• Historical climate averages by month

• Temperature ranges, precipitation levels

This is explicitly not weather forecasting—that's a different product. Climate data tells you what to generally expect; weather tells you what's happening right now.

If you've built a travel app, you've probably used REST Countries. It's free, it's popular, it has decent coverage of country basics. For many use cases, it's fine.

But if you've used it in production, you've also probably experienced:

The ownership transition. REST Countries changed hands, and with it came API changes. Endpoints moved. Response formats shifted. Developers woke up to broken apps.

The coverage gaps. REST Countries doesn't have power plug data. It doesn't have emergency numbers. It doesn't have holiday calendars. For a "trip info" screen, you're back to stitching together multiple sources.

The maintenance question. Who updates it? How quickly? When South Sudan gained independence, how fast did that propagate? When countries change their calling codes or currencies, what's the lag?

We're not saying REST Countries is bad. For a free, community-maintained project, it's impressive. But "free and community-maintained" has tradeoffs when you're running a production app that users depend on.

We consolidated the reference data that travel apps need into a single API:

Timezone data. All 316 IANA timezones with current UTC offset, DST status, and standard/daylight abbreviations. Query by timezone ID or by country to get all timezones in that country.

Country fundamentals. The basics—capital, population, currencies, languages, calling codes, ISO codes. The stuff REST Countries has, maintained and updated.

Power and electrical. Plug types (using IEC 60083 designations: Type A, Type B, etc.), voltage, frequency. The data you need for adapter checker features.

Emergency numbers. Police, ambulance, and fire numbers by country. National-level data (we don't have regional variations within countries).

Holiday calendars. Public holidays for 230+ countries, with regional breakdown where it matters. Business day calculations so you can answer "what's the next working day after this date?"

Climate averages. Monthly temperature and precipitation data for major cities. Historical averages, not forecasts.

One API. One authentication scheme. One response format. One place to check when something seems wrong.

We're not trying to be everything. There's a clear boundary around what we do:

No real-time data. We don't have current weather, live flight status, or up-to-the-minute currency rates. We provide reference data—the stuff that changes slowly (timezones, country info) or on a known schedule (holidays).

No visa or immigration data. Entry requirements are complex, change frequently, and depend on both origin and destination. We don't have the expertise or update velocity to do this responsibly.

No booking or availability. We can tell you that Christmas is a holiday in Germany; we can't tell you if a specific museum is open on that day.

No translation. We provide language metadata (Germany's official language is German); we don't translate your app's UI into German.

City-level emergency numbers. Some countries have local emergency numbers in addition to national ones. We cover national; we don't have city-level granularity.

We think it's important to be explicit about these boundaries. If you need visa data, you need a visa API. If you need flight status, you need a flight API. We're the reference data layer underneath the real-time services.

A typical trip info screen might look like this:

Before World Data API:

• Fetch timezone from TimezoneDB

• Fetch country basics from REST Countries

• Look up power plug data from your internal spreadsheet (last updated... when?)

• Fetch holidays from Calendarific

• Manually maintain emergency numbers (and hope they're still accurate)

Five data sources. Five potential failure points. Five things to keep in sync.

After World Data API:

• Fetch trip info from World Data API

Two dead-simple requests gets you timezone, country basics, power data, emergency numbers, and holidays. Your code is simpler. Your failure modes are simpler. Your bill is simpler.

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

That gives you the country basics. For travel-specific data (power, emergency, climate), there's a dedicated endpoint:

curl "https://worlddataapi.com/v1/travel/JP" \
  -H "X-API-Key: YOUR_API_KEY"

Now you can move on to building actual trip planning features!

There's a free tier (60 requests/day) that covers country basics, timezones, and holidays—enough for development and light usage. The travel endpoint (power, emergency, climate) requires a paid tier.

Paid tiers: Starter at $9/month (15,000 requests), Pro at $49/month (100,000 requests), Growth at $149/month (500,000 requests). Annual billing saves roughly 25%.

Compare this to buying data separately:

• TimezoneDB: Free tier exists, paid tiers vary

• Calendarific: $100/year for reasonable volume

• Abstract Holidays: Separate pricing from their other APIs

• Power plug data: You're probably maintaining this yourself, which means engineering hours

We're not the cheapest option if you're only doing one thing. If you only need holidays, Nager.Date is free and might be sufficient. If you only need timezones, there are free options.

But if you're building a trip planning app that needs all of this data, consolidation is worth something. Fewer integrations. Fewer failure points. Fewer things to maintain. That's the value we're providing.

You're building a trip planning app, an itinerary manager, a travel packing assistant, a "travel info" feature inside a larger app, a digital nomad tool, or anything else where users are going somewhere and need to know things about that place.

You've already wired up three APIs and you're looking at adding a fourth. You're frustrated that the "simple" feature—showing emergency numbers—turned into a data maintenance project.

Or you're starting fresh and you want to avoid the fragmentation problem from the beginning.

Either way, we built this because we've been in that exact position.

The API uses REST patterns, returns JSON, and authenticates via the X-API-Key header. You can try reference endpoints (countries, timezones, holidays) without authentication—they'll work at a lower rate limit.

For the travel endpoint and other premium features, sign up at worlddataapi.com/dashboard to get an API key.

Full documentation is at worlddataapi.com/docs. We have guides for common travel app use cases:

• Building a Power Adapter Checker

• Adding Emergency Numbers to Your App

• Trip Planning with Climate Data

• Timezone-Aware Applications