Next.js throws malformed URL error when importing Airtable library in getServerSideProps

Other Questions Airtable
1

I’m working on a Next.js project and trying to fetch data from Airtable inside getServerSideProps. However, I keep getting a URL malformed error even though I’m not making any relative URL requests.

pages/dataPage.js

import React from 'react';
import AirtableLib from 'airtable';

export const config = {
  runtime: 'experimental-edge',
};

export async function getServerSideProps({ params }) {
  AirtableLib.configure({
    endpointUrl: 'https://api.airtable.com',
    apiKey: process.env.AIRTABLE_KEY,
  });
  
  const database = AirtableLib.base(process.env.AIRTABLE_DATABASE);
  const records = database('myTable').select({});
  
  return { props: { data: [] } };
}

function DataPage({ data }) {
  return (
    <div>
      <h1>My Data</h1>
    </div>
  );
}

export default DataPage;

The error message I get is:

Error: URL is malformed "". Please use only absolute URLs

This happens as soon as I import the Airtable library. I don’t even need to call any functions. Just importing it causes the issue.

I tried setting the endpoint URL explicitly but that didn’t help. The error seems to be related to the experimental edge runtime I’m using.

Has anyone encountered this before? How can I properly use Airtable with Next.js in this setup?

2

Been wrestling with this too. The issue goes beyond just removing the edge runtime config. Even after switching back to Node.js runtime, you’ll still hit intermittent problems because Airtable’s SDK doesn’t handle environment detection well during SSR. What fixed it for me was wrapping the Airtable import in a dynamic import inside getServerSideProps instead of importing at the module level. This way the library only loads in Node.js context when it’s actually needed. Replace your top-level import with const AirtableLib = (await import('airtable')).default; inside your getServerSideProps function. This solved both the edge runtime compatibility and some weird SSR hydration issues I was seeing. Dynamic import adds maybe 10ms overhead but kills all the URL parsing errors.

3

Totally agree, edge runtime’s a pain with some libraries. Drop the experimental config and switch to Node.js runtime. Works perfectly with Airtable, no more headaches!

4

Yeah, the edge runtime is breaking your Airtable import. Hit this exact issue 8 months ago when optimizing some data fetching.

Airtable SDK needs Node.js APIs that don’t exist in edge runtime. When you import it, the library tries initializing with URL handling that expects full Node environment.

Here’s the fix. Drop the experimental edge config:

// Remove this entire block
// export const config = {
//   runtime: 'experimental-edge',
// };

Your code should work fine with standard Node runtime. If you really need edge performance, use fetch directly against Airtable’s REST API instead of their SDK.

I kept Node runtime for my Airtable pages - performance difference wasn’t worth the hassle. Airtable SDK makes life easier with built-in pagination and error handling.

Want to learn more about Next.js patterns and when to use different runtimes? This video covers it well:

Once you remove that edge config, your import will work perfectly.

5

Hit this exact nightmare 4 months ago migrating a legacy project to Next.js. The issue isn’t just edge runtime - it’s how Airtable’s SDK handles module resolution during SSR. Import Airtable at module level and it immediately tries initializing dependencies that need full Node.js APIs. Edge runtime strips most of these out, so you get the URL malformed error before your code even runs. Removing edge runtime config should fix it, but there’s another gotcha. Check you’re not accidentally setting NEXT_RUNTIME=edge in environment variables or deployment settings - this overrides page-level runtime config. Switched back to Node.js runtime and Airtable SDK worked perfectly. Performance hit was nothing since you’re already waiting on external API calls anyway. If you really need edge performance elsewhere, split your data fetching into separate API routes running on Node.js runtime.

6

Had this exact problem six months ago building a client dashboard. Your Airtable config isn’t the issue - it’s the experimental edge runtime. Edge has a completely different execution environment that’s missing tons of Node.js globals and APIs. When Airtable loads, it does internal URL parsing that needs Node.js-specific behavior.
Removing edge runtime will fix it, but here’s another approach I found. Move your Airtable calls to a separate API route that runs on Node.js runtime, then call that from getServerSideProps. You keep edge performance for your main page logic but run database operations on standard runtime. You’ll have an extra internal HTTP call, but that’s nothing compared to Airtable’s API latency.

7

Quick fix - you’re hitting a classic edge runtime incompatibility. I ran into this exact same error building a dashboard that pulled from multiple APIs last year.

The Airtable SDK breaks in edge runtime because it does internal URL construction that fails. Even before you call any functions, the library tries to validate endpoints and crashes since edge doesn’t handle URLs the same way Node.js does.

Drop this block:

export const config = {
  runtime: 'experimental-edge',
};

Your code will work immediately. I know edge runtime sounds appealing for performance, but when you’re already waiting on external API calls like Airtable, the runtime difference is basically nothing.

One thing I learned - if you really want better performance, consider using getStaticProps with ISR instead of getServerSideProps. Set a revalidation period that makes sense for your data freshness needs. You’ll get better performance than edge runtime ever gave you.

The SDK works perfectly with standard Node.js runtime. I’ve been using it in production for over a year without issues.

8

Hit this exact same problem last year building a data dashboard. Your Airtable setup is fine - the issue is that the experimental edge runtime doesn’t have the Node.js environment the Airtable library needs. The SDK tries to validate URLs internally but fails because key Node.js globals are missing in edge context. Just remove the config export completely and switch back to the default Node.js runtime. Your code will work as-is after that. Performance difference between edge and Node.js runtime is pretty minimal anyway when you’re already hitting external APIs like Airtable. If you’re worried about cold starts, try ISR (Incremental Static Regeneration) instead of SSR for this data fetching. You’ll get better performance than edge runtime and keep full Node.js library compatibility.

9

Honestly, just ditch the experimental edge runtime completely - it’s causing all sorts of weird issues with third party libs. Airtable SDK works fine on regular Node.js runtime. I’ve been using it for months without problems. The performance gain from edge isn’t worth the headache when you’re dealing with external APIs anyway.

10

The experimental edge runtime is the source of your issue. I experienced a similar problem when attempting to use Node.js libraries with the edge runtime. Many libraries, including Airtable’s SDK, are not designed for the edge environment, which has different APIs and restrictions from the standard Node.js runtime. To resolve this, you should remove the config export and revert to the default Node.js runtime. If you require edge runtime for better performance, consider bypassing the Airtable library and directly using their REST API with fetch. Their API is straightforward, allowing you to manage authentication and requests without much complexity. Alternatively, you can transfer your Airtable logic to a traditional API route (pages/api/) that operates on Node.js, and then call it from getServerSideProps.

11

This goes beyond edge runtime issues - Airtable’s SDK has problems with base URL resolution during server-side execution. I hit this building a CMS last year. Even with Node.js runtime, the SDK sometimes can’t resolve its internal endpoints when process.env variables don’t load right at build time. Check that your AIRTABLE_KEY and AIRTABLE_DATABASE are set in .env.local and accessible during build. Try calling await records.all() explicitly instead of just creating the query object - the SDK needs to execute the request to validate the config. That malformed URL error usually happens when the SDK tries building requests with undefined environment variables, creating empty URL strings. Double-check your environment variable names match exactly what’s in your code.