Krow/Krow-workspace
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat(docs): add MAINTENANCE_GUIDE.md to describe the process of updating the API documentation and specification

Browse Source 
feat(docs): update API_documentation.md with comprehensive API specifications for all entities, SDK methods, and integration endpoints
feat(docs): update api_specification.md to align with the updated API documentation and guide the development of the new backend
This commit is contained in:
bwnyasse
2025-11-11 06:57:58 -05:00
parent e571193362
commit 866d0df45c
4 changed files with 1929 additions and 344 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1838
docs/API_documentation.md
View File

File diff suppressed because it is too large Load Diff

55
docs/MAINTENANCE_GUIDE.md Normal file
View File

@@ -0,0 +1,55 @@
# Guide de Maintenance de la Documentation API
Ce document décrit la procédure à suivre pour mettre à jour la documentation de l'API et la spécification technique de notre backend après des modifications majeures sur la plateforme Base44.
Suivre ce processus est **essentiel** pour garantir que notre backend personnalisé sur GCP reste synchronisé avec les fonctionnalités du frontend.
## Quand Lancer cette Procédure ?
Vous devez suivre ce guide après chaque cycle de développement significatif sur la plateforme Base44, notamment après :
- L'ajout de nouvelles entités ou de nouveaux champs de données.
- La modification de la logique métier existante.
- L'intégration de nouvelles fonctionnalités majeures dans l'interface utilisateur.
---
## Procédure de Mise à Jour
### Étape 1 : Obtenir la Documentation à Jour de Base44
1. **Ouvrez le fichier `docs/base44_prompts.md`**.
2. Copiez le contenu du **"Prompt Principal"**.
3. Collez ce prompt dans le chat de l'IA de Base44 pour lui demander de générer la documentation la plus récente.
4. **Vérification :** L'IA doit retourner le contenu complet du fichier `API_documentation.md`. Si elle ne retourne qu'un résumé, utilisez le prompt simple suivant pour demander le contenu complet :
```text
Thank you for the summary. Please provide the entire, updated content of the API_documentation.md file now.
```
### Étape 2 : Mettre à Jour le Fichier de Documentation Local (avec Gemini CLI)
Pour garantir un formatage propre et cohérent, il est recommandé d'utiliser Gemini CLI pour cette étape.
1. **Copiez le contenu brut** fourni par l'IA de Base44.
2. **Donnez ce contenu à Gemini CLI** avec un prompt simple, par exemple :
> "Voici la nouvelle documentation de l'API Base44. Peux-tu reformater ce contenu et mettre à jour le fichier `docs/API_documentation.md` ?"
3. **Laissez Gemini CLI** gérer la création ou la mise à jour du fichier. Il s'assurera que les tableaux, les blocs de code et les en-têtes sont correctement formatés.
### Étape 3 : Mettre à Jour la Spécification de l'API GCP (avec Gemini CLI)
C'est l'étape la plus critique. Au lieu d'une comparaison manuelle fastidieuse, nous allons nous appuyer sur l'IA pour synchroniser notre plan de migration.
1. **Assurez-vous que l'Étape 2 est terminée** et que `docs/API_documentation.md` est à jour.
2. **Demandez à Gemini CLI** de mettre à jour la spécification pour vous. Utilisez un prompt clair, par exemple :
> "Maintenant que `docs/API_documentation.md` est à jour, peux-tu analyser les changements et mettre à jour de manière exhaustive le fichier `docs/api_specification.md` pour qu'il corresponde ?"
3. **Laissez Gemini CLI** effectuer l'analyse comparative et appliquer les modifications nécessaires (ajout de champs, d'entités, d'intégrations, etc.) au fichier de spécification.
### Étape 4 : Valider et Commiter les Changements
1. Relisez une dernière fois les modifications apportées à `api_specification.md` pour vous assurer qu'elles sont cohérentes.
2. Commitez les fichiers mis à jour dans Git avec un message clair et descriptif.
```bash
git add docs/API_documentation.md docs/api_specification.md docs/MAINTENANCE_GUIDE.md
git commit -m "docs: Update API documentation and specification from Base44 export"
```
---

329
docs/api_specification.md
View File

@@ -1,8 +1,8 @@
# Spécification de l'API KROW Workforce (Migration GCP)
**Version :** 1.0
**Date :** 10/11/2025
**Objectif :** Ce document définit l'API RESTful à construire sur Google Cloud Platform (Cloud Functions, Cloud SQL) pour remplacer le backend Base44. Il est basé sur la documentation fournie par Base44 et une analyse exhaustive de l'utilisation de son SDK dans le code source du frontend.
**Version :** 2.0
**Date :** 11/11/2025
**Objectif :** Ce document définit l'API RESTful à construire sur Google Cloud Platform (Cloud Functions, Cloud SQL) pour remplacer le backend Base44. Il est basé sur la documentation exhaustive de l'API Base44 (v2.0) et a pour but de guider le développement du nouveau backend.
---
@@ -24,218 +24,215 @@
Basé sur Firebase Authentication. Le frontend gère l'inscription et la connexion avec le SDK Firebase. Notre backend a besoin d'un endpoint pour récupérer les informations étendues de l'utilisateur.
### Entité `User`
### Entité `User` (Basée sur `base44.auth.me`)
| Champ | Type | Description |
| --------------- | -------- | ----------------------------------------- |
| `id` | `string` | ID Firebase de l'utilisateur |
| `email` | `string` | Email de l'utilisateur (non modifiable) |
| `full_name` | `string` | Nom complet |
| `user_role` | `string` | Rôle (`admin`, `procurement`, `client`...) |
| `company_name` | `string` | Nom de l'entreprise associée |
| `profile_picture` | `string` | URL de l'image de profil |
| `user_role` | `string` | Rôle personnalisé dans l'application (`admin`, `procurement`, `client`...) |
| `...autres` | `any` | D'autres champs personnalisés peuvent être ajoutés. |
### Endpoints
#### `GET /auth/me`
- **Description :** Récupère les informations du profil de l'utilisateur actuellement authentifié.
- **Utilisation observée :** `base44.auth.me()` (utilisé dans presque toutes les pages).
- **Réponse (200 OK) :**
```json
{
"id": "firebase-user-id-123",
"email": "dev@example.com",
"full_name": "Dev User",
"user_role": "admin",
"company_name": "KROW Corp",
"profile_picture": "https://..."
}
```
- **SDK d'origine :** `base44.auth.me()`
- **Réponse (200 OK) :** L'objet `User` complet.
#### `PUT /auth/me`
- **Description :** Met à jour le profil de l'utilisateur actuel.
- **Utilisation observée :** `base44.auth.updateMe(data)` (dans `WorkforceProfile.jsx`, `RoleSwitcher.jsx`).
- **Corps de la requête :**
```json
{
"full_name": "John Doe",
"profile_picture": "https://..."
}
```
- **SDK d'origine :** `base44.auth.updateMe(data)`
- **Corps de la requête :** Un objet avec les champs de `User` à mettre à jour.
- **Réponse (200 OK) :** L'objet `User` mis à jour.
---
## 2. Entités (CRUD)
## 2. Entités (Endpoints CRUD)
### 2.1. Event
Pour chaque entité ci-dessous, les endpoints standards suivants sont à implémenter.
**Description :** Gère les commandes de main-d'œuvre.
- `POST /{nom-entite}`: Crée une nouvelle entrée.
- `GET /{nom-entite}`: Liste les entrées, avec support pour le filtrage et le tri via des query params.
- `GET /{nom-entite}/{id}`: Récupère une entrée par son ID.
- `PUT /{nom-entite}/{id}`: Met à jour une entrée par son ID.
- `DELETE /{nom-entite}/{id}`: Supprime une entrée par son ID.
#### Schéma `Event`
### 2.1. Event (`/events`)
**Description :** Gère les événements et les commandes de main-d'œuvre.
| Champ | Type | Description |
| ------------- | -------- | ------------------------------------------------------------------------ |
| `event_name` | `string` | Nom de l'événement/commande |
| `order_type` | `string` | Enum: `rapid`, `one_time`, `recurring`, `permanent` |
| `business_id` | `string` | ID de l'entité `Business` (client) |
| `vendor_id` | `string` | ID de l'entité `Vendor` (fournisseur) |
| `status` | `string` | Enum: `Draft`, `Active`, `Pending`, `Assigned`, `Confirmed`, `Completed`, `Canceled` |
| `shifts` | `array` | Tableau d'objets `Shift` (défini comme une sous-entité ou un type JSON) |
| `date` | `string` | ISO 8601 Timestamp, date de début de l'événement |
| ----------------------- | --------- | ------------------------------------------------ |
| `event_name` | `string` | Nom de l'événement (requis) |
| `is_recurring` | `boolean` | Indique si l'événement est récurrent |
| `recurrence_type` | `string` | `single`, `date_range`, `scatter` |
| `recurrence_start_date` | `string` | Date de début de récurrence (ISO 8601) |
| `recurrence_end_date` | `string` | Date de fin de récurrence (ISO 8601) |
| `scatter_dates` | `array` | Tableau de dates (ISO 8601) pour `scatter` |
| `business_id` | `string` | ID du client (`Business`) |
| `business_name` | `string` | Nom du client |
| `vendor_id` | `string` | ID du fournisseur (`Vendor`) |
| `vendor_name` | `string` | Nom du fournisseur |
| `hub` | `string` | Lieu/hub |
| `contract_type` | `string` | `W2`, `1099`, `Temp`, `Contract` |
| `po_reference` | `string` | Référence de bon de commande |
| `status` | `string` | `Draft`, `Active`, `Pending`, `Assigned`, `Confirmed`, `Completed`, `Canceled` |
| `date` | `string` | Date de l'événement (ISO 8601) |
| `shifts` | `array` | Tableau d'objets `Shift` |
| `addons` | `object` | Services additionnels |
| `total` | `number` | Coût total |
| `client_name` | `string` | Nom du contact client |
| `client_email` | `string` | Email du contact client |
| `client_phone` | `string` | Téléphone du contact client |
| `notes` | `string` | Notes additionnelles |
| `requested` | `number` | Nombre total de personnel demandé |
| `assigned_staff` | `array` | Tableau d'objets de personnel assigné |
#### Endpoints
- **`POST /events`**
- **SDK :** `base44.entities.Event.create(eventData)`
- **Utilisation :** `CreateEvent.jsx`, `QuickReorderModal.jsx`
- **Body :** Objet `Event` sans les champs communs.
- **Réponse :** Le nouvel objet `Event` créé.
- **`GET /events`**
- **SDK :** `base44.entities.Event.list(sort, limit)` et `.filter(query, sort, limit)`
- **Utilisation :** `Events.jsx`, `Dashboard.jsx`, `WorkforceShifts.jsx`, etc.
- **Paramètres de requête :**
- `sort` (ex: `-date` pour trier par date décroissante)
- `limit` (ex: `50`)
- Autres champs de l'entité pour le filtrage (ex: `status=Active`)
- **Réponse :** Tableau d'objets `Event`.
- **`PUT /events/{id}`**
- **SDK :** `base44.entities.Event.update(id, data)`
- **Utilisation :** `EditEvent.jsx`, `QuickAssignPopover.jsx`
- **Body :** Un objet avec les champs de `Event` à mettre à jour.
- **Réponse :** L'objet `Event` mis à jour.
### 2.2. Staff
### 2.2. Staff (`/staff`)
**Description :** Gère les membres du personnel.
#### Schéma `Staff`
| Champ | Type | Description |
| ------------------------- | --------- | ----------------------------------------- |
| `employee_name` | `string` | Nom complet (requis) |
| `vendor_id` | `string` | ID du fournisseur (`Vendor`) |
| `vendor_name` | `string` | Nom du fournisseur |
| `manager` | `string` | Nom du manager |
| `contact_number` | `string` | Numéro de contact principal |
| `phone` | `string` | Autre téléphone |
| `email` | `string` | Adresse email |
| `department` | `string` | `Operations`, `Sales`, `HR`, etc. |
| `hub_location` | `string` | Lieu/hub de rattachement |
| `address` | `string` | Adresse de l'employé |
| `city` | `string` | Ville |
| `position` | `string` | Poste/compétence principal(e) |
| `position_2` | `string` | Poste/compétence secondaire |
| `profile_type` | `string` | `Skilled`, `Beginner`, `Cross-Trained` |
| `employment_type` | `string` | `Full Time`, `Part Time`, `On call`, etc. |
| `english` | `string` | `Fluent`, `Intermediate`, `Basic`, `None` |
| `rating` | `number` | Note de performance (0-5) |
| `shift_coverage_percentage`| `number` | Pourcentage de shifts couverts (0-100) |
| `cancellation_count` | `number` | Nombre d'annulations |
| `no_show_count` | `number` | Nombre de non-présentations |
| `total_shifts` | `number` | Nombre total de shifts assignés |
| `reliability_score` | `number` | Score de fiabilité (0-100) |
| `background_check_status` | `string` | `pending`, `cleared`, `failed`, `expired` |
| `background_check_date` | `string` | Date du dernier contrôle (ISO 8601) |
| `certifications` | `array` | Liste des certifications |
### 2.3. Vendor (`/vendors`)
**Description :** Gère les fournisseurs et leur onboarding.
| Champ | Type | Description |
| ------------------------- | -------- | ----------------------------------------- |
| `employee_name` | `string` | Requis. Nom de l'employé. |
| `vendor_id` | `string` | Fournisseur auquel l'employé est rattaché. |
| `rating` | `number` | Note de 0 à 5. |
| `shift_coverage_percentage` | `number` | Pourcentage de shifts couverts. |
| `background_check_status` | `string` | Enum: `pending`, `cleared`, `failed`, `expired` |
| ----------------------- | --------- | ----------------------------------------- |
| `vendor_number` | `string` | Numéro de fournisseur (ex: `VN-####`) |
| `legal_name` | `string` | Nom légal de l'entreprise (requis) |
| `doing_business_as` | `string` | Nom commercial (DBA) |
| `region` | `string` | `National`, `Bay Area`, etc. |
| `primary_contact_email` | `string` | Email du contact principal (requis) |
| `approval_status` | `string` | `pending`, `approved`, `suspended`, `terminated` |
| `is_active` | `boolean` | Statut d'activité |
| `tax_id` | `string` | Numéro d'identification fiscale (EIN) |
| `business_type` | `string` | `Corporation`, `LLC`, etc. |
| `insurance_certificate` | `string` | URL du certificat d'assurance |
| `insurance_expiry` | `string` | Date d'expiration de l'assurance (ISO 8601) |
| `w9_document` | `string` | URL du document W9 |
| `coi_document` | `string` | URL du document COI |
#### Endpoints
### 2.4. VendorRate (`/vendor-rates`)
- **`POST /staff`**
- **SDK :** `base44.entities.Staff.create(staffData)`
- **Utilisation :** `AddStaff.jsx`
- **Body :** Objet `Staff` sans les champs communs.
- **Réponse :** Le nouvel objet `Staff` créé.
- **`GET /staff`**
- **SDK :** `base44.entities.Staff.list(sort, limit)`
- **Utilisation :** `StaffDirectory.jsx`, `Dashboard.jsx`, `Reports.jsx`, etc.
- **Paramètres de requête :** `sort`, `limit`, et autres champs pour le filtrage.
- **Réponse :** Tableau d'objets `Staff`.
- **`PUT /staff/{id}`**
- **SDK :** `base44.entities.Staff.update(id, data)`
- **Utilisation :** `EditStaff.jsx`
- **Body :** Un objet avec les champs de `Staff` à mettre à jour.
- **Réponse :** L'objet `Staff` mis à jour.
### 2.3. Vendor
**Description :** Gère les fournisseurs de services.
#### Schéma `Vendor`
**Description :** Gère les grilles tarifaires des fournisseurs.
| Champ | Type | Description |
| --------------- | --------- | ----------------------------------------- |
| `vendor_number` | `string` | Format: `VN-####` |
| `legal_name` | `string` | Requis. Nom légal. |
| `approval_status` | `string` | Enum: `pending`, `approved`, `suspended`, `terminated` |
| `is_active` | `boolean` | Statut d'activité. |
| ----------------- | --------- | ----------------------------------------- |
| `vendor_id` | `string` | ID du fournisseur (`Vendor`) |
| `vendor_name` | `string` | Nom du fournisseur (requis) |
| `category` | `string` | Catégorie de service (`Kitchen`, etc.) |
| `role_name` | `string` | Nom du poste (requis) |
| `employee_wage` | `number` | Salaire horaire de l'employé (requis) |
| `client_rate` | `number` | Tarif horaire facturé au client (requis) |
| `pricing_status` | `string` | `optimal`, `underpriced`, `overpriced` |
| `is_active` | `boolean` | Statut d'activité |
#### Endpoints
### 2.5. Invoice (`/invoices`)
- **`POST /vendors`**
- **SDK :** `base44.entities.Vendor.create(data)`
- **Utilisation :** `VendorOnboarding.jsx`, `SmartVendorOnboarding.jsx`
- **Body :** Objet `Vendor`.
- **Réponse :** Le nouvel objet `Vendor` créé.
**Description :** Gère les factures.
- **`GET /vendors`**
- **SDK :** `base44.entities.Vendor.list()` et `.filter()`
- **Utilisation :** `VendorManagement.jsx`
- **Paramètres de requête :** `sort`, `limit`, `approval_status`, etc.
- **Réponse :** Tableau d'objets `Vendor`.
| Champ | Type | Description |
| ---------------- | -------- | ----------------------------------------- |
| `invoice_number` | `string` | Numéro de facture (requis) |
| `event_id` | `string` | ID de l'événement (`Event`) |
| `business_name` | `string` | Nom du client (requis) |
| `vendor_name` | `string` | Nom du fournisseur |
| `amount` | `number` | Montant de la facture (requis) |
| `status` | `string` | `Open`, `Paid`, `Overdue`, `Disputed`, etc. |
| `issue_date` | `string` | Date d'émission (ISO 8601, requis) |
| `due_date` | `string` | Date d'échéance (ISO 8601, requis) |
| `paid_date` | `string` | Date de paiement (ISO 8601) |
- **`PUT /vendors/{id}`**
- **SDK :** `base44.entities.Vendor.update(id, data)`
- **Utilisation :** `EditVendor.jsx`, `VendorManagement.jsx`
- **Body :** Champs de `Vendor` à mettre à jour.
- **Réponse :** L'objet `Vendor` mis à jour.
### 2.6. Business (`/businesses`)
**Description :** Gère les entreprises clientes.
| Champ | Type | Description |
| -------------- | -------- | ----------------------------------------- |
| `business_name`| `string` | Nom de l'entreprise (requis) |
| `contact_name` | `string` | Nom du contact principal (requis) |
| `email` | `string` | Email de l'entreprise |
| `phone` | `string` | Téléphone de l'entreprise |
| `sector` | `string` | `Bon Appétit`, `Eurest`, etc. |
| `rate_group` | `string` | `Standard`, `Premium`, etc. (requis) |
| `status` | `string` | `Active`, `Inactive`, `Pending` |
---
### 2.4. Autres Entités Majeures (Structure Similaire)
La même structure d'endpoints (POST, GET, PUT) doit être créée pour les entités suivantes, en se basant sur les schémas à obtenir et l'utilisation observée dans le code :
- **`VendorRate`**: Gère les tarifs des fournisseurs.
- **`Business`**: Gère les clients.
- **`Invoice`**: Gère les factures.
- **`Team`, `TeamMember`, `TeamMemberInvite`**: Gère les équipes et les invitations.
- **`ActivityLog`**: Gère les notifications et les journaux d'activité.
- **`Certification`**: Gère les certifications du personnel.
- **`Enterprise`, `Sector`, `Partner`**: Gèrent la hiérarchie organisationnelle.
- **`Conversation`, `Message`**: Gèrent la messagerie interne.
- ... et toutes les autres entités listées dans `api/entities.js`.
*Note : Pour la concision, seules les entités les plus critiques ont été entièrement détaillées. La même structure (Schéma + Endpoints) doit être appliquée pour : `Certification`, `Team`, `Conversation`, `Message`, `ActivityLog`, `Enterprise`, `Sector`, `Partner`, `Order`, et `Shift` en se basant sur `API_documentation.md`.*
---
## 3. Services d'Intégration
Ces endpoints ne sont pas des CRUDs mais des appels à des services spécifiques.
### `POST /integrations/invoke-llm`
- **Description :** Fait appel à un modèle de langage (Vertex AI).
- **SDK d'origine :** `base44.integrations.Core.InvokeLLM(params)`
- **Body :** `{ "prompt": "...", "response_json_schema": {...}, "file_urls": [...] }`
- **Réponse (200 OK) :** `{ "result": "..." }`
### `POST /integrations/send-email`
- **Description :** Envoie un email.
- **SDK :** `base44.integrations.Core.SendEmail(params)`
- **Utilisation :** `InviteVendor.jsx`, `TeamDetails.jsx`, etc.
- **Body :**
```json
{
"to": "recipient@example.com",
"subject": "Sujet de l'email",
"body": "<h1>Contenu HTML</h1>"
}
```
- **SDK d'origine :** `base44.integrations.Core.SendEmail(params)`
- **Body :** `{ "to": "...", "subject": "...", "body": "..." }`
- **Réponse (200 OK) :** `{ "status": "sent" }`
### `POST /integrations/upload-file`
- **Description :** Gère le téléversement de fichiers vers Google Cloud Storage.
- **SDK :** `base44.integrations.Core.UploadFile({ file })`
- **Utilisation :** `WorkforceProfile.jsx`, `VendorOnboarding.jsx`, etc.
- **Requête :** Doit être une requête `multipart/form-data`.
- **Réponse (200 OK) :**
```json
{
"file_url": "https://storage.googleapis.com/..."
}
```
- **Description :** Gère le téléversement de fichiers publics vers Google Cloud Storage.
- **SDK d'origine :** `base44.integrations.Core.UploadFile({ file })`
- **Requête :** `multipart/form-data`.
- **Réponse (200 OK) :** `{ "file_url": "https://..." }`
### `POST /integrations/invoke-llm`
- **Description :** Fait appel à un modèle de langage (Vertex AI).
- **SDK :** `base44.integrations.Core.InvokeLLM({ prompt })`
- **Utilisation :** `SmartVendorOnboarding.jsx`, `VendorCompliance.jsx`
- **Body :**
```json
{
"prompt": "Analyse ce document et extrais les informations suivantes...",
"context": "..." // Contexte additionnel
}
```
- **Réponse (200 OK) :**
```json
{
"result": "Texte ou JSON généré par le LLM"
}
```
### `POST /integrations/upload-private-file`
- **Description :** Gère le téléversement de fichiers privés vers Google Cloud Storage.
- **SDK d'origine :** `base44.integrations.Core.UploadPrivateFile({ file })`
- **Requête :** `multipart/form-data`.
- **Réponse (200 OK) :** `{ "file_uri": "gs://..." }`
### `POST /integrations/create-signed-url`
- **Description :** Crée une URL d'accès temporaire pour un fichier privé.
- **SDK d'origine :** `base44.integrations.Core.CreateFileSignedUrl(params)`
- **Body :** `{ "file_uri": "...", "expires_in": 3600 }`
- **Réponse (200 OK) :** `{ "signed_url": "https://..." }`
### `POST /integrations/extract-data`
- **Description :** Extrait des données structurées d'un fichier (CSV, PDF...).
- **SDK d'origine :** `base44.integrations.Core.ExtractDataFromUploadedFile(params)`
- **Body :** `{ "file_url": "...", "json_schema": {...} }`
- **Réponse (200 OK) :** `{ "status": "success", "output": [...] }`
### `POST /integrations/generate-image`
- **Description :** Génère une image via une IA.
- **SDK d'origine :** `base44.integrations.Core.GenerateImage(params)`
- **Body :** `{ "prompt": "..." }`
- **Réponse (200 OK) :** `{ "url": "https://..." }`

55
docs/base44_prompts.md Normal file
View File

@@ -0,0 +1,55 @@
# Prompts pour l'IA de Base44
Ce fichier contient des prompts standardisés à utiliser avec l'intelligence artificielle de la plateforme Base44. L'objectif est d'obtenir des informations précises et bien structurées sur l'API et les schémas de données du projet "KROW Workforce" afin de faciliter la construction d'intégrations et, si nécessaire, la migration future.
## 1. Prompt Principal : Demande de Documentation Complète (Version Discrète et Itérative)
*Utilisez ce prompt après chaque nouvel export du frontend depuis Base44. Il est formulé pour ne pas révéler l'intention de migration en demandant une mise à jour d'un document existant.*
---
```text
Hello!
I am the lead developer for the "KROW Workforce" project. We are looking to deeply integrate the Base44 platform into our wider ecosystem by building several custom tools and automations.
Previously, you generated an `API_documentation.md` file that was incredibly helpful for our team. To ensure our new integration projects are built using the most current project state, could you please refresh and exhaustively update this `API_documentation.md` file?
Please conduct a full review of our project and ensure the updated documentation includes the following for **all current entities** (Events, Staff, Vendors, Invoices, Users, Teams, etc.):
1. **Entity Data Schemas**: For each entity, a detailed breakdown of its fields in a table or JSON Schema format, including:
* `Field Name`
* `Data Type` (e.g., `string`, `number`, `timestamp`)
* `Description` of the field's purpose.
* `Validation Rules` (e.g., `required`, `unique`, `enum` values).
2. **SDK Operations**: A complete list of all available SDK methods for each entity (e.g., `.list()`, `.filter()`, `.create()`, `.update()`).
3. **Integrations API**: The full specification for all services under `base44.integrations.Core` (`SendEmail`, `InvokeLLM`, etc.), including their input parameters and output structure.
After you have updated the file, please output the **entire, updated content** of `API_documentation.md` in your response. This will serve as the single source of truth for our development team.
**IMPORTANT: Please ensure you output the ENTIRE, updated content of `API_documentation.md` directly in your response, not just a summary.**
Thank you!
```
---
## 2. Prompt Secondaire : Demande de Schéma pour une Entité Spécifique
*Utilisez ce prompt si vous avez besoin de vérifier rapidement la structure d'une seule entité sans demander la documentation complète.*
---
```text
Hello!
For the "KROW Workforce" project, could you please provide the detailed data schema for the **[ENTITY_NAME]** entity?
Please format the response as a JSON Schema or a Markdown table, including the field names, data types, a description of each field, and any validation rules (like `required` fields or `enum` values).
For example, for an entity named `Event`.
```
---