IPRout

Use case

Login Activity with IP Geolocation

Your application already knows the login IP. IPRout turns it into approximate location, timezone, ASN, and network context for a useful account activity history.

Account activity

Recent logins

Illustrative data
  • Sydney, Australia

    Example Network · 203.0.113.24

    30 Sep 2026, 09:42 UTC

    Sample session

  • London, United Kingdom

    Example ISP · 198.51.100.18

    29 Sep 2026, 18:15 UTC

    Sample login

From IP to context

How to add IP geolocation to login activity

After a successful login, your backend captures the client IP, looks up that explicit address, and stores only the response fields needed by your activity page. A server-side request to GET /ip would look up your backend's caller IP instead of the person signing in.

  1. 01

    Login

    Record the authentication event and time.

  2. 02

    Client IP

    Resolve the address through trusted proxy settings.

  3. 03

    IPRout

    Call GET /ip/{ip} with a server-side API key.

  4. 04

    Activity

    Save selected context for the account history.

Available context

What the API adds

IPRout returns location and network fields in one JSON response. Geographic values can be unavailable or approximate, so keep your UI tolerant of missing data.

Country, region, city
A readable, approximate location for the login record.
Timezone
Local context for displaying or comparing timestamps.
ASN
The autonomous system associated with the IP address.
Organization
The network operator returned by the API, not the person logging in.

A login history users can understand

Show time, approximate place, address, and network together. A location label helps someone recognize a session, but it should not be presented as their precise physical position.

Account activity

Recent logins

Illustrative data
  • Sydney, Australia

    Example Network · 203.0.113.24

    30 Sep 2026, 09:42 UTC

    Sample session

  • London, United Kingdom

    Example ISP · 198.51.100.18

    29 Sep 2026, 18:15 UTC

    Sample login

  • Tokyo, Japan

    Example Hosting · 192.0.2.15

    26 Sep 2026, 11:08 UTC

    Sample login

API example

One explicit IP lookup

Call the API from your server with Authorization: Bearer. The documented 8.8.8.8 address below demonstrates the endpoint; use the actual login IP in your application and keep your key out of browser code.

Request
curl -H "Authorization: Bearer $IPROUT_API_KEY" \
  https://api.iprout.com/ip/8.8.8.8
Response excerpt
{
  "ip": "8.8.8.8",
  "country": "United States",
  "region": "California",
  "city": "Mountain View",
  "timezone": "America/Los_Angeles",
  "asn": 15169,
  "organization": "Google LLC"
}

The response shown is an excerpt. See all response fields and authentication guidance.

Laravel implementation

Capture a successful login event

This example listens for Laravel's login event, requests context for the captured IP, and writes a record even if enrichment fails. Configure services.iprout.key from a server-side environment variable and create the activity table with the columns below.

AppServiceProvider.php
<?php

namespace App\Providers;

use Illuminate\Auth\Events\Login;
use Illuminate\Support\Facades\DB;
use Illuminate\Support\Facades\Event;
use Illuminate\Support\Facades\Http;
use Illuminate\Support\ServiceProvider;

class AppServiceProvider extends ServiceProvider
{
    public function boot(): void
    {
        Event::listen(Login::class, function (Login $event): void {
            $ip = request()->ip(); // Trust only your own proxies.
            if ($ip === null) return;
            $context = [];

            try {
                $context = Http::withToken(config('services.iprout.key'))
                    ->timeout(2)
                    ->get('https://api.iprout.com/ip/' . rawurlencode($ip))
                    ->throw()
                    ->json();
            } catch (\Throwable $error) {
                report($error); // Never log your API key.
            }

            DB::table('login_activities')->insert([
                'user_id' => $event->user->getAuthIdentifier(),
                'ip_address' => $ip,
                'country' => $context['country'] ?? null,
                'city' => $context['city'] ?? null,
                'timezone' => $context['timezone'] ?? null,
                'asn' => $context['asn'] ?? null,
                'organization' => $context['organization'] ?? null,
                'logged_in_at' => now(),
            ]);
        });
    }
}

A synchronous lookup can add up to the configured timeout to login. For production, consider dispatching a queued job with the captured user ID, IP, and timestamp, so API latency does not hold up authentication. Handle invalid addresses and API errors without preventing login.

Suggested stored fields

user_id, ip_address, logged_in_at, and nullable country, city, timezone, asn, and organization. Add device/session fields only if your app already collects them.

IP addresses and login activity may be personal information depending on context and jurisdiction. Keep only what you need, restrict access, and set an appropriate retention period.

Try IPRout

What you can build

Recent login history

Let people review when and roughly where their account was accessed.

New-login notices

Add approximate location and network context to a notification, alongside a time and device signal.

Support and admin views

Give authorized staff enough context to investigate a reported session without presenting GeoIP as proof.

Authentication audit logs

Store selected IP intelligence next to the event so historical records retain their original context.

A useful new-login notice

“Your account was accessed at 09:42 from an approximate location near Sydney, Australia, on Example Network. If this was not you, review your sessions and secure your account.” The location and network here are illustrative, not a verified user or threat signal.

Travel, VPNs, corporate networks, and mobile routing can make a familiar login appear elsewhere. Combine IP context with device, session, MFA, and account-history signals before deciding whether to ask for extra verification.

Focus on your authentication experience

With a GeoIP API, your team does not need to download and refresh location datasets or operate separate IPv4, IPv6, and ASN lookup infrastructure. IPRout works through ordinary HTTP requests from Laravel, PHP, Node.js, Python, and other backend environments.

Login activity FAQ

What is login activity?
Login activity is a history of authentication events. It can include login time, IP address, device information, and approximate location.
How does IPRout determine login location?
Your server sends the login IP to GET /ip/{ip}. IPRout returns available geographic and network information for that address.
Is IP geolocation exact?
No. It is approximate network location, not GPS position. VPNs, mobile gateways, corporate networks, and ISP routing can affect the result.
Can I use IP geolocation for account security?
Yes, as context alongside sessions, device information, MFA, account history, and other risk signals. A location change alone is not proof of compromise.
Does IPRout support IPv6?
Yes. The explicit IP lookup endpoint supports IPv4 and IPv6 addresses.
Can I use IPRout with Laravel?
Yes. Laravel can call the IPRout REST API after a login event and store selected context with a login activity record. No dedicated SDK is required.
Do I need to maintain a GeoIP database?
No local GeoIP database is required when using the IPRout API.

Build login activity with IPRout

Add useful location and network context to your authentication logs.