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. WordPress powers 43% of all websites globally (W3Techs, July 2026), and TableCrafter bridges the gap between the data you collect and the tables your users need to see, no custom PHP, no dashboard access required for viewers. 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/PDF, role-based column visibility, and auto-refresh. Every table embeds on any page with a [tablecrafter] shortcode or the native Gutenberg block. Google Sheets supports real-time collaboration for up to 100 simultaneous editors (Google Workspace documentation, 2025).

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.

If this step produces unexpected output, check the source data directly in the connected system. TableCrafter passes data through without modification — if a cell displays an unexpected value, the source record contains that value. Use the TableCrafter debug log (Settings > Advanced > Debug Mode) to trace the exact query sent to the source and the raw response received, which narrows the diagnosis to either a source-side or rendering-side issue.

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.

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.

The shortcode accepts all column and filter settings defined in the table builder as defaults, but you can override individual parameters inline. For example, `[tablecrafter id="1" per_page="25"]` overrides the default rows-per-page setting for this specific embed without changing the saved table configuration. This lets you reuse one table definition across multiple pages with different display requirements.

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:

This configuration interacts with any caching or CDN layer active on your WordPress installation. If you use WP Rocket, LiteSpeed Cache, or a CDN such as Cloudflare, flush the page cache after making this change to ensure the updated configuration is reflected in the cached HTML served to visitors. TableCrafter's server-side output is regenerated on the next uncached request.

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: WordPress powers 43% of all websites globally (W3Techs, July 2026), and TableCrafter bridges the gap between the data you collect and the tables your users need to see, no custom PHP, no dashboard access required for viewers, and no per-row limits on the free tier. 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/PDF, role-based column visibility, and auto-refresh. Every table embeds on any page with a [tablecrafter] shortcode or the native Gutenberg block.

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.

After completing this step, verify the result by viewing the page as a logged-out visitor in an incognito window. This confirms the table behaves correctly for public visitors rather than reflecting admin-level permissions that may hide configuration issues during initial setup. Check both the rendered output and the browser console for any JavaScript errors.

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.

The column mapping you define here is stored as a JSON configuration in the WordPress database. You can export this configuration using the TableCrafter export tool and import it to another table or another site. This is useful when replicating a table layout across multiple pages or when migrating a table to a staging environment for testing before going live.

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:

TableCrafter re-fetches this data on each page load by default. If your data source updates infrequently and your site has significant traffic, enable the built-in caching option in the table's Performance tab. This stores the fetched data for a configurable number of minutes and serves it from WordPress transients, reducing API calls to the source and improving page load time for visitors.

• 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.