DEV Community: Xproapi

Building a Reliable REST API Client in Node.js Using Fetch

Xproapi — Sat, 07 Nov 2026 07:35:23 +0000

Calling an external REST API from Node.js is easy. Modern Node.js versions include the Fetch API, so you don't necessarily need an additional HTTP library.

But a production API client needs more than a simple fetch() call.

You need to think about request timeouts, authentication, rate limits, failed responses, and retry behavior.

Let's build a small reusable API client using native Node.js features.

1. Configure the API credentials

Use environment variables instead of putting API credentials directly in your source code.

API_BASE_URL=https://api.example.com
API_KEY=your_api_key

For local development, you can load these variables using the dotenv package.

npm install dotenv

Create config.js:

import 'dotenv/config';

export const config = {
    apiBaseUrl: process.env.API_BASE_URL,
    apiKey: process.env.API_KEY,
};

if (!config.apiBaseUrl || !config.apiKey) {
    throw new Error('Missing API configuration');
}

2. Create a reusable API client

Instead of writing a new Fetch request for every endpoint, create one reusable function.

import { config } from './config.js';

export async function apiRequest(path, options = {}) {
    const url = new URL(path, config.apiBaseUrl);

    const controller = new AbortController();

    const timeout = setTimeout(() => {
        controller.abort();
    }, 15000);

    try {
        const response = await fetch(url, {
            ...options,
            signal: controller.signal,
            headers: {
                Accept: 'application/json',
                Authorization: `Bearer ${config.apiKey}`,
                ...options.headers,
            },
        });

        const body = await response.text();

        let data;

        try {
            data = body ? JSON.parse(body) : null;
        } catch {
            throw new Error('API returned an invalid JSON response');
        }

        if (!response.ok) {
            const error = new Error(
                data?.message || `API request failed: ${response.status}`
            );

            error.status = response.status;
            error.data = data;

            throw error;
        }

        return data;

    } finally {
        clearTimeout(timeout);
    }
}

This implementation provides:

A configurable API base URL.
Centralized authentication.
A 15-second timeout.
JSON parsing.
HTTP error handling.

The Bearer authentication format is illustrative. Use the authentication scheme specified by your API provider.

3. Call an API endpoint

Now you can use the client from anywhere in your application.

import { apiRequest } from './api-client.js';

async function getUser(username) {
    return apiRequest('/users', {
        method: 'GET',
        headers: {
            // Add endpoint-specific headers if needed.
        },
    });
}

try {
    const user = await getUser('example');

    console.log(user);

} catch (error) {
    console.error('Unable to retrieve user:', error.message);
}

Replace /users and the parameters with the actual endpoint contract.

4. Handle rate limits

One of the most common mistakes in API integrations is treating HTTP 429 like an ordinary server error.

HTTP 429 means the client has exceeded a rate limit.

A well-behaved client should respect the Retry-After header when the server provides it.

function getRetryDelay(response) {
    const retryAfter = response.headers.get('Retry-After');

    if (!retryAfter) {
        return 1000;
    }

    const seconds = Number(retryAfter);

    if (Number.isFinite(seconds)) {
        return Math.max(0, seconds * 1000);
    }

    const retryDate = Date.parse(retryAfter);

    if (!Number.isNaN(retryDate)) {
        return Math.max(0, retryDate - Date.now());
    }

    return 1000;
}

Don't retry continuously when a service is telling you to slow down.

For production systems, add a maximum retry count and exponential backoff with jitter.

5. Add safe retry behavior

Retries are useful for temporary network errors and selected server failures.

However, there is an important distinction between retrying a GET request and retrying an operation that creates or modifies data.

A simple retry helper for safe GET requests:

const sleep = (ms) =>
    new Promise(resolve => setTimeout(resolve, ms));

export async function getWithRetry(path, maxAttempts = 3) {
    for (let attempt = 1; attempt <= maxAttempts; attempt++) {
        try {
            return await apiRequest(path, {
                method: 'GET',
            });

        } catch (error) {
            const retryable =
                !error.status ||
                error.status === 429 ||
                error.status >= 500;

            if (!retryable || attempt === maxAttempts) {
                throw error;
            }

            const delay = Math.min(
                1000 * (2 ** (attempt - 1)),
                10000
            );

            await sleep(delay);
        }
    }
}

This is a basic example. A production implementation should also honor Retry-After for HTTP 429 and add random jitter to reduce synchronized retries.

6. Keep API responses predictable

Avoid making every part of your application understand the details of an external provider's response format.

Instead, normalize the response inside your integration layer.

For example:

function normalizeUser(data) {
    return {
        id: String(data.id),
        username: data.username,
        name: data.name ?? null,
    };
}

Only map fields that the actual provider returns.

This approach makes it easier to change providers or update API versions later.

7. When should you use a dedicated HTTP library?

Native Fetch is sufficient for many integrations.

Consider a library such as Axios when your application needs:

Request and response interceptors.
More advanced request configuration.
Shared HTTP client instances.
Existing Axios-based infrastructure.

Don't add dependencies without a reason.

8. Try a real API integration

The architecture in this tutorial can be adapted to many REST APIs, including social media data services.

If you're building an application around X-related data, review the available endpoints and integration documentation at XProAPI.

Always check the provider's authentication method, supported parameters, credit usage, and rate limits before implementing your client.

Conclusion

A reusable API client is a small investment that pays off as an application grows.

Centralize authentication, handle timeouts, respect rate limits, and make retry behavior predictable.

These practices apply whether you're building a small Node.js script or a larger production SaaS application.

DEV tags: node, javascript, api, webdev, programming

How to Integrate a Third-Party REST API in Laravel (With Error Handling and Retries)

Xproapi — Sat, 07 Nov 2026 07:34:08 +0000

How to Integrate a Third-Party REST API in Laravel (With Error Handling and Retries)

Integrating an external API into a Laravel application is usually straightforward. You send an HTTP request, receive JSON, and process the response.

The real challenges appear later.

What happens when the API is temporarily unavailable? What if the server responds with HTTP 429? What if a request takes 30 seconds? And how do you prevent API credentials from ending up in your source code?

In this tutorial, we'll build a small, reusable API integration in Laravel with proper configuration, timeouts, error handling, and retry logic.

1. Store API credentials securely

Never hardcode API keys inside controllers or service classes.

Add the following to your .env file:

EXTERNAL_API_BASE_URL=https://api.example.com
EXTERNAL_API_KEY=your_api_key

Then add a configuration entry in config/services.php:

'external_api' => [
    'base_url' => env('EXTERNAL_API_BASE_URL'),
    'key' => env('EXTERNAL_API_KEY'),
],

This keeps environment-specific configuration outside your application logic.

2. Create a dedicated API service

I prefer keeping external API communication inside a service class instead of scattering HTTP requests throughout controllers.

Create:

php artisan make:class Services/ExternalApiService

Implementation:

<?php

namespace App\Services;

use Illuminate\Http\Client\PendingRequest;
use Illuminate\Support\Facades\Http;
use Illuminate\Http\Client\RequestException;

class ExternalApiService
{
    protected function client(): PendingRequest
    {
        return Http::baseUrl(
            config('services.external_api.base_url')
        )
            ->withToken(config('services.external_api.key'))
            ->acceptJson()
            ->timeout(15)
            ->connectTimeout(5);
    }

    public function getUser(string $username): array
    {
        $response = $this->client()->get('/users', [
            'username' => $username,
        ]);

        $response->throw();

        return $response->json();
    }
}

The endpoint and authentication scheme above are examples. Replace them with the actual API contract.

A dedicated service makes the integration easier to test, maintain, and reuse.

3. Handle API failures properly

External APIs can fail for several reasons:

Invalid credentials.
Invalid parameters.
Rate limiting.
Temporary upstream failures.
Network timeouts.
Unexpected response formats.

Don't assume every request will return HTTP 200.

For example:

try {
    $user = app(ExternalApiService::class)
        ->getUser('example');

} catch (\Illuminate\Http\Client\RequestException $e) {

    report($e);

    return response()->json([
        'message' => 'The external service returned an error.',
    ], 502);

} catch (\Illuminate\Http\Client\ConnectionException $e) {

    report($e);

    return response()->json([
        'message' => 'The external service is temporarily unavailable.',
    ], 503);
}

In a production application, you should also distinguish validation errors, authentication failures, and rate-limit responses instead of converting every upstream failure into the same response.

4. Implement retry logic carefully

A temporary network issue doesn't necessarily mean the operation has failed permanently.

Laravel provides retry support through its HTTP client.

For example:

$response = Http::retry(
    3,
    500,
    throw: false
)
    ->timeout(15)
    ->withToken(config('services.external_api.key'))
    ->get('https://api.example.com/users');

This retries failed requests up to three times, with a 500 ms delay.

However, retries should be used carefully.

For HTTP 429 responses, respect the API's Retry-After header when available. Avoid blindly retrying every request. Retrying non-idempotent operations can create duplicate actions.

5. Add logging without exposing secrets

When debugging an API integration, request logs are extremely useful.

You may want to record:

Endpoint name.
HTTP status.
Response time.
Request ID.
Error category.
Timestamp.

Never log API keys, authorization headers, passwords, or sensitive response data.

A simple logging example:

logger()->info('External API request completed', [
    'endpoint' => '/users',
    'status' => $response->status(),
]);

For larger applications, consider using Laravel queues for non-urgent API operations and monitoring failed jobs through Laravel Horizon.

6. Test the integration without calling the real API

Laravel's HTTP testing tools allow you to fake external responses.

use Illuminate\Support\Facades\Http;

Http::fake([
    'api.example.com/*' => Http::response([
        'id' => '123',
        'username' => 'example',
    ], 200),
]);

Now your application can be tested without depending on an external server.

Test at least these cases:

Successful API response.
Invalid API key.
HTTP 429 rate limit.
HTTP 500 response.
Connection timeout.
Invalid JSON response.

7. Where this approach is useful

The same architecture works for many external integrations:

Social media APIs.
Payment gateways.
CRM platforms.
Analytics services.
Data providers.
SaaS integrations.

If you're integrating X-related data into a Laravel application, you can explore API documentation and integration examples at XProAPI.

The important thing is to treat external API communication as a separate application boundary.

Final thoughts

A successful API integration is not just about making an HTTP request.

It's about handling failures, protecting credentials, managing rate limits, logging useful information, and making the integration maintainable.

Build the integration properly once, and you'll have a reusable foundation for every external service your Laravel application needs.

DEV tags: laravel, php, api, webdev, programming