Security Featured

Base44 Legacy API Key Audit (October 15, 2026 Deadline)

Base44 is retiring legacy api_key authentication on October 15, 2026. Run this read-only audit prompt to find every place your app still uses the old header before it breaks.

How to use this prompt

🚨 Base44 Apps May Break on October 15, 2026

Base44 is replacing its legacy account and app API keys with personal access tokens.

This is not an automatic migration.

If your application, automation, script, or external integration still sends an API key using the old

api_key

header after October 15, its requests will fail.

That could cause:

Automations to stop running
Data synchronization to fail
External dashboards to stop updating
Orders or customer records to stop transferring
Scheduled scripts to fail
Integrations between applications to disconnect
AI tools and external development agents to lose access

This does not mean every Base44 app will break. It affects applications and services that use Base44's API through the old authentication method.

The authentication format is changing from:

api_key: YOUR_API_KEY

To:

Authorization: Bearer YOUR_PERSONAL_ACCESS_TOKEN

You cannot simply paste the new token into the existing API key field. Your code must send the token through the Authorization header as a bearer token.

What you need to do

Audit your code, environment variables, scripts, automations, and external services for
```
api_key
```
or
```
BASE44_API_KEY
```
.
Identify which workspace and app each integration accesses.
Create a personal access token under: Workspace → Settings → Secrets → Personal access tokens
Give each token only the access it needs. Use read-only access where possible and limit it to one app instead of the entire workspace.
Store the token securely as an environment variable or encrypted secret. Never place it in frontend code or commit it to GitHub.
Update the authentication header in every request.
Test reads, writes, function calls, scheduled jobs, webhooks, and background automations.
Monitor for
```
401 Unauthorized
```
and
```
403 Forbidden
```
errors.
Delete the old API key only after confirming that nothing still depends on it.

I also recommend creating a separate token for each integration. That way, one compromised or disabled token does not take down every connected system.

Personal access tokens are tied to the person who created them. If that person leaves the workspace, the token stops working. Workspace owners can see and disable member tokens, although they cannot view the actual token value.

Base44 shows each token only once when it is created, so save it securely immediately.

Do not wait until October 15 to discover which apps still use the old authentication system. Start auditing and migrating them now.

FREE PROMPT BELOW — copy it and run it in your app.

The prompt

Perform a complete, read-only authentication audit of this Base44 application.

## Objective

Identify every location that still uses Base44's legacy API-key authentication system:

```http
api_key: YOUR_API_KEY
```

These calls must migrate to:

```http
Authorization: Bearer YOUR_PERSONAL_ACCESS_TOKEN
```

Do not modify any code, secrets, functions, workflows, or configuration. Generate a report only.

## Scope

Scan the entire accessible application, including:

* Frontend source files
* Backend functions
* Shared API clients and request utilities
* Automations and scheduled jobs
* Workflows and event handlers
* Webhook handlers
* Server, API, worker, and edge-function directories
* Scripts and migration utilities
* Environment-variable references
* Secret names and configuration files
* Axios instances and interceptors
* `fetch()` requests
* SDK client initialization
* cURL commands stored in scripts
* Documentation containing executable examples
* Any available logs showing API-key activity

Do not limit the audit to files currently imported by the frontend. Include backend-only and scheduled code.

Exclude generated directories such as `node_modules`, `dist`, and build output unless the application actively references a generated file at runtime.

## Search Patterns

Search case-insensitively for:

* `api_key`
* `api-key`
* `x-api-key`
* `BASE44_API_KEY`
* `B44_API_KEY`
* `APP_API_KEY`
* `ACCOUNT_API_KEY`
* `appApiKey`
* `accountApiKey`
* `apiKey`
* `headers.api_key`
* `headers["api_key"]`
* `headers['api_key']`
* Axios default headers containing API keys
* API client constructors receiving an API key
* Environment or secret values passed into request headers
* Requests made to `app.base44.com`
* Requests made to Base44 API endpoints
* Shared request helpers that could add the old header indirectly

Trace variables back to their source. For example, if a request uses `headers: authHeaders`, inspect where `authHeaders` is created.

## Accuracy Requirements

Only classify something as confirmed legacy Base44 authentication when the old header or credential is connected to a Base44 request.

Do not confuse Base44 authentication with API keys for:

* OpenAI
* Stripe
* Resend
* Cloudflare
* Google
* Twilio
* Airtable
* Other external services

Place ambiguous results in a separate "Manual Review Required" section.

Do not classify normal Base44 user authentication, session tokens, `base44.auth`, or third-party bearer tokens as legacy authentication unless they ultimately depend on an old Base44 account or app API key.

## Security Requirements

* Never print or expose a complete API key, token, or secret.
* Replace discovered credential values with `[REDACTED]`.
* Report secret and environment-variable names only.
* Do not move secrets into frontend code.
* Do not create a personal access token.
* Do not delete, rotate, disable, or replace any existing credential.
* Do not make code changes.

## Required Report

### 1. Executive Summary

Provide:

* Overall status: `Legacy`, `Mixed`, `Migrated`, `No Legacy Usage Found`, or `Inconclusive`
* Number of confirmed legacy authentication locations
* Number of unique shared authentication helpers
* Number of affected functions, workflows, or integrations
* Number of locations already using bearer-token authentication
* Number of ambiguous locations requiring manual review
* Overall risk: Critical, High, Medium, or Low
* Expected impact if nothing is changed before October 15, 2026

### 2. Confirmed Legacy Authentication

Create a table with:

| Severity | File and Line | Function/Component | Base44 Endpoint | Old Authentication Evidence | Secret Reference | Trigger | Feature Affected | Confidence |
| -------- | ------------- | ------------------ | --------------- | --------------------------- | ---------------- | ------- | ---------------- | ---------- |

For every result:

* Provide the exact file path and line number.
* Identify the function, component, workflow, or script.
* Show only the relevant code snippet.
* Redact all credential values.
* Explain when the code runs.
* Explain what user-facing or business feature would stop working.
* Identify whether the authentication comes from a shared helper.
* Assign a confidence level of Confirmed, Likely, or Possible.

### 3. Dependency and Blast-Radius Analysis

Determine whether multiple features depend on:

* The same legacy secret
* The same request helper
* The same Axios instance
* The same backend function
* The same account-level API key

Explain which features could fail together if that shared credential is removed or expires.

### 4. Already Migrated Locations

List requests already using:

```http
Authorization: Bearer ...
```

Only include them when they authenticate requests to Base44.

For each location, report:

* File and line
* Function or integration
* Token secret name
* Token scope if visible
* Whether the token appears to be stored server-side
* Any security concerns

Do not reveal token values.

### 5. Manual Review Required

List anything that cannot be inspected directly, including:

* Make scenarios
* Zapier workflows
* n8n workflows
* Cloudflare Workers
* Vercel or Netlify functions
* External servers
* GitHub Actions
* Local scripts
* Mobile application backends
* MCP configurations
* Third-party cron services
* External environment variables
* Integrations configured outside this Base44 application

For each item, explain exactly what a human should check.

### 6. Migration Recommendations

For each confirmed legacy location, recommend:

* The file or external system that needs updating
* The header that must be replaced
* The minimum required token access
* Whether read-only or full access is required
* Whether the token should be restricted to one app
* Which workflows must be tested afterward

The expected change is:

```http
# Old
api_key: YOUR_API_KEY

# New
Authorization: Bearer YOUR_PERSONAL_ACCESS_TOKEN
```

Do not implement this change.

### 7. Prioritized Action Plan

Organize the findings into:

1. Critical production flows
2. Shared authentication utilities
3. Scheduled jobs and automations
4. External integrations
5. Internal or development scripts
6. Low-risk or unused code

Recommend migrating shared authentication utilities first when doing so safely updates multiple confirmed callers.

### 8. Testing Checklist

Create a checklist covering every affected flow, including:

* Read requests
* Create and update operations
* Deletes
* Backend function calls
* Webhook processing
* Scheduled jobs
* Data synchronization
* Admin operations
* External dashboards
* Error monitoring for `401` and `403` responses

## Final Verification

At the end of the report, state:

* Which directories and systems were inspected
* Which areas could not be inspected
* Whether any findings remain uncertain
* Whether any code or configuration was changed

Do not claim the application is fully migrated when external systems or inaccessible configuration could still be using the legacy key.

Need help making the switch?

If the audit turns up legacy API keys and you'd rather not migrate them yourself, we'll handle the token migration, header updates and testing for you.

Get migration help

Security

#base44

#api keys

#personal access tokens

#security audit

#migration