Comment consulter les budgets d'une copropriété, faire voter une version, puis en dériver un plan de financement (échéancier) et ses appels de fonds.
Tous les appels de ce guide sont adressés à une copropriété précise (idCopro) : c'est le périmètre racine de chaque route. À l'intérieur de ce périmètre, deux notions structurent le sujet :
Une version chiffrée du budget d'un exercice et d'un type de poste donné. Un exercice peut porter plusieurs versions successives (brouillons, corrections, version votée) — voir Parcours A.
estLastBudget indique si cette version est la plus récente pour son exercice et son type, indépendamment de son statut de vote — voir Parcours A.
Un montant affecté à un poste comptable, à l'intérieur d'un budget.
* présents uniquement sur la route qui expose le réalisé — voir Parcours A.
Le calendrier d'appels de fonds calculé pour un budget voté. Un seul échéancier existe par (exercice ou travaux, type de poste) — voir Parcours D.
* présents seulement quand la route consultée détaille l'échéancier (pas sur un appel de liste allégé).
Une ligne du calendrier : soit un appel de fonds, soit une affectation d'un paiement déjà reçu.
compte identifie le compte bancaire visé par un appel de fonds (non applicable à une affectation) ; source identifie l'origine du paiement pour une affectation (non applicable à un appel). * présents uniquement en consultation détaillée d'une échéance précise — voir Parcours F.
Chaque appel nécessite un jeton d'accès OAuth2, et le client doit être explicitement autorisé sur la copropriété visée par idCopro : toute tentative sur un périmètre non autorisé renvoie 403 Forbidden, qu'il s'agisse d'un budget, d'un échéancier ou d'une échéance. Il n'y a pas de restriction supplémentaire propre à ces deux entités au-delà de ce contrôle de périmètre.
access_token=…) plutôt qu'en en-tête Authorization: Bearer — cette dernière forme est rejetée. Toutes les routes de ce guide sont préfixées /v2 et servies depuis https://syndic.datacopro.org en production, ou https://preprod-syndic.datacopro.org sur la plateforme de test — par exemple GET https://syndic.datacopro.org/v2/copro/{idCopro}/echeancier en production.
Ces six parcours suivent le cycle de vie réel d'un budget : de sa consultation à son vote, puis du plan de financement qui en découle jusqu'à la gestion de chaque échéance individuelle.
Cas d'usage : afficher l'état budgétaire courant d'une copropriété, avec ou sans le détail des montants déjà réalisés.
Renvoie toutes les versions de budget existantes pour cet exercice et ce type de poste — brouillons compris.
Ne renvoie que la version la plus récente, votée ou non. idAssociation est l'identifiant de l'exercice (ou de l'opération de travaux pour ce type de poste).
Réservé aux charges courantes : renvoie la version votée en ajoutant, sur chaque ligne, les montants effectivement réalisés (montantRealise, tva) — des champs absents des deux appels précédents.
La même version votée que ci-dessus, mais sans les montants réalisés — également réservé aux charges courantes. Pour les autres types de poste, l'équivalent « version votée uniquement » est exposé par une route dédiée par poste (voir la référence des endpoints) plutôt que par cette route générique.
budgets/{type} ni last-budget ne filtrent sur le statut de vote : les deux renvoient des brouillons aussi bien que des versions votées, et aucun des deux ne renvoie montantRealise. Un intégrateur qui veut la version de référence pour la comptabilité doit soit lire le champ estVote sur les éléments renvoyés par ces deux appels, soit interroger directement une route « vote » dédiée.
Cas d'usage : saisir un projet de budget avant qu'il ne soit soumis au vote de l'assemblée générale.
{
"groupeBudgetExercice": {
"isVote": 0,
"note": "Projet soumis à l'AG du 14/03",
"budgets": [
{ "cle": 4821, "type": 9012, "montant": 128000 },
{ "planComptable": 55310, "montant": 42500 }
]
}
}
Chaque ligne de budgets désigne un poste soit par la paire cle (clé de répartition) + type (poste comptable générique), soit directement par un planComptable existant de la copropriété. Les montants s'expriment en centimes.
version envoyé dans la requête est ignoré.
POST crée une version complète et indépendante. Modifier une ligne signifie renvoyer l'intégralité des lignes du budget dans une nouvelle version. Les lignes envoyées à montant nul sont silencieusement ignorées — elles ne créent pas de ligne à zéro.
Cas d'usage : entériner la version soumise à l'assemblée générale comme référence officielle de l'exercice.
Marque la version la plus récente comme votée et enregistre sa date de vote. Le vote est un appel séparé de la création : il n'existe pas de paramètre « voter » à passer directement dans le POST du Parcours B.
Cas d'usage : une fois le budget voté, produire le calendrier d'appels de fonds envoyé aux copropriétaires.
{
"echeancier": {
"type": 4110,
"exercice": 3305,
"calculer": 1,
"echeances": [
{ "numero": 1, "type": "appel", "date": "2026-01-05 00:00:00", "part": 1, "libelle": "1er appel" },
{ "numero": 2, "type": "appel", "date": "2026-04-05 00:00:00", "part": 1, "libelle": "2e appel" }
]
}
}
Le type de l'échéancier (ici 4110) est un code de calendrier propre à la comptabilité de la copropriété : ce n'est pas le même espace de valeurs que le type de poste utilisé comme paramètre de chemin dans les routes de budget (Parcours A/B). Chaque échéance porte en plus un numero d'ordre, un type (appel de fonds, ou affectation d'un paiement déjà reçu), une date et une part — le poids relatif de cette échéance parmi les échéances de même type : des parts égales répartissent le montant total à parts égales entre elles, des parts inégales le répartissent proportionnellement. Au moins une échéance est obligatoire.
calculer: 1 déclenche un calcul réellement effectué côté serveur : l'API répartit elle-même chaque échéance entre les lots de la copropriété selon les clés de répartition en vigueur. Il n'est pas nécessaire — ni possible — de soumettre une répartition par lot déjà calculée dans cette requête.
400. Passé ce point, tout ajustement se fait par modification (Parcours E), jamais par une nouvelle création. La création échoue également en 400 s'il n'existe pas de budget voté avec au moins une ligne non nulle pour ce type.
Cas d'usage : ajuster le calendrier après une correction budgétaire votée en cours d'exercice.
Accepte le même format de corps que la création. La liste d'échéances soumise remplace la définition du plan, mais pas de façon purement destructrice.
Cas d'usage : consulter le détail d'un appel de fonds précis, ajouter un appel isolé sans passer par un échéancier complet, ou revenir sur une échéance saisie par erreur.
Ajoute un appel de fonds ponctuel, indépendamment de tout échéancier — utile pour un appel exceptionnel qui ne doit pas modifier le plan de financement existant.
Seule route à renvoyer details, documentsAppels et jeuxDecritures — la liste des écritures comptables déjà générées à partir de cette échéance.
400) dès que son exercice est clôturé. Supprimer une échéance déjà appelée exige en plus de passer explicitement un indicateur de confirmation dans la requête — une suppression « silencieuse » d'un appel déjà envoyé n'est jamais le comportement par défaut.
| Méthode | Route | Rôle |
|---|---|---|
| GET | /v2/copro/{idCopro}/exercice/{idExercice}/budgets/{type} | Toutes les versions de budget d'un exercice et d'un type de poste |
| POST | /v2/copro/{idCopro}/exercice/{idExercice}/budget/{type} | Crée une nouvelle version de budget |
| GET | /v2/copro/{idCopro}/last-budget/{type}/{idAssociation} | Dernière version de budget, votée ou non |
| PUT | /v2/copro/{idCopro}/last-budget/{type}/{idAssociation}/voter | Marque la dernière version comme votée |
| DELETE | /v2/copro/{idCopro}/budget/{idGroupeBudget} | Supprime une version de budget (refusé si un échéancier y est lié) |
| GET | /v2/copro/{idCopro}/exercice/{idExercice}/budget-vote-et-realise | Budget voté des charges courantes, avec montants réalisés |
| GET | /v2/copro/{idCopro}/exercice/{idExercice}/budget-vote | Budget voté des charges courantes, sans le réalisé |
| GET | /v2/copro/{idCopro}/exercice/{idExercice}/budget-a-voter | Dernière version non encore votée |
| GET | /v2/copro/{idCopro}/exercice/{idExercice}/budget-avances-de-tresorerie | Budget voté du poste avance de trésorerie / fonds de roulement |
| GET | /v2/copro/{idCopro}/exercice/{idExercice}/budget-fonds-travaux | Budget voté du poste fonds de travaux / fonds de réserve |
| GET | /v2/copro/{idCopro}/exercice/{idExercice}/budget-avances-travaux | Budget voté du poste avances sur travaux (obsolète) |
| GET | /v2/copro/{idCopro}/exercice/{idExercice}/budget-autres-avances | Budget voté du poste autres avances |
| POST | /v2/copro/{idCopro}/echeancier | Crée un échéancier sur un budget voté |
| PUT | /v2/copro/{idCopro}/echeancier/{idEcheancier} | Modifie un échéancier existant |
| GET | /v2/copro/{idCopro}/echeanciers | Liste les échéanciers de la copropriété |
| GET | /v2/copro/{idCopro}/echeancier/{idEcheancier} | Détail d'un échéancier, échéances comprises |
| DELETE | /v2/copro/{idCopro}/echeancier/{idEcheancier} | Supprime un échéancier |
| GET | /v2/copro/{idCopro}/echeance/{idEcheance} | Détail complet d'une échéance (pièces jointes, écritures) |
| POST | /v2/copro/{idCopro}/echeance/{typeEcheance} | Ajoute un appel de fonds isolé, hors échéancier complet |
| POST | /v2/copro/{idCopro}/echeance/{idEcheance}/annuler | Annule une échéance |
| DELETE | /v2/copro/{idCopro}/echeance/{idEcheance} | Supprime une échéance |
| POST / GET / DEL | /v2/copro/{idCopro}/echeance/{idEcheance}/document(s)[/{idDocument}] | Pièces jointes d'une échéance |
Toutes ces routes attendent une extension de format explicite en fin de chemin (par exemple .json).
Les routes de liste (échéanciers, budgets) acceptent trois familles de paramètres de requête génériques, communs à l'ensemble de l'API :
filters — restreint les résultats. Syntaxe par champ avec opérateur préfixé, par exemple filters[exercice.id]==3305 pour ne récupérer que les échéanciers d'un exercice donné.sorts / pagination — ordonnancement et découpage en pages des listes.displays — restreint ou ouvre l'ensemble des champs renvoyés, parmi ceux déjà présents dans la réponse de la route appelée.displays ne permet pas de « débloquer » un champ qui n'appartient pas à l'ensemble déjà exposé par la route choisie. Concrètement, il est impossible de demander montantRealise via displays sur l'appel générique GET .../budgets/{type} (Parcours A) : ce champ n'existe que dans la réponse de budget-vote-et-realise. De même, details ou jeuxDecritures sur une échéance ne sont disponibles qu'en consultant l'échéance individuellement (Parcours F), jamais via displays sur une liste d'échéanciers. Le bon réflexe est de choisir la route qui expose nativement le champ recherché, plutôt que de chercher à l'obtenir par ce paramètre.
calculer: 1 — elle ne s'envoie pas précalculée (Parcours D).DELETE .../budget/{id}).displays ne fait que filtrer les champs déjà exposés par la route appelée — il n'ouvre jamais l'accès à un champ propre à une autre route (Paramètres transverses).montantRealise est présent, indépendamment du statut de vote. Les routes génériques de consultation (budgets/{type}, last-budget) renvoient du prévisionnel — voté ou non, à vérifier via estVote — mais jamais de réalisé. Seule la route dédiée au réalisé des charges courantes (budget-vote-et-realise) ajoute montantRealise à chaque ligne, et uniquement sur la version votée. Parcours A · Modèle & périmètrecalculer ne sert pas à activer un calcul optionnel côté client, il déclenche le calcul réel effectué par le serveur à partir des clés de répartition de la copropriété. Il n'existe pas de mode où l'appelant fournirait sa propre répartition ligne par lot dans la requête de création ou de modification. Parcours D