Skip to content

API Issues #373

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 16 commits into from
Jun 16, 2025
Merged
Show file tree
Hide file tree
Changes from 12 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions docs/troubleshooting/api/_category_.json
Original file line number Diff line number Diff line change
@@ -0,0 +1,3 @@
{
"label": "API"
}
55 changes: 55 additions & 0 deletions docs/troubleshooting/api/api_charset_and_encoding_fix_guide.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,55 @@
---
keywords: ['api', 'encoding', 'charset']
slug: /api-charset-and-encoding-fix-guide
title: API Charset and Encoding Fix Guide
---
# API Charset and Encoding Fix Guide

When working with API calls in FlutterFlow, you might encounter issues where the response returns with strange characters, incorrect formatting, or unreadable content. These problems are often caused by improper charset or encoding settings either in the API request or the server response.

This guide shows you how to resolve such issues and ensure your API outputs are correctly displayed in your FlutterFlow project.

Follow the steps below:

1. **Set Proper Request Headers**

Make sure your API call includes the appropriate headers to instruct the server on how to format the response. Add the following headers to your API configuration:

`Content-Type: application/json`

`Charset: utf-8`​


These headers tell the server to return the data in JSON format using UTF-8 encoding, which is compatible with FlutterFlow.

![Setting Content-Type and Charset headers](../assets/20250430121409119593.png)

2. **Enable UTF-8 Decoding in FlutterFlow**

If the server does not specify encoding—or if you're still getting corrupted text—you can configure FlutterFlow to decode the API response as UTF-8 manually.

To do this:

1. Go to your API call setup in FlutterFlow.
2. Scroll to **Advanced Settings**.
3. Enable **Force response decoding as UTF-8**.

This setting helps FlutterFlow correctly interpret the API response, especially from servers that don’t return standard headers.

![Force decode response as UTF-8](../assets/20250430121409391507.png)


:::tip[Final Tips]
- Always test your API calls in FlutterFlow’s API Test tab to ensure the response is properly formatted.
- Confirm that the external API supports UTF-8 and returns a valid JSON response.
- Review your server settings if you control the backend, to ensure it sends the correct headers.
:::

:::note
Incorrect API call outputs due to charset or encoding can be quickly resolved by:
- Adding proper headers like `Content-Type: application/json` and `Charset: utf-8`.
- Enabling **Force response decoding as UTF-8** in FlutterFlow’s API advanced settings.
These simple steps will help you get accurate and readable data from your APIs, resulting in a smoother app development experience.
:::

If you still face challenges, don't hesitate to reach out to our support team through Live chat or by emailing [email protected]
119 changes: 119 additions & 0 deletions docs/troubleshooting/api/client-server_errors_during_the_api_call.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,119 @@
---
keywords: ['api', 'error', 'client']
slug: /client-server-errors-during-the-api-call
title: Client-Server Errors during the API call
---
# Client-Server Errors During the API Call


When calling an API in FlutterFlow, you may run into client-server errors. These typically come as status codes that indicate what went wrong, either on your end (the client) or on the server you're requesting data from.

This guide will help you understand the most common API error codes and how to fix them.

To learn more about APIs, check out our [API documentation guide](/resources/backend-logic/rest-api/).

## Common client-side status codes

These errors are usually caused by incorrect requests from the client side.

- **400 – Bad request**

Your request isn’t properly formatted. This could be due to a missing parameter, a typo, or incorrect syntax.

:::tip
Check the API's own documentation to ensure you're including the correct fields and headers.
:::

![400 Example](../assets/20250430121351345482.png)

- **401 – Unauthorized**

You didn’t provide the correct credentials (like an API key). Most APIs require authentication via headers.

![401 Example](../assets/20250430121350799148.png)

- **403 – Forbidden**

You’re authenticated, but you don’t have permission to access the resource. This could be due to API plan restrictions or role-based access.

![403 Example](../assets/20250430121351077308.png)

- **404 – Not found**

The URL you’re requesting doesn’t exist. This could be due to a typo or a deprecated API endpoint.

:::tip
Always double-check your request URL before troubleshooting further.
:::

![404 Example](../assets/20250430121350517804.png)

- **407 – Proxy authentication required**

You haven't authenticated with the proxy server. This is less common but can happen in restricted network environments.

- **422 – Unprocessable entity**

Your request was well-formed but couldn’t be processed. For example, passing a `latlng` without a comma.

- **429 – Too many requests**

You’ve hit your rate limit. Most APIs restrict the number of requests you can make in a certain timeframe.

:::tip
Check your API plan limits and consider throttling requests from your app.
:::

## Common server-side status codes

These errors occur on the API server side.

- **500 – Internal server error**

The server ran into an unexpected issue. Double-check your request, but if it looks fine, the problem is likely on the server side.

- **501 – Not implemented**

The HTTP method you're using (example, PUT or PATCH) isn't supported by the API yet.

- **502 – Bad gateway**

The API server is using a gateway or proxy, and it failed to get a valid response from the upstream server. Usually a temporary issue.

- **503 – Service unavailable**

The API server is overloaded or undergoing maintenance. Try again later.

- **504 – Gateway timeout**

The API server took too long to respond. Try simplifying your request or reducing the size of the data being sent.


**Troubleshooting Steps**

- **Clear Browser Cache and Cookies**

If you're encountering a 400 Bad Request error, clearing your browser's cache and cookies can resolve issues related to expired or invalid data.

- **Verify the Requested URL**

Ensure the URL or endpoint is correct. Remember, domain names are case-sensitive.

- **Adjust Request Parameters**

For 400 errors, check if the file size is too large (for POST requests) or if there are any other incorrect parameters.

- **Consult API Documentation**

Always refer to the API's official documentation for specific requirements and troubleshooting tips.

- **Contact API Support**

If you continue to face issues, reaching out to the API's support team can provide further assistance and insights into resolving the problem.

Understanding these common API error status codes and their solutions can significantly smooth the development process, ensuring more efficient and effective communication between your application and the APIs you rely on.

:::tip[Final tips]
- Always check the API's own documentation, inspect your request, and look up error messages. If the issue persists, contact the API provider.
- Once you fix the issue, your calls should return a `200 OK`, which means everything is working as expected!
:::
Original file line number Diff line number Diff line change
@@ -0,0 +1,50 @@
---
keywords: ['api', 'calls', 'private']
slug: /securing-your-api-keys-in-private-api-calls
title: Securing Your API Keys in Private API Calls
---
# Securing Your API Keys in Private API Calls


Ensuring the security of API keys is a critical aspect of building and maintaining a safe and reliable application. In the realm of private API calls, it's especially important to make sure your API keys are not exposed. This article aims to provide a best-practices guide on where to place your API keys to increase security in a FlutterFlow environment.​

**The Misconception: Private API Calls Secure Everything**

Many users assume that simply marking an API call as 'private' is enough to protect all associated data. However, this is not the case. Private API calls run in a Cloud Function, which means any keys or sensitive data in the body will be secure, as long as they're not passed in from the frontend. Even in private API calls, if you're loading an API key from the frontend (like from Firebase remote configs), then you're still exposing it.​

## Secure Placement of API Keys in Your Project

The ideal way to secure an API key is to include it in a request header or directly within the API endpoint URL. This ensures that it is never passed in from the client, thereby maintaining its confidentiality.​

For example, you can hard-code the key directly into your API call header like this:​

```js
{ "Authorization": "Bearer YOUR_API_KEY_HERE" }
```

Or directly within the API endpoint URL:​

```js
https://api.example.com/resource?api_key=YOUR_API_KEY_HERE
```
The key should never be a variable that gets passed in from the frontend, as that would make it accessible via the client-side code, defeating the purpose of using private API calls for secure operations.

## Verifying the Security of Your API Key

After implementing these changes, a straightforward way to verify that your key is secured is by downloading your application code and checking to make sure the API key doesn’t appear in any frontend files.​

Example: Not Secure

![](../assets/20250430121157297846.png)

Example: More Secure

![](../assets/20250430121157601185.png)


By adhering to these best practices, you can increase the safety of your API keys even while making private API calls.

:::info
The goal is to keep all sensitive data, including API keys, away from the client side of the application to ensure optimal security.
:::
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.