DEV Community: Joyce Foster

How to Use the OpenWeatherMap API — A Practical Guide.

Joyce Foster — Fri, 11 Sep 2026 13:12:20 +0000

Overview

The OpenWeatherMap API provides current weather data for any location in the world, including temperature, humidity, wind speed, and general conditions (e.g., clear skies, clouds, rain). Data is returned in JSON format and can be requested by city name or geographic coordinates. This guide covers how to authenticate, make a request, and handle both successful responses and errors.

Authentication

This API requires a free API key to make requests. Without a valid key, all requests will return an error.

How to get your API key:
1.) Sign up for a free account at https://home.openweathermap.org/users/sign_up

2.)Verify your email address via the confirmation link sent to your inbox.

3.)Log in and navigate to the API keys tab in your account.

4.)Copy your default key (or generate a new one).

Note: New API keys can take up to 2 hours to activate. If you receive an "Invalid API key" error immediately after signing up, this is expected — simply wait and try again.

Using your key:
Your API key must be included in every request as a query parameter called appid. For example:

https://api.openweathermap.org/data/2.5/weather?q=Lagos&appid=YOUR_API_KEY

Base URL & Endpoint

All requests to the current weather data endpoint use this base URL:
https://api.openweathermap.org/data/2.5/weather

You send a GET request to this URL, along with the parameters below, to retrieve current weather data for a location.

Parameters

Parameter	Required?	Type	Description
`q`	Required	string	City name (e.g., Lagos, London). Can also include country code (e.g., Lagos,NG) for more precise results.
`appid`	Required	string	Your unique API key, used to authenticate the request.
`units`	Optional	string	Sets the unit format for temperature. Options: standard (Kelvin, default if omitted), metric (Celsius), imperial (Fahrenheit).

Example Requests & Responses
1.) Basic request (default units — Kelvin)
Request:
https://api.openweathermap.org/data/2.5/weather?q=Lagos&appid=YOUR_API_KEY

Response:

{ "coord": {"lon": 3.75, "lat": 6.5833}, "weather": [{"main": "Clouds", "description": "overcast clouds"}], "main": { "temp": 302.18, "feels_like": 305.94, "humidity": 70 }, "wind": {"speed": 4.15}, "sys": {"country": "NG"}, "name": "Lagos", "cod": 200 }

Note: temperature is returned in Kelvin since no units parameter was set.

2.) Request with metric units
Request:
https://api.openweathermap.org/data/2.5/weather?q=Lagos&appid=YOUR_API_KEY&units=metric

Response (partial):

{ "main": { "temp": 29.03, "feels_like": 32.79, "humidity": 70 }, "name": "Lagos" }

Same location, now readable in Celsius.

3.) Request for a different city
Request:
https://api.openweathermap.org/data/2.5/weather?q=London&appid=YOUR_API_KEY&units=metric

Response (partial):

{ "weather": [{"main": "Clear", "description": "clear sky"}], "main": { "temp": 19.94, "feels_like": 19.3, "humidity": 50 }, "name": "London" }

Demonstrates the same endpoint working for any valid city name.

4.) Error response — invalid city name
Request:
https://api.openweathermap.org/data/2.5/weather?q=asdkjasnd&appid=YOUR_API_KEY
Response:

{ "cod": "404", "message": "city not found" }

Error Handling

Error	Cause	Solution
`401 Unauthorized` — "Invalid API key"	Your API key is incorrect, or was very recently generated and hasn't activated yet.	Double-check your key for typos. If it was just generated, wait up to 2 hours and try again.
`404 Not Found` — "city not found"	The city name in the `q` parameter is misspelled or doesn't exist.	Check the spelling, or add a country code for precision (e.g., q=Lagos,NG).
`429 Too Many Requests`	You've exceeded your plan's rate limit (calls per minute/day).	Wait before making more requests, or check your usage on your OpenWeatherMap dashboard.

Quick Start

1.) Sign up for a free account at https://home.openweathermap.org/users/sign_up and verify your email.

2.) Copy your API key from the API keys tab (allow up to 2 hours for it to activate).

3.) Build a request using the base URL, your key, and a city name:
https://api.openweathermap.org/data/2.5/weather?q=YOUR_CITY&appid=YOUR_API_KEY&units=metric

4.) Paste the URL into your browser or an API tool (e.g., Postman).

5.) You'll receive a JSON response with current weather data for that city.

Conclusion

This documentation covers everything needed to start making requests to the OpenWeatherMap current weather API — from generating an API key to handling common errors. All examples in this guide were tested directly against the live API to ensure accuracy.
For more advanced use cases, such as extended forecasts or historical weather data, refer to OpenWeatherMap's official documentation at https://openweathermap.org/api

AWS IAM for Beginners: Understanding Users, Groups, Roles, and Policies.

Joyce Foster — Mon, 07 Sep 2026 15:11:39 +0000

INTRODUCTION
Brief overview of AWS IAM.

IAM, which stands for ‘Identity and Access Management,’ is an essential feature of Amazon Web Services (AWS). It is the foundation upon which AWS infrastructure is built. With IAM, users and groups can be created, policies can be assigned through JSON, security can be enforced through multi-factor authentication(MFA), command-line interface(CLI) can be explored, and more.
As I dug deeper into IAM, I discovered that it provides the mechanism needed for authentication and authorization. When a user creates an AWS account, they usually start out using the root account. As time progressed, I learnt that I would need to create an IAM user for everyday tasks because it provides better security and accountability. These users can eventually be organized into groups, with one user belonging to multiple groups at once.
Generally, IAM provides an adequate structure to control access to your AWS resources and how it can be used. This structure manifests itself in the AWS community through key entities. Users represent individuals seeking access to AWS resources. Groups are typically made up of users and a user can belong to more than one group at a time. Roles are necessary to grant permission in the AWS environment, without the need to create a dedicated user.
By providing a systematic method for AWS components to communicate, IAM improves operational efficiency while strengthening security and simplifying cloud management.

Why IAM is important in cloud security.
The more I explored AWS, the clearer it became that IAM sits at the heart of cloud security rather than being just another feature to configure. Unlike traditional systems where physical access limits who can reach a server, cloud resources are reachable from anywhere with an internet connection. This means that without a strong access control system, anyone with the right credentials could potentially access critical resources, regardless of their location. IAM closes this gap by ensuring that every request to an AWS resource is first authenticated and then authorized, so that only the right people, or systems, get to perform the right actions. I came to see this as the difference between simply having a lock on the door and actually deciding who gets a key, when they can use it, and what rooms it opens.
What really drove the importance of IAM home for me was realizing how much damage a single misconfigured permission could cause. A developer with more access than they need, or an application with unrestricted permissions, becomes a much bigger risk the moment their credentials are compromised. IAM addresses this through the principle of least privilege, which I learned means giving users and services only the permissions they need to do their specific job, nothing more. By combining this with tools like MFA, granular policies, and temporary role-based access, IAM allows me to reduce the attack surface significantly while still keeping the environment flexible enough for daily operations. In this sense, I began to understand IAM not just as an access tool but as a core layer of defense that shapes how secure an entire AWS environment can be.

WHAT IS AWS IAM?
Definition and purpose
To me, IAM is a central system that oversees the basics of access in the cloud. It is the service provided by AWS to manage access to an account and the activities carried out therein. Fundamentally, IAM handles authentication, which confirms the identity of the user, and authorization, which allows for permissions granted afterward. When I first came across IAM, I realized it wasn't just a login system; it was more like a gatekeeper that decides both entry and movement within the AWS environment.
The purpose of IAM became clearer to me once I understood that AWS accounts are not meant to be operated solely through the root user. IAM exists so that access can be distributed safely, and it allows various persons and applications to interact with AWS resources without complete or permanent control over the account. Through IAM, I'm able to create individual identities, assign specific permissions, and revoke or adjust access at any time, all without compromising the security of the environment. This made me appreciate IAM not as an optional add-on, but as the foundation that every other AWS service depends on to stay secure.

Key benefits of IAM:
Centralized Access Control — Essentially, IAM lets me manage all user and system access from one place, instead of having to configure permissions separately across every AWS service I use.

Granular Permissions — Rather than giving broad access, IAM allows me to define exactly what each user, group, or role can do, right down to specific actions on specific resources.

Enhanced Security — With features like MFA, I'm able to reduce the risk of unauthorized access and limit the damage a compromised account could cause.

Scalability — As my AWS environment grows, IAM makes it easy for me to add new users, adjust group memberships, or update policies without having to rebuild my entire access structure from scratch.

Core Components Of IAM
IAM Users- An IAM user represents a single identity within an AWS account, which could be an actual person or an application that interacts with AWS resources. A user is granted unique credentials, consisting of a username and password for console access, or access keys for programmatic access through the CLI or SDKs. What stood out to me is that every user starts out with no permissions at all by default, so nothing is accessible until permissions are explicitly granted. Generally, the concept of IAM users taught me the importance of granting each person or application separate identities across a team. This way, I'm able to track exactly who did what within the account, and if one user's credentials are ever compromised, I can disable or delete that specific user without affecting anyone else. It also made me appreciate how IAM users form the base layer that groups and policies eventually build on top of.

IAM Groups- An IAM group is simply a collection of IAM users that share a common set of permissions. Instead of assigning policies to each user individually, I can attach a policy to a group, and every user in that group automatically inherits those permissions. This became especially useful to me when thinking about teams within an organization, for example, grouping all developers together so they share the same access to development resources, while a separate group for administrators holds broader permissions. To me, the most valuable detail about IAM groups is how much easier they make managing permissions. I also grasped that a user isn’t limited to one group and can belong to multiple groups at once, which gives me more flexibility in combining different sets of permissions depending on what a person's role actually requires. This taught me that groups aren't just a convenience, they're a key part of keeping permission management organized as an environment grows.

IAM Roles- IAM Roles has a different function from users and groups. They are synonymous with a temporary identity that can be assumed by whoever needs it at that moment, whether that's an IAM user, an application, or even another AWS service. It also gives users temporary security credentials that expire after a set period. This means I don't have to worry about long-term access keys sitting around and potentially getting exposed. I found roles particularly useful when an EC2 instance needs to talk to another AWS service, like S3, without hardcoding credentials into the application. I could easily attach a role to the instance and let it assume the permissions it needs, only for as long as it needs them. This taught me that roles aren't just an alternative to users, they're actually a safer way to handle access for anything temporary or cross-account.

IAM Policies- A policy, written in JSON, essentially spells out exactly what actions are allowed or denied on which resources. At first, the JSON format looked intimidating to me, but once I broke it down, I realized it's really just a structured way of saying "this identity can" or "this identity cannot" do a specific thing. What I appreciated most about policies is how much control they give me over granularity. I'm not stuck choosing between "full access" or "no access." I can be as specific as allowing someone to only read from one particular S3 bucket, without touching anything else in the account. Learning to write and attach policies made me realize that this is really where the principle of least privilege comes to life. It's one thing to talk about giving minimal permissions, but policies are the actual tool that makes it possible.

How IAM Controls Access
Authentication- This is AWS confirming I am who I say I am, whether through a console login or access keys via the CLI. It doesn't grant permissions on its own, it just verifies identity.

Authorization- Once I'm authenticated, IAM checks the permissions tied to my user, group, or role to decide what I'm actually allowed to do. This is where policies come in.

Example of access management in AWS- Say I create a new IAM user with no permissions attached. They can log in, but every action is denied until I grant access, like read access to an S3 bucket. Try anything outside that, like deleting an EC2 instance, and authorization blocks it.

IAM Best Practices
Principle of least privilege- This was a recurring phenomenon as I read through IAM documentation, and it's essentially the idea of giving users only the permissions they need, nothing more. I learned that it's easier to grant additional access later than to try and undo the damage from over-permissioned accounts.

Enable Multi-Factor Authentication (MFA)- Even strong passwords can be compromised, so I picked up that adding MFA gives an extra layer of protection, requiring a second form of verification before access is granted. It's a small step that significantly reduces the risk of unauthorized access.

Avoid using the root account- the root account has unrestricted access to everything, which makes it a major security risk if used for everyday tasks. I learned that it's best practice to lock it away, enable MFA on it specifically, and rely on IAM users and roles for daily operations instead.

Real-World Use Case
Simple example of assigning permissions to a user- To bring everything together, say I onboard a new team member who only needs to view files in a specific S3 bucket. I'd start by creating an IAM user for them, then attach a policy granting read-only access to that particular bucket. Instead of assigning this directly to the user, I'd add them to a group I've already set up for that permission level, say, "S3-ReadOnly", so if another team member needs the same access later, I just add them to the group instead of repeating the process. This small example reflects exactly what I learned throughout: start with no access, grant only what's needed, and use groups to keep things scalable.

CONCLUSION
Looking back, IAM turned out to be more than just a checkbox in AWS setup, it's the layer that decides who gets in, what they can touch, and how much damage a single mistake can cause. Getting comfortable with users, groups, roles, and policies changed how I think about security altogether, not as something to configure once and forget, but as an ongoing responsibility.

The Smallest Fix With The Biggest Impact [Skips VS Technology Edition]

Joyce Foster — Thu, 20 Aug 2026 09:11:15 +0000

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

Remember that one Regular Show episode where Skips tried to destroy the park's computer because it caught the Error 220 bug? He took one look at it, picked up a sledgehammer and said the line we’ve all felt as devs: “ There’s something evil in that computer. We gotta smash it”. In the cartoon, they literally smash the computer and this works to fix the bug. In real life? We don’t get sledgehammers. We get Github PRs.

Last week, I almost felt like Skips. I found a one-line bug in an open source repo that could’ve broken Instagram webhook security. No hammer, no explosion, just one misindented ‘if’ statement and a missing test. This is the story of how the smallest fix had the biggest impact.

-The Challenge
So what was my Error 220?
While contributing to the corsair open-source repo, I found a security breach in the Instagram webhook handler. Something about the verification flow felt off, so I started tracing it line by line. The code called timingSafeEqual but the result was indecisive. I took an extensive look at it and that's when I saw it- The if statement meant to guard the check was there, but timingSafeEqual was indented wrong. It was meant to return the result of timingSafeEqual to accept or reject the request, but it fell through instead. Although it was running, its return value wasn’t being used to control the flow.
This bug was tiny-one mis-indented line- but it had a great impact. In JS, it is not considered an error and so it’s easy to miss. Webhook security relies on a signature check to prove a request. If timingSafeEqual isn’t actually enforcing it, an attacker could forge a webhook and it would be accepted. The entire protection could fall apart over one tab.
View PR #759

-The Fix
In fixing it, I opened PR#759 to correct the indentation so crypto.timingSafeEqual would be inside the if block and its boolean result would decide whether to return true or false. Prior to the fix, the function was calling timingSafeEqual but then ignoring what it returned and continuing to execute anyway. The update makes it return instantly based on that result. If a signature doesn’t match, the request is rejected. In the same vein, it is accepted where it matches.

This change, small but significant, reconnects the verification to the return value. Consequently, the library actually enforces “only accepts requests signed by Instagram” instead of just running the check. This two-line difference restores the whole security guarantee and PR #759 has since been merged into the corsair repo, closing the gap for good.

-The Technical Breakdown
Here, Instagram signs every webhook with a secret key, and sends that signature in the request header. It is then the corsair's job to take the incoming payload, recreate the signature on our side, and compare it to the one Instagram sent. At this stage, crypto.timingSafeEqual comes in. It is a Node.js function made particularly for comparing secrets because it requires the same amount of time, whether they match or not. This prevents timing attacks.

In the process of generating the comparison, the bug broke the last step, and due to the indentation, the results never actually returned. So, the function would always continue, whether the signatures matched or not. After PR#759, I made the return value matter. If timingSafeEqual says false, it rejects. If it says true, it accepts. Now the check actually gates the request.

-The Lesson
What I am proud of: Recalling the Regular Show episode where the computer threw Error 220 and Skips immediately wanted to smash it. With this bug, it would’ve been just as easy to see the bad indentation, ignore it and let the webhook pass through anyway. I am proud that, like Skips, I decided to “smash” the bug by finding and fixing the indentation. This small choice positively restored the security.

What I learnt: I learnt that running a security check isn’t the same as enforcing it. My code was checking the signature but not using the result. Technology is only effective when you act on what it tells you. crypto.timingSafeEqual only mattered once I made its return value decide whether to accept or reject.

Challenges I came across: The challenge was that it failed silently. Just like Error 220 didn’t crash the computer in Regular Show, the bug didn’t show any errors. The request still went through whether the signature was valid or not. I had to slow down, read the flow and make one precise fix. This made me pay attention to the tiniest of details.

-Before and After Comparison
Before: The webhook validation ran timingSafeEqual but ignored the result, so all requests got through whether the signature matched or not.

After: PR#759 makes the return value gate the request, so only valid Instagram webhooks are processed.

Error 220 taught the Park crew that some problems just need to be smashed. PR #759 taught me that some problems just need to be seen. Not every fix has to be loud to matter. Sometimes the biggest impact comes from the smallest, most precise correction, one misindented line, caught and fixed, restoring an entire security guarantee. That's the smash bug story I'll remember.