How to Authenticate a REST API in TableCrafter (API Key, Bearer Token)

Updated July 2026 • 6 min read • By Fahad Murtaza

TableCrafter supports four authentication modes for REST API data sources: no authentication, API key as a request header, API key as a query parameter, and Bearer token. This guide covers when to use each method, how to configure it, and how TableCrafter handles credential security. The free version on WordPress.org supports CSV, JSON, Google Sheets, and Excel. Pro adds Gravity Forms, Airtable, Notion, WooCommerce, REST APIs, inline cell editing, export to CSV and Excel, and role-based column visibility. Every table embeds on any page with a [tablecrafter] shortcode or the native Gutenberg block. All credentials stored in the data source settings are encrypted using AES-256-CBC keyed off your site's WordPress secret keys before being written to the database.

Where to Configure Authentication?

Authentication is set at the data source level, not the table or shortcode level. Go to TableCrafter → Data Sources, open an existing REST API source or create a new one, and locate the Authentication section. Credentials entered here apply to every table that uses this data source, so if you have five tables pointing at the same API, you configure the key once and all five tables benefit.

Creating a dedicated data source per external API rather than duplicating credentials across tables has a maintenance benefit: when an API key rotates, you update it in one place and every dependent table picks up the change on the next page load. The data source is also where you set the endpoint URL, response path (the JSON key that contains the rows array), and optional caching interval. Authentication is one of several settings in the data source panel, and the plugin validates the credential format on save without ever echoing the raw value back to the browser after initial entry.

What Is Option 1: No Authentication (Public APIs)?

Select None when the API is fully public and requires no credentials. This is the right choice for:

• JSONPlaceholder (https://jsonplaceholder.typicode.com)
• Open government data APIs (data.gov, api.data.gov)
• Public weather feeds without an account requirement
• Your own WordPress REST API endpoints that are publicly readable

No additional configuration is needed. TableCrafter sends a plain GET request to the endpoint URL with no credential headers or query parameters appended.

Even with a public API, the SSRF protection layer in TableCrafter runs on every request. The resolved IP address of the hostname is checked against private ranges (10.0.0.0/8, 192.168.0.0/16, loopback, cloud metadata at 169.254.169.254) before the request is made. If the domain resolves to a private IP, the request is blocked regardless of the authentication mode. This means you cannot accidentally point a table at an internal service by using a public API hostname that DNS-rebinds to a private address.

For public APIs that return CORS headers, the request originates server-side from PHP (not browser-side), so CORS restrictions on the API side do not apply. TableCrafter's REST API fetching is always server-to-server.

What Is Option 2: API Key as a Request Header?

Many commercial APIs authenticate via a custom header. Select API Key (Header) and fill in two fields:

• Header Name: the exact header the API expects, for example X-API-Key, X-Auth-Token, or api-key
• Header Value: your API key string

TableCrafter will add this header to every request made to the endpoint. Example configuration for an API that uses X-API-Key:

Header Name:  X-API-Key
Header Value: sk_live_abc123def456

This is the most common format for APIs like OpenWeatherMap (using x-api-key), Airtable (using Authorization: Bearer, covered below), and many SaaS platforms.

What Is Option 3: API Key as a Query Parameter?

Some older APIs and some public data portals pass the key as a URL query parameter rather than a header. Select API Key (Query Parameter) and fill in:

• Parameter Name: the query string key, commonly api_key, apikey, key, or token
• Parameter Value: your API key string

TableCrafter appends this parameter to the endpoint URL before making the request. If your base URL is https://api.example.com/data and the parameter name is key, the actual request goes to:

https://api.example.com/data?key=YOUR_KEY_HERE

What Is Option 4: Bearer Token?

OAuth 2.0 APIs and many modern REST APIs use Bearer token authentication. Select Bearer Token and enter your token in the Token field. TableCrafter will send the header:

Authorization: Bearer YOUR_TOKEN_HERE

This is the correct method for:

• GitHub API (Authorization: Bearer ghp_xxx)
• Airtable API (Authorization: Bearer patXXX)
• Any OAuth 2.0 access token
• Stripe API (Bearer token using your secret key)

Note that Bearer tokens obtained via OAuth flows typically expire. TableCrafter does not currently handle automatic token refresh. For long-lived static tokens (personal access tokens, API keys issued as bearer tokens), this is not a concern. For short-lived OAuth access tokens, you would need to update the token manually or via a custom wp-cron job that refreshes it and updates the data source via the REST API.

How Credentials Are Stored?

All credentials, API keys, tokens, and header values, are encrypted using AES-256 before being written to the WordPress database. TableCrafter uses WordPress's built-in AUTH_KEY and SECURE_AUTH_KEY constants from wp-config.php as part of the encryption key derivation. The stored value in wp_options is a base64-encoded ciphertext, not the raw credential.

To take advantage of this, make sure your wp-config.php uses strong, unique values for AUTH_KEY and SECURE_AUTH_KEY, the WordPress secret keys generator at https://api.wordpress.org/secret-key/1.1/salt/ produces suitable values.

Credentials are decrypted in memory at request time and never written to debug logs or displayed in admin screens after initial entry. When you edit a data source, the credential fields show placeholder text rather than the stored value.

How Does SSRF Protection Work?

Server-Side Request Forgery (SSRF) is an attack where a malicious user tricks your server into making requests to internal network addresses, your database, the WordPress server itself, or cloud metadata endpoints. TableCrafter includes a built-in SSRF protection layer that blocks requests to:

• Private IPv4 ranges: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
• Loopback: 127.0.0.0/8
• IPv6 loopback: ::1
• Cloud metadata endpoints: 169.254.169.254 (AWS/GCP/Azure IMDSv1)
• Link-local addresses

This check runs on the resolved IP address of the hostname, not just the URL string, so DNS rebinding attacks (where a hostname resolves to a private IP) are also blocked. If you see an error like "SSRF protection: request to private address blocked", the endpoint URL resolves to a private IP range and cannot be used as a data source.

How Does Debugging Authentication Failures Work?

After configuring authentication, click Test Connection. If the test fails, the error display shows the HTTP status code and response body from the API. Common patterns:

• 401 Unauthorized, credentials are missing or malformed. Check the header name exactly, many APIs are case-sensitive (X-API-Key vs x-api-key).
• 403 Forbidden, credentials are valid but the key does not have permission for this endpoint. Check the API's scopes or permission settings in your API provider dashboard.
• 400 Bad Request, the request is malformed. If using query parameter auth, verify the parameter name matches what the API documentation specifies exactly.

How Does Custom Headers Beyond Authentication Work?

Some APIs require additional headers beyond authentication — for example Accept: application/json to specify the expected response format, Content-Type: application/json for APIs that require it on GET requests, API version headers like Stripe-Version: 2024-06-20, or custom tenant or workspace identifiers like X-Organization-Id: abc123. Use the Custom Headers section of the data source configuration to add arbitrary key-value header pairs. These are sent on every request alongside the authentication header you configured in the preceding step.

Custom headers are stored encrypted in the WordPress database alongside the authentication credentials. You can add as many header pairs as the API requires — there is no limit on header count. Header names are case-insensitive per HTTP/1.1 spec, but enter them in the canonical form expected by the API (e.g., Stripe-Version not stripe-version) to avoid confusion during debugging. To verify the headers are being sent correctly, use the Test Connection button in the data source settings — if the API responds successfully, the headers are correct; if it returns 400 or 422, check the header names and values against the API documentation.