API Issues (#373)

* Add troubleshooting FAQ

* Added API troubleshooting FAQ

* proper spacing

* Added more CodeMagic Deployment tips

* assets added, typos fixed, formating fixed.

* improved formatting and updated content.

* Update docs/troubleshooting/api/client-server_errors_during_the_api_call.md

Co-authored-by: Pooja Bhaumik <[email protected]>

* Update docs/troubleshooting/api/client-server_errors_during_the_api_call.md

Co-authored-by: Pooja Bhaumik <[email protected]>

* Update docs/troubleshooting/api/client-server_errors_during_the_api_call.md

Co-authored-by: Pooja Bhaumik <[email protected]>

* two files merged into one, improved formatting.

* improved formatting and bolded internal hyperlinks

* fixed headers, added more details

---------

Co-authored-by: David Edet Orok <[email protected]>
Co-authored-by: Pooja Bhaumik <[email protected]>

Author: 3 people

docs/troubleshooting/api/_category_.json

@@ -0,0 +1,3 @@
+{
+    "label": "API"
+}

docs/troubleshooting/api/api_charset_and_encoding_fix_guide.md

@@ -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]

docs/troubleshooting/api/client-server_errors_during_the_api_call.md

@@ -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**
+
+    The 400 error is a generic response indicating that the server could not understand the request due to malformed syntax. Common causes include incorrect query parameters or missing fields in the request body. Ensure your request is correctly formatted and all required information is included.
+
+    :::tip
+    Check the API's own documentation to ensure you're including the correct fields and headers.
+    :::
+
+    ![400 Example](../assets/20250430121351345482.png)
+
+- **401 – Unauthorized**
+
+    This status code appears when authentication has not yet been provided. To resolve this, ensure you have signed up for the API and included your API key in the HTTP header of your request.
+
+    ![401 Example](../assets/20250430121350799148.png)
+
+- **403 – Forbidden**
+    
+    Receiving a 403 error means you're authenticated but do not have permission to access the requested resource. This could be due to using the wrong API key or attempting to access features not available in your subscription plan.
+
+    ![403 Example](../assets/20250430121351077308.png)
+
+- **404 – Not Found**
+
+    The 404 error indicates that the requested URL does not exist on the server. This could be due to a typo in the URL or changes in the API endpoints. Always verify the URL and check for any recent API updates.
+
+    :::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**
+
+    This error occurs when too many requests are sent in a short period, exceeding the API's rate limits. To avoid this, implement request throttling or review your API subscription plan to ensure it meets your needs.
+
+    :::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**
+
+    A 500 error can occur for various reasons, often indicating that the API server has crashed. Check your request for accuracy and consult the API documentation for any known issues.
+
+- **501 – Not Implemented**
+
+    This error occurs when the HTTP method used in the request is not supported by the server. Trying a different HTTP method or checking the API documentation for supported methods can resolve this issue.
+
+- **502 – Bad Gateway**
+
+    This error means that the server, acting as a gateway or proxy, received an invalid response from the upstream server. It's usually a temporary issue that should be resolved by the API provider.
+
+- **503 – Service Unavailable**
+
+    The 503 status code indicates that the server is temporarily unable to handle the request due to overload or maintenance. Waiting before sending another request is often the best approach.
+
+- **504 – Gateway Timeout**
+
+   A 504 error suggests that the server, acting as a gateway, did not receive a timely response from the upstream server. This could be due to network latency or the API server processing the request too slowly.
+
+
+**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!
+:::

docs/troubleshooting/api/securing_your_api_keys_in_private_api_calls.md

@@ -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.
+:::
+​