supabase

This happens when you pass a capitalized Content-Type header in file_options. The storage backend fails to parse the multipart body and stores the entire envelope (including --boundary strings) as the file content, while still returning 200 OK.

**Fix:** Use the lowercase content-type header instead:

# ❌ Broken - stores multipart boundaries
supabase.storage.from_("bucket").upload(
    filename, file_content,
    file_options={"Content-Type": file.content_type}
)

# ✅ Works - stores actual file bytes
supabase.storage.from_("bucket").upload(
    filename, file_content,
    file_options={"content-type": file.content_type}
)

This affects both the Python client (confirmed on v2.17.0) and direct REST API calls. Although HTTP headers should be case-insensitive per RFC, the storage backend's multipart parser is case-sensitive. If you already uploaded corrupted files, re-upload them with the lowercase header and verify downloads return valid content.

The response from supabase.auth.oauth.approveAuthorization() / denyAuthorization() returns data.redirect_url, not data.redirect_to. Older Supabase docs examples used the wrong property name, causing window.location.href = undefined and an infinite redirect loop to /oauth/undefined. Fix: use const { data, error } = await supabase.auth.oauth.approveAuthorization(authorizationId) then window.location.href = data.redirect_url. Note: in browsers the SDK auto-redirects by default, so the manual redirect is only needed when passing skipBrowserRedirect: true. The documentation has since been corrected.

The 'Enable email confirmations' toggle (Authentication > Providers > Email) only applies to NEW signups. Users who registered while confirmation was enabled remain unconfirmed and still get the 'Email Not Confirmed' error. To fix existing users, either: 1) Manually confirm them via the SQL Editor: UPDATE auth.users SET email_confirmed_at = NOW() WHERE email_confirmed_at IS NULL; (or target a specific user with WHERE email = 'user@example.com'), or 2) Delete the test user from Authentication > Users and sign up again. New signups after disabling the setting will be confirmed automatically and can sign in immediately.

Contact Supabase support immediately at support@supabase.com with your project ref, organization, and deletion date so they can review your specific case. Note that per Supabase's documentation, deleted projects are normally permanently removed and cannot be self-restored, so recovery is not guaranteed. For future prevention: enable daily backups (available on the Pro plan) under Project Settings > Database > Backups, download backups regularly, or create your own dumps with pg_dump via the connection string found in Project Settings > Database.

If your card is declined when paying a Supabase invoice, first confirm with your bank or card issuer that they are not blocking the transaction. If the bank confirms the card is fine but payment still fails across multiple cards, this is a billing-side issue that cannot be fixed on your end. Contact Supabase billing support directly at support@supabase.com with your organization/project details so the team can investigate the payment failure and process your invoice.