Exclusions de règles bancaires
Une exclusion (bank_rule_exclusion) retire une entreprise du champ d'une règle de workspace. C'est la soupape de la portée workspace : une règle qui convient à toutes les entreprises sauf deux n'a pas besoin d'être dupliquée, il suffit d'exclure ces deux-là.
Les règles elles-mêmes, leur vocabulaire de conditions et leur simulation sont décrits sur leur propre page (Règles d'imputation bancaires).
Seule une règle de workspace peut être exclue
Une règle société ne peut jamais faire l'objet d'une exclusion. Elle ne concerne déjà qu'une seule entreprise, donc l'exclure de cette entreprise serait soit sans effet, soit une contradiction. La tentative est refusée en 422, elle n'est pas silencieusement ignorée. C'est aussi pour cela que l'excluded_company_ids d'une règle société est toujours vide : le tableau vide y est la vraie réponse, pas un remplissage.
L'entreprise que vous excluez doit appartenir au workspace de la règle. Une entreprise d'un autre workspace et une entreprise qui n'existe pas reçoivent la même réponse, de sorte que cet endpoint ne permet pas de sonder l'existence d'une entreprise.
Retirer une exclusion remet la règle de workspace en vigueur pour cette entreprise à partir du classement suivant. Ni la pose ni le retrait ne réécrivent quoi que ce soit de déjà comptabilisé : une exclusion ne possède ni écriture comptable ni paiement.
Les endpoints
GET /api/v1/bank_rules/{bank_rule_id}/exclusions- lister les exclusions d'une règlePOST /api/v1/bank_rules/{bank_rule_id}/exclusions- exclure une entreprise d'une règleDELETE /api/v1/bank_rule_exclusions/{id}- retirer une exclusion
Deux formes de chemin, et ce n'est pas une incohérence. La liste et la création sont la collection de la règle, donc elles pendent à la règle. Le retrait est adressé par l'identifiant propre de l'exclusion, sur un chemin qui ne porte ni la règle ni l'entreprise - c'est le workspace_id publié sur l'exclusion qui l'autorise. Aucun des trois chemins ne porte de workspace_id : il est déduit de la règle pour les deux premiers, de l'exclusion pour le troisième.
La lecture demande le scope read, la création le scope write, le retrait le scope destroy ou write. L'en-tête Idempotency-Key est accepté et facultatif sur les deux écritures.
Les champs d'une exclusion
Six champs, tous présents dans chaque réponse. Il n'y a rien de plus à lire : c'est la règle qui porte la vue d'ensemble.
| Champ | Ce qu'il porte |
|---|---|
id | L'identifiant de l'exclusion, celui que porte DELETE /api/v1/bank_rule_exclusions/{id} |
workspace_id | Le workspace auquel l'exclusion appartient |
bank_rule_id | La règle de workspace dont cette entreprise est retirée |
company_id | L'entreprise retirée. Elle appartient au workspace de la règle |
created_at, updated_at | Horodatages ISO 8601 |
Le même ensemble est publié sur la règle, sous excluded_company_ids, et c'est souvent tout ce dont vous avez besoin. Cette ressource sert quand il vous faut l'identifiant propre de chaque exclusion pour pouvoir la retirer.
Exclure une entreprise
curl -X POST https://app.scribee.tech/api/v1/bank_rules/88/exclusions \
-H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
-H "Content-Type: application/json" \
-H "Idempotency-Key: b3d7e510-2c48-4a9f-8e61-70f4a2c9d183" \
-d '{ "company_id": 34 }'
{
"data": {
"id": 410,
"workspace_id": 12,
"bank_rule_id": 88,
"company_id": 34,
"created_at": "2026-08-21T15:10:00+02:00",
"updated_at": "2026-08-21T15:10:00+02:00"
}
}
company_id est le seul champ du corps, et il est obligatoire. Un corps qui n'en porte aucun est refusé en 422 avec le code validation_failed, en nommant company.
Sur une règle société, le refus nomme la règle et porte le remède :
{
"error": "unprocessable_entity",
"code": "validation_failed",
"message": "La validation a échoué",
"details": {
"rule": ["est une règle de société : elle ne concerne déjà qu'une seule société et ne peut pas faire l'objet d'une exclusion"]
}
}
Une entreprise hors du workspace de la règle - ou qui n'existe nulle part - porte un code différent, parce que ce n'est pas la règle qui est en cause mais la valeur du champ :
{
"error": "unprocessable_entity",
"code": "invalid_argument",
"message": "La validation a échoué",
"details": {
"company": ["est introuvable dans l'espace de travail de cette règle"]
}
}
Une entreprise déjà exclue de cette règle est refusée en 422 avec le code validation_failed, en nommant company : poser deux fois la même exclusion ne produit pas de doublon.
Lister les exclusions d'une règle
curl "https://app.scribee.tech/api/v1/bank_rules/88/exclusions?company_id=34" \
-H "Authorization: Bearer YOUR_ACCESS_TOKEN"
{
"data": [
{
"id": 410,
"workspace_id": 12,
"bank_rule_id": 88,
"company_id": 34,
"created_at": "2026-08-21T15:10:00+02:00",
"updated_at": "2026-08-21T15:10:00+02:00"
}
],
"meta": {
"current_page": 1,
"per_page": 20,
"total_pages": 1,
"total_count": 1
}
}
La liste est rendue par company_id croissant puis par id croissant, et l'enveloppe data + meta suit Conventions de l'API. La pagination est par décalage, avec page et per_page - 20 par défaut, 100 au maximum.
company_id est le seul filtre, facultatif, et il attend un entier. Une valeur qui n'est pas un entier ne remonte rien - un 200 avec une collection vide, jamais un 422. Un paramètre absent ou vide n'est pas un filtre : il ne restreint rien.
Le même appel sur une règle société répond un 200 avec une collection vide, puisqu'une telle règle ne peut porter aucune exclusion.
Retirer une exclusion
curl -X DELETE https://app.scribee.tech/api/v1/bank_rule_exclusions/410 \
-H "Authorization: Bearer YOUR_ACCESS_TOKEN"
{
"data": {
"id": 410,
"workspace_id": 12,
"bank_rule_id": 88,
"company_id": 34,
"created_at": "2026-08-21T15:10:00+02:00",
"updated_at": "2026-08-21T15:10:00+02:00"
}
}
Le corps de la réponse est l'exclusion telle qu'elle était au moment où vous en avez demandé le retrait. À partir du classement suivant, la règle de workspace redevient candidate pour les opérations de cette entreprise.
Les erreurs
| Statut | error | code | Quand |
|---|---|---|---|
400 | bad_request | - | Un page qui n'est pas un entier supérieur ou égal à 1, ou une page au-delà de la dernière page d'une collection non vide |
403 | forbidden | - | Votre client OAuth n'a pas d'habilitation sur le workspace concerné, ou le token ne porte pas le scope requis |
404 | not_found | - | La règle ou l'exclusion n'est pas atteignable par vos habilitations |
409 | - | idempotency_key_reuse | La même Idempotency-Key a déjà servi pour un corps différent |
409 | - | idempotency_request_in_progress | Un appel antérieur portant cette clé est encore en cours |
422 | unprocessable_entity | validation_failed | La règle visée est une règle société, l'entreprise est déjà exclue, ou le corps ne porte pas de company_id |
422 | unprocessable_entity | invalid_argument | Le company_id n'est pas une entreprise du workspace de la règle |
Une ressource hors de portée répond 404, jamais 403. L'atteignabilité est tranchée avant la question des droits : une exclusion d'un workspace que vos habilitations ne couvrent pas et une exclusion qui n'existe pas reçoivent la même réponse. C'est d'autant plus important sur DELETE /api/v1/bank_rule_exclusions/{id}, dont le chemin ne porte ni la règle ni l'entreprise.