API REST - Vue d'ensemble
L'API EFact est une API REST versionnée. Toutes les réponses sont au format JSON, enveloppées dans un format unique.
En bref
L'API EFact est une API REST JSON utilisable depuis tout langage. Une facture suit le cycle PENDING, NORMALIZING, SIGNING, SUBMITTED, puis un statut final ACCEPTED, REJECTED ou FAILED. Les erreurs renvoient des codes HTTP standard et un corps JSON structuré.
Base URL
| Environnement | URL |
|---|---|
| Production | https://api.efact.ma |
Versioning
L'API est versionnée via le préfixe d'URL. La version courante est v1 .
/v1/invoicesAuthentification
Toutes les requêtes doivent inclure la clé API secrète dans le header Authorization :
Authorization: Bearer efact_sk_xxxLa clé identifie votre organisation côté serveur : aucun identifiant d'organisation ne transite dans vos requêtes. Voir Authentification pour le détail complet.
Format des requêtes
- Content-Type :
application/json - Encoding : UTF-8
- Montants : nombres décimaux dans la devise de la facture - ex :
150.00= 150,00 DH. Les totaux (HT, TVA, TTC) sont calculés côté serveur à partir des lignes. - Dates de facture : format
YYYY-MM-DD(ex :2026-04-07) ; les horodatages retournés sont en ISO 8601 UTC - IDs : UUIDs
Format des réponses
Chaque réponse, succès ou erreur, utilise la même enveloppe { code, message, data, errors }. Les SDK officiels déballent data automatiquement et lèvent une erreur typée sinon.
Succès
{
"code": "OK",
"message": "Invoice created",
"data": {
"id": "550e8400-e29b-41d4-a716-446655440000",
"invoiceNumber": "INV-2026-042",
"status": "SIGNED",
"currency": "MAD",
"amountHt": 12000.00,
"amountVat": 2400.00,
"amountTtc": 14400.00,
"createdAt": "2026-04-07T10:00:00Z"
},
"errors": null
}Erreur
{
"code": "VALIDATION_ERROR",
"message": "Validation failed",
"data": null,
"errors": [
{
"field": "buyerIce",
"message": "buyerIce must be exactly 15 digits"
}
]
}Codes de statut HTTP
| Code | Signification |
|---|---|
200 OK | Requête réussie (GET, PUT, DELETE) |
201 Created | Ressource créée avec succès (POST) |
400 Bad Request | Payload invalide ou champ manquant (détail champ par champ dans errors) |
401 Unauthorized | Clé API manquante, invalide ou révoquée |
404 Not Found | Ressource introuvable (ou n'appartenant pas à votre organisation) |
409 Conflict | Conflit d'état : numéro de facture déjà utilisé, ou modification d'une facture déjà signée |
429 Too Many Requests | Rate limiting dépassé - respecter le header Retry-After |
500 Internal Server Error | Erreur côté EFact - support à contacter |
Codes d'erreur métier
Le champ codede l'enveloppe porte un code stable, exploitable par programme. Les principaux :
| Code | HTTP | Description |
|---|---|---|
API_KEY_MISSING | 401 | Header Authorization absent ou vide |
API_KEY_INVALID | 401 | Clé API non reconnue ou révoquée |
API_KEY_RATE_LIMITED | 429 | Limite de 300 requêtes/minute dépassée |
VALIDATION_ERROR | 400 | Champ manquant ou format invalide (détail dans errors[]) |
INVOICE_NOT_FOUND | 404 | Facture introuvable ou hors organisation |
INVOICE_NUMBER_EXISTS | 409 | Numéro de facture déjà utilisé dans votre organisation |
INVOICE_NOT_EDITABLE | 409 | Modification/annulation d'une facture qui n'est plus PENDING |
MISSING_LEGAL_MENTIONS | 409 | Mentions légales de l'organisation incomplètes (ICE, IF, RC...) - à compléter dans le dashboard avant de facturer |
Idempotence
L'idempotence de la création repose sur le invoiceNumber, unique par organisation :
// invoiceNumber est unique par organisation : rejouer la même
// création retourne 409 INVOICE_NUMBER_EXISTS au lieu de créer un doublon.
POST /v1/invoices
{ "invoiceNumber": "INV-2026-042", ... }En cas de doute après un timeout réseau, rejouez la création : soit elle réussit, soit vous recevez 409 INVOICE_NUMBER_EXISTS - la facture existe déjà et peut être retrouvée via la liste. Les SDK ne rejouent jamais un POST automatiquement.
Rate limiting
| Scope | Limite |
|---|---|
| Par clé API secrète | 300 requêtes / minute |
Au-delà, l'API retourne 429 avec un header Retry-After (en secondes). Les SDK officiels le respectent automatiquement avec un back-off exponentiel.
Pagination
Les endpoints de liste utilisent une pagination par page :
GET /v1/invoices?status=ACCEPTED&page=0&size=20&sort=createdAt,descParamètres
| Paramètre | Type | Description |
|---|---|---|
page | integer | Index de page, base 0 (défaut : 0) |
size | integer | Nombre de résultats par page (défaut : 20) |
sort | string | propriété,asc|desc (défaut : createdAt,desc) |
status | string | Filtre par statut (PENDING, ACCEPTED...) |
Réponse
{
"code": "OK",
"message": "Invoices retrieved",
"data": {
"content": [ ... ],
"page": 0,
"size": 20,
"totalElements": 42,
"totalPages": 3,
"first": true,
"last": false
},
"errors": null
}Endpoints disponibles
| Méthode | Endpoint | Description |
|---|---|---|
POST | /v1/invoices | Créer une facture (normalisée + signée à la volée) |
GET | /v1/invoices | Lister les factures de l'organisation |
GET | /v1/invoices/:id | Récupérer une facture |
GET | /v1/invoices/:id/status | Statut de clairance DGI (léger, conçu pour le polling) |
PUT | /v1/invoices/:id | Modifier une facture PENDING |
DELETE | /v1/invoices/:id | Annuler une facture PENDING |
GET | /v1/invoices/:id/pdf | Télécharger le PDF de la facture |
GET | /v1/invoices/:id/xml | Télécharger le XML UBL 2.1 signé (original légal) |
GET | /v1/invoices/:id/qr | Télécharger le QR code de clairance (PNG) |
Questions fréquentes
Quels sont les statuts possibles d'une facture EFact ?
Une facture suit le cycle PENDING, NORMALIZING, SIGNING, SUBMITTED, puis un statut final ACCEPTED, REJECTED ou FAILED. ACCEPTED signifie que la facture a reçu son visa fiscal ; REJECTED indique un refus DGI avec un motif ; FAILED signale une erreur technique. Chaque transition est journalisée pour la piste d'audit.
L'API EFact est-elle compatible avec tous les langages ?
Oui. L'API est une API REST JSON utilisable depuis tout langage capable d'émettre des requêtes HTTP. Le SDK officiel Node.js/TypeScript (@itzenata/efact-node) facilite l'intégration - les SDK Python, Java, PHP et .NET sont en cours de développement - mais il reste optionnel : vous pouvez appeler directement les points de terminaison HTTP.
Comment sont gérées les erreurs de l'API EFact ?
L'API renvoie des codes HTTP standard et un corps JSON structuré avec un code d'erreur et un message. Les erreurs de validation renvoient 400, l'authentification 401, une facture verrouillée 409 et le dépassement de quota 429. Les rejets DGI sont distincts et rattachés au statut REJECTED de la facture.