Yowyob Business Core
A YOWYOB SYSTEM / UN SYSTÈME YOWYOB
CONDITIONS GÉNÉRALES D’UTILISATION ET DE SERVICES
TERMS OF USE AND SERVICES
Plateforme API déclarative de gestion générique des cœurs de métier au-dessus du Yowyob Kernel
Declarative API platform for generic business-core management above the Yowyob Kernel
IMPORTANT / IMPORTANT — Business Core interprète et exécute des modèles métier déclarés par les organisations. Il ne valide pas automatiquement la légalité, l’exactitude, la sécurité sectorielle, la fiscalité ou l’adéquation opérationnelle de chaque métier configuré. / Business Core interprets and executes business models declared by organisations. It does not automatically validate the legality, accuracy, sector safety, tax treatment or operational suitability of each configured business.
Contrôle du document / Document control
Champ / Field
Valeur / Value
Statut / Status
Bêta publiée / Published Beta
Version
1.0
Date
29 juillet 2026 / 29 July 2026
Éditeur / Publisher
Yowyob Inc. Ltd
Système / System
Yowyob Business Core
Document
CGU / Terms of Use and Services
Périmètre du système / System scope
Portail public, documentation, console développeur, API REST, Swagger/OpenAPI, webhooks, applications Web/PWA/mobile intégrées, environnements de test et de production / Public portal, documentation, developer console, REST API, Swagger/OpenAPI, webhooks, integrated Web/PWA/mobile applications, test and production environments
Canal / Channel
Composants / Components
Portée / Scope
Web
Site public, tarifs, documentation, console, gestion des tenants et audit / Public site, pricing, documentation, console, tenant management and audit
Navigateurs desktop et mobiles / Desktop and mobile browsers
PWA / Mobile
Console installable ou fonctions embarquées dans les applications clientes / Installable console or functions embedded in customer applications
Selon activation et magasin / Subject to enablement and app store
API REST
Types, offres, acteurs, règles, opérations, transactions, configuration et traces / Types, offers, actors, rules, operations, transactions, configuration and traces
Intégrateurs et applications / Integrators and applications
Kernel & services
Identité, JWT, stock, vente, caisse, paiement, notification, recherche ou autres services communs / Identity, JWT, stock, sales, cash, payment, notification, search or other shared services
Selon contrat et configuration / Subject to contract and configuration
Webhooks & events
Notifications d’état, intégrations, reprises, observabilité et automatisations / Status notifications, integrations, retries, observability and automation
Destinations autorisées / Authorised destinations
Principales références juridiques / Main legal references
Français
Loi n° 2024/017 du 23 décembre 2024 relative à la protection des données à caractère personnel au Cameroun et textes d’application applicables.
Loi n° 2010/021 du 21 décembre 2010 régissant le commerce électronique et décret n° 2011/1521/PM du 15 juin 2011.
Loi n° 2010/012 du 21 décembre 2010 relative à la cybersécurité et à la cybercriminalité, ainsi que réglementation des communications électroniques.
Actes uniformes OHADA et règles camerounaises applicables aux contrats, sociétés, preuve, comptabilité, fiscalité, consommation, publicité, concurrence et propriété intellectuelle.
Réglementations CEMAC/BEAC/COBAC relatives aux paiements, à la monnaie électronique et à la lutte contre le blanchiment lorsque des fonctions réglementées sont effectivement activées.
Règles sectorielles propres au métier déclaré, notamment santé, transport, éducation, finance, commerce, assurance, agriculture, sécurité, emploi ou administration, lorsque concernées.
English
Law No. 2024/017 of 23 December 2024 relating to personal data protection in Cameroon and applicable implementing instruments.
Law No. 2010/021 of 21 December 2010 governing electronic commerce and Decree No. 2011/1521/PM of 15 June 2011.
Law No. 2010/012 of 21 December 2010 on cybersecurity and cybercrime, together with electronic communications regulation.
Applicable OHADA Uniform Acts and Cameroonian rules on contracts, companies, evidence, accounting, tax, consumer protection, advertising, competition and intellectual property.
Applicable CEMAC/BEAC/COBAC payment, electronic-money and anti-money-laundering rules where regulated functions are actually enabled.
Sector-specific rules for the declared business, including health, transport, education, finance, commerce, insurance, agriculture, security, employment or public administration where relevant.
Réserve / Qualification — Cette liste est indicative et ne remplace pas l’analyse des lois sectorielles, du pays de l’utilisateur, de l’activité configurée ou des traitements effectivement réalisés. / This list is indicative and does not replace analysis of sector-specific law, the user’s country, the configured activity or the processing actually performed.
PARTIE I — FRANÇAIS
Entrée en vigueur : 29 juillet 2026
Principe directeur — Business Core fournit une infrastructure générique déclarative. L’Organisation reste propriétaire de sa logique métier, de ses choix de configuration et de la relation avec ses propres utilisateurs, sauf engagement écrit contraire.
1. Éditeur, objet et rôle du service
Yowyob Inc. Ltd, société de droit camerounais, édite Yowyob Business Core. Le service permet de décrire un métier sous forme de données, de versionner ce modèle et d’exécuter des opérations au-dessus du Yowyob Kernel au moyen d’API, de règles et de workflows génériques.
Sauf contrat contraire, Yowyob agit comme fournisseur de plateforme. L’Organisation conçoit le métier, définit les finalités, règles, rôles, offres, paramètres et contrôles, et reste responsable du service final présenté à ses clients, employés, partenaires ou bénéficiaires.
2. Définitions
« Organisation » : entité créant un tenant, un modèle métier ou une application; « Intégrateur » : développeur ou prestataire reliant un système; « Type métier » : schéma versionné; « Offre » : unité de valeur et capacités; « Acteur » : opérateur ou bénéficiaire; « Règle » : déclencheur, condition et effet; « Opération » : workflow exécuté; « Transaction » : échange de valeur; « Configuration » : paramètres; « Kernel » : noyau de services communs Yowyob.
« Environnement » désigne notamment sandbox, test, préproduction ou production; « Trace » désigne un journal technique ou fonctionnel; « Données du tenant » désigne les modèles, paramètres, opérations, contenus et données transmis pour le compte de l’Organisation.
3. Acceptation et hiérarchie contractuelle
La création d’un compte, d’un tenant, d’une clé, d’un modèle, l’appel d’une API ou l’utilisation de la console vaut acceptation des présentes CGU par l’utilisateur autorisé. L’administrateur garantit son pouvoir d’engager l’Organisation.
Le contrat d’entreprise, le bon de commande, les SLA, l’accord de traitement, les conditions tarifaires et la documentation versionnée priment pour leur objet. Une documentation technique ne peut supprimer une garantie légale impérative.
4. Éligibilité, pouvoirs et conformité sectorielle
L’Organisation maintient son existence, ses licences, assurances, habilitations, déclarations et autorisations. Elle évalue si son activité peut légalement être automatisée, externalisée, hébergée ou traitée dans les territoires concernés.
Les secteurs réglementés ou à risque élevé exigent une validation juridique, métier, sécurité et, lorsque nécessaire, humaine avant production. Une clé d’API ou un environnement opérationnel ne constitue pas un agrément.
5. Comptes, tenants, rôles et moindre privilège
Chaque tenant est administré selon le moindre privilège. Les rôles propriétaire, administrateur, développeur, opérateur, auditeur, support, finance ou lecture seule sont séparés lorsque le risque le justifie. Les comptes partagés sont évités.
L’Organisation révoque rapidement les accès lors d’un départ, changement de fonction, perte d’appareil ou incident. Elle active MFA lorsque disponible et conserve des coordonnées de récupération exactes.
6. Clés API, JWT, secrets et authentification
Les clés, secrets clients, jetons JWT, certificats, mots de passe, clés de signature et webhooks sont confidentiels. Ils ne doivent pas être placés dans un dépôt public, une application cliente non protégée, une URL, un journal non filtré ou un support non chiffré.
L’authentification peut être déléguée au Kernel. L’Organisation reste responsable de l’identité et des autorisations qu’elle transmet. Une clé compromise doit être révoquée et remplacée sans délai.
7. Bêta publiée, essais, plans et quotas
Certaines fonctions sont proposées en bêta, essai gratuit ou préversion. Elles peuvent évoluer, être limitées, nécessiter une migration ou ne pas bénéficier du même niveau de support qu’une offre générale.
Les quotas, limites de débit, volumes, rétentions, environnements, fonctionnalités et niveaux de support sont indiqués dans l’offre. Le contournement par multiplication de comptes, clés, IP ou tenants est interdit.
8. Déclaration des types métier
L’Organisation décrit la structure de son métier, ses versions, capacités, contraintes et métadonnées. Elle vérifie cohérence, noms, unités, relations, cardinalités, valeurs par défaut, compatibilité et effets sur les données existantes.
Business Core peut refuser un schéma invalide ou dangereux, sans garantir qu’un schéma accepté soit complet, légal ou adapté au domaine.
9. Versionnement, épinglage et migrations
Une entreprise peut être épinglée à une version pour stabiliser son comportement. Toute évolution incompatible fait l’objet d’une nouvelle version, d’un plan de migration, de tests et d’une stratégie de retour.
L’Organisation ne modifie pas rétroactivement une règle au détriment d’une opération conclue sans base contractuelle. Les migrations conservent, lorsque requis, la preuve de l’ancienne version et des transformations.
10. Offres et unités de valeur
Les offres décrivent des produits, services, droits, ressources ou autres unités de valeur, avec prix, capacités, disponibilité et conditions. L’Organisation garantit l’exactitude des descriptions, montants, taxes, unités, restrictions et droits.
Une capacité technique telle que STOCKABLE, RESERVABLE, LIVRABLE ou PAYABLE n’établit pas à elle seule la réalité physique, la conformité, la propriété, la disponibilité ou la sécurité de l’offre.
11. Acteurs, rôles et bénéficiaires
L’Organisation définit qui peut initier, approuver, exécuter, recevoir ou contester une opération. Elle vérifie l’identité, la capacité, la séparation des tâches, les conflits d’intérêts et les délégations nécessaires.
Les données d’acteurs ne doivent pas être surcollectées. Les rôles métier ne remplacent pas les droits d’accès techniques et inversement.
12. Règles déclaratives
Une règle associe un déclencheur, une condition et un effet. L’Organisation documente sa finalité, son ordre de priorité, ses exceptions, ses limites, ses dépendances, sa date d’effet et son comportement en cas de données manquantes.
Les règles discriminatoires, opaques, illégales, incohérentes ou susceptibles de produire un dommage grave sans contrôle sont interdites. Les changements importants sont testés et approuvés.
13. Opérations et workflows
Une opération peut comporter validations, étapes, délais, appels externes, états, compensation et résultat synchrone ou différé. Un statut 202 indique une prise en charge, non une réussite définitive.
L’application cliente doit afficher l’état réel, gérer les délais et ne pas présenter une opération en attente comme conclue. Les tâches humaines requises ne doivent pas être masquées.
14. Transactions et échanges de valeur
La façade transactionnelle peut orchestrer vente, stock, caisse, paiement ou autres échanges. Business Core n’est pas automatiquement un établissement financier, un système comptable certifié, un assureur, un transporteur ou le vendeur du bien.
L’Organisation assure les pièces, rapprochements, taxes, factures, autorisations, politiques de remboursement et obligations de conservation applicables.
15. Configuration et paramètres
Les paramètres globaux et propres au tenant sont documentés, validés et limités. Les valeurs sensibles ou dangereuses disposent de bornes, droits et historique appropriés.
Une erreur de configuration peut affecter de nombreuses opérations. L’Organisation utilise revue à quatre yeux, environnement de test, sauvegarde et procédures de restauration lorsque le risque l’exige.
16. Kernel et services partagés
Business Core orchestre des services communs Yowyob, notamment identité, stock, vente, caisse, paiement, notification, recherche ou stockage, selon activation. Chaque service conserve ses propres conditions, responsabilités et limites.
L’inspiration d’une architecture fédérée de type Google.com ne crée aucune affiliation, approbation, licence ou identité technique avec Google.
17. Exécution synchrone, différée et statuts
Une réponse immédiate peut être complète, partielle ou provisoire. Les clients interrogent le statut, consomment les événements et gèrent les expirations. Les appels ne doivent pas être répétés aveuglément après un timeout.
Les codes HTTP, erreurs RFC 7807, identifiants de corrélation et messages doivent être traités conformément à la documentation versionnée.
18. Idempotence, reprise et déduplication
Les opérations créant une valeur, un débit, une réservation ou une écriture utilisent une clé d’idempotence unique et stable pendant la fenêtre publiée. L’Organisation protège cette clé contre la réutilisation incohérente.
Une reprise ne doit pas créer un double paiement, double stock, double avantage ou double notification. Les systèmes partenaires doivent également être idempotents.
19. Compensation, annulation et réconciliation
Une compensation vise à restaurer un état fonctionnel après échec, sans garantir l’effacement matériel de tous les effets externes. Les opérations irréversibles ou partiellement exécutées exigent une procédure métier.
L’Organisation rapproche régulièrement Business Core avec les systèmes sources, traite les écarts, documente les corrections et conserve l’auteur, le motif et la preuve.
20. Isolation multi-tenant et RLS
L’isolation par Row-Level Security et autres contrôles réduit les risques d’accès croisé. L’Organisation ne doit pas désactiver, contourner ou partager des identifiants de tenant de manière non autorisée.
Les intégrateurs testent les contrôles d’autorisation, évitent les identifiants prédictibles et signalent toute fuite potentielle. Aucun contrôle unique ne remplace une défense en profondeur.
21. Traces, audit et preuve électronique
Business Core peut journaliser acteur, opération, statut, durée, tenant, version, horodatage, IP, appareil, clé, erreurs et événements de sécurité. Les traces sont protégées contre l’altération et accessibles selon les rôles.
Les journaux constituent des éléments techniques soumis au droit applicable; ils ne prouvent pas automatiquement la réalité physique, la volonté juridique ou la culpabilité d’une personne.
22. API, webhooks et intégrations
L’Intégrateur respecte schémas, versions, signatures, quotas, délais, sécurité TLS, validation des entrées et journalisation. Il vérifie les certificats, signatures et destinations des webhooks.
Les intégrations tierces sont sous la responsabilité de leur opérateur. Yowyob peut suspendre une destination compromise, générant des boucles, fuites, erreurs massives ou abus.
23. Qualité des données et données sources
L’Organisation garantit la licéité, l’exactitude, la complétude, la fraîcheur et la provenance des données qu’elle injecte. Elle ne doit pas utiliser Business Core pour légitimer un registre faux, incomplet ou obtenu illicitement.
Les champs obligatoires et validations techniques ne remplacent pas les contrôles métier. Les données critiques doivent être confirmées auprès de la source appropriée.
24. Automatisation, recommandations et intelligence artificielle
Des outils peuvent proposer un schéma, une règle, un mapping, une anomalie ou une optimisation. Ces suggestions sont indicatives, peuvent être inexactes ou biaisées et doivent être validées avant activation.
Les données d’un tenant ne servent pas à entraîner un modèle général sans base, information, contrat et choix requis. Les décisions significatives concernant une personne ne reposent pas exclusivement sur un résultat automatisé non vérifié.
25. Usages interdits et systèmes à risque élevé
Sont interdits : fraude, blanchiment, contournement réglementaire, malware, surveillance illégale, discrimination, manipulation, exploitation de mineurs, armes ou contenus illicites, atteinte aux droits, extraction massive non autorisée, attaque, test de sécurité sans permission ou reconstruction du service.
Les usages vitaux, médicaux, judiciaires, policiers, financiers, de crédit, d’emploi, d’assurance ou de sécurité critique nécessitent un cadre spécifique, des contrôles humains, une analyse de risque et les autorisations applicables.
26. Sandbox, tests et passage en production
Les données réelles ne doivent pas être utilisées en test sans nécessité et protection. Les jeux de données sont synthétiques ou minimisés. Les environnements et clés sont séparés.
Avant production, l’Organisation réalise tests fonctionnels, charge, sécurité, reprise, autorisations, confidentialité, idempotence, compensation, accessibilité et conformité, puis documente l’acceptation.
27. Abonnements, facturation et taxes
Les prix, appels, stockage, trafic, environnements, support, services tiers et dépassements sont définis par l’offre. Les taxes, frais de réseau, paiement, messagerie et matériels sont supportés par la partie désignée.
L’essai peut être limité ou révoqué en cas d’abus. Un impayé peut entraîner restriction après préavis raisonnable, sans supprimer les obligations de restitution ou de conservation.
28. Propriété intellectuelle
Yowyob conserve ses logiciels, API, modèles génériques, documentation, marques, interfaces et savoir-faire. L’Organisation conserve ses modèles métier, données, marques, règles et contenus, sous réserve des droits de tiers.
La licence accordée à Yowyob est limitée à la fourniture, sécurité, support et amélioration du service. Le feedback peut être utilisé sans divulguer les secrets ou réaffecter les données personnelles.
29. Confidentialité
Chaque partie protège les informations non publiques, clés, architectures, prix, modèles, opérations et rapports reçus. L’accès est limité au besoin d’en connaître et les sous-traitants sont liés par des obligations appropriées.
La confidentialité ne couvre pas les informations devenues publiques sans faute, déjà connues, développées indépendamment ou légalement exigées, sous réserve d’information lorsque permise.
30. Protection des données personnelles
L’Avis de confidentialité précise les rôles, finalités, données, droits, rétention, transferts et sécurité. L’Organisation est généralement responsable du traitement de ses données métier; Yowyob peut être sous-traitant et responsable distinct pour comptes, sécurité, facturation et obligations légales.
L’Organisation signe les accords nécessaires, informe les personnes, traite les demandes et configure la minimisation. Elle n’injecte pas de données sensibles sans nécessité, base et garanties.
31. Données hors du Cloud Yowyob
Toute donnée exportée vers un CRM, ERP, data lake, tableur, appareil, email, sauvegarde, cloud, API, webhook ou prestataire externe relève de l’entité qui décide l’export. Elle assure base, sécurité, accès, conservation, suppression, droits et incidents.
La suppression dans Business Core ne supprime pas automatiquement les copies, caches, journaux ou sauvegardes externes.
32. Sécurité et notification des incidents
Chaque partie applique des mesures proportionnées : chiffrement, MFA, contrôle d’accès, RLS, rotation des secrets, sauvegardes, surveillance, tests, correctifs et plan de réponse. L’Organisation sécurise son code, ses appareils et intégrations.
Toute suspicion de compromission, accès croisé, perte de clé, injection, altération ou indisponibilité significative est signalée rapidement avec les informations disponibles et sans détruire les preuves.
33. Documentation, support et changements techniques
La documentation décrit l’état publié de l’API mais peut comporter des erreurs. Les versions, dépréciations et fenêtres de migration sont communiquées selon l’offre et l’urgence.
Le support n’assume pas la conception juridique ou sectorielle du métier. L’Organisation fournit des reproductions minimales et évite d’envoyer des secrets ou données excessives dans un ticket.
34. Disponibilité, maintenance et continuité
Yowyob vise une disponibilité raisonnable, sans garantir un service continu, sans erreur ou compatible avec tout système. Maintenance, réseau, dépendances, force majeure, attaque ou fournisseur peuvent affecter le service.
L’Organisation prévoit mode dégradé, files d’attente, reprise, surveillance, sauvegarde et procédure manuelle pour les opérations critiques.
35. Suspension, résiliation et réversibilité
Yowyob peut limiter ou suspendre un compte, une clé, un tenant ou une opération pour sécurité, illégalité, abus, impayé, risque tiers ou violation substantielle. Une urgence peut justifier une action immédiate suivie d’un examen.
À la fin, les parties organisent export, restitution, suppression, rétention probatoire, révocation des clés, arrêt des webhooks et migration selon contrat et loi.
36. Garanties et exclusions
Chaque partie garantit son pouvoir et ses droits. Yowyob garantit fournir le service avec un soin professionnel raisonnable, sans garantir qu’un modèle métier produira le résultat économique, réglementaire ou opérationnel attendu.
Les informations, exemples et snippets sont fournis pour assistance et doivent être testés. Aucune clause n’exclut une garantie impérative.
37. Responsabilité et indemnisation
Chaque partie répond de ses fautes, obligations et systèmes sous contrôle. Yowyob n’est pas responsable des règles, données, offres, décisions, transactions ou intégrations conçues par l’Organisation, sauf faute propre.
Les plafonds et exclusions éventuels figurent au contrat commercial et ne s’appliquent pas lorsqu’interdits, notamment en cas de fraude, faute lourde, atteinte intentionnelle ou responsabilité obligatoire.
38. Droit applicable et différends
Les présentes CGU sont régies par le droit camerounais, sous réserve des règles impératives applicables. Les parties recherchent d’abord une résolution documentée par le support et les responsables contractuels.
À défaut, la juridiction compétente ou le mécanisme convenu s’applique. Les mesures urgentes de sécurité, confidentialité, propriété intellectuelle ou données restent disponibles.
39. Modifications et contacts
Les modifications portent une date et, lorsqu’elles sont substantielles, font l’objet d’une information et d’un délai raisonnable, sauf urgence légale ou de sécurité.
Contacts : legal@yowyob.com; privacy@yowyob.com; support@yowyob.com. Portail : https://business-core.yowyob.com/.
Annexe A — Les sept briques du modèle
Brique
Objet
Contrôles minimaux
Types métier
Schéma versionné du domaine
Version, compatibilité, migration, validation
Offres
Unités de valeur et capacités
Description, prix, unités, droits, disponibilité
Acteurs
Opérateurs et bénéficiaires
Identité, rôle, séparation, habilitation
Règles
Déclencheur → condition → effet
Priorité, exception, test, traçabilité
Opérations
Workflows exécutables
États, délai, idempotence, compensation
Transactions
Échanges de valeur
Pièce, rapprochement, taxe, preuve
Configuration
Paramètres globaux et tenant
Bornes, droits, historique, revue
Annexe B — Matrice des responsabilités
Acteur
Responsabilités principales
Ne doit pas être présumé
Yowyob
Infrastructure, sécurité plateforme, API, isolation, support contractuel
Concepteur ou garant du métier du client
Organisation
Finalités, modèle, règles, données, utilisateurs, conformité et exploitation
Simple utilisateur sans responsabilité
Intégrateur
Code, clés, mappings, tests, sécurité, webhooks et documentation
Mandataire de Yowyob sans écrit
Utilisateur final
Usage loyal, exactitude et protection du compte
Partie directe au contrat d’entreprise Yowyob sauf indication
Fournisseur tiers
Service, sécurité et obligations propres
Sous contrôle intégral de Yowyob
Annexe C — Cycle minimal d’une opération
Étape
État indicatif
Contrôles
Réception
Acceptée / rejetée
Auth, tenant, schéma, quota, idempotence
Validation
Valide / incomplète
Règles, droits, données, dépendances
Exécution
En cours / attente externe
Étapes, délai, corrélation, sécurité
Finalisation
Complétée / partielle / échouée
Résultat, pièce, notification
Compensation
Annulée / à traiter
Effets irréversibles, responsable, preuve
Réconciliation
Conforme / écart
Source, rapprochement, correction, audit
PART II — ENGLISH
Effective date: 29 July 2026
Core principle — Business Core provides generic declarative infrastructure. The Organisation retains ownership of its business logic, configuration choices and relationship with its users unless expressly agreed otherwise.
1. Publisher, purpose and service role
Yowyob Inc. Ltd publishes Yowyob Business Core. The service allows a business domain to be declared as data, versioned and executed above the Yowyob Kernel through APIs, rules and generic workflows.
Unless otherwise agreed, Yowyob is the platform provider. The Organisation designs the domain, purposes, rules, roles, offers, settings and controls and remains responsible for the final service offered to customers, staff, partners or beneficiaries.
2. Definitions
“Organisation” means a tenant or application owner; “Integrator” means a developer or provider connecting a system; “Business Type” means a versioned schema; “Offer” means a unit of value and capabilities; “Actor” means operator or beneficiary; “Rule” means trigger, condition and effect; “Operation” means executed workflow; “Transaction” means value exchange; “Configuration” means settings; “Kernel” means Yowyob shared services.
“Environment” includes sandbox, test, staging and production; “Trace” means a technical or functional log; “Tenant Data” means models, settings, operations, content and data submitted for the Organisation.
3. Acceptance and contract hierarchy
Creating an account, tenant, key or model, calling an API or using the console constitutes acceptance by an authorised user. The administrator warrants authority to bind the Organisation.
The enterprise agreement, order form, SLA, data-processing agreement, pricing and versioned documentation prevail for their subject matter. Technical documentation does not waive mandatory legal rights.
4. Eligibility, authority and sector compliance
The Organisation maintains its legal status, licences, insurance, approvals and declarations. It assesses whether its activity may lawfully be automated, outsourced, hosted or processed in relevant territories.
Regulated or high-risk sectors require legal, domain, security and, where needed, human validation before production. An API key is not a regulatory approval.
5. Accounts, tenants, roles and least privilege
Each tenant uses least privilege and separates owner, administrator, developer, operator, auditor, support, finance and read-only roles where justified. Shared accounts are avoided.
Access is promptly revoked on departure, role change, lost device or incident. MFA is enabled where available.
6. API keys, JWT, secrets and authentication
Keys, client secrets, JWTs, certificates, passwords and signing keys are confidential and must not be placed in public repositories, unprotected clients, URLs or unfiltered logs.
Authentication may be delegated to the Kernel. The Organisation remains responsible for identities and authorisations it sends. Compromised credentials must be revoked and rotated.
7. Published beta, trials, plans and quotas
Some functions are beta, trial or preview and may change, be limited, require migration or have reduced support.
Quotas, rate limits, retention, environments, functions and support are defined in the offer. Circumvention through multiple accounts, keys, IPs or tenants is prohibited.
8. Declaring business types
The Organisation defines the domain structure, versions, capabilities, constraints and metadata and checks consistency, units, relationships, cardinalities, defaults and compatibility.
Business Core may reject an invalid or unsafe schema without warranting that an accepted schema is complete, lawful or suitable.
9. Versioning, pinning and migrations
A business instance may be pinned to a version. Incompatible changes require a new version, migration plan, testing and rollback strategy.
Rules must not be changed retroactively to defeat concluded operations without a lawful contractual basis. Required evidence of prior versions is preserved.
10. Offers and units of value
Offers describe products, services, rights, resources or other units of value. The Organisation ensures descriptions, amounts, taxes, units, restrictions and rights are accurate.
A technical capability such as STOCKABLE or PAYABLE does not prove physical existence, compliance, title, availability or safety.
11. Actors, roles and beneficiaries
The Organisation defines who may initiate, approve, execute, receive or challenge an operation and verifies identity, capacity, segregation and delegation.
Business roles and technical permissions are both required and should not be conflated.
12. Declarative rules
A rule combines trigger, condition and effect. Purpose, priority, exceptions, limits, dependencies, effective date and missing-data behaviour are documented.
Illegal, discriminatory, opaque or dangerous rules are prohibited. Material changes are tested and approved.
13. Operations and workflows
Operations may include validation, steps, timeouts, external calls, states, compensation and synchronous or deferred results. A 202 response means accepted for processing, not completed.
Client applications must display actual status and handle delay instead of presenting a pending operation as final.
14. Transactions and value exchanges
The transaction facade may orchestrate sales, stock, cash, payment or other exchanges. Business Core is not automatically a financial institution, certified accounting system, insurer, carrier or seller.
The Organisation handles evidence, reconciliation, tax, invoicing, authorisation, refunds and statutory retention.
15. Configuration and settings
Global and tenant settings are documented, validated and bounded. Sensitive settings use appropriate rights and history.
Misconfiguration can affect many operations. Four-eyes review, testing, backup and restoration are used where justified.
16. Kernel and shared services
Business Core may orchestrate shared Yowyob identity, stock, sales, cash, payment, notification, search or storage services. Each service retains its own terms and limits.
Architectural inspiration from integrated ecosystems such as Google.com creates no affiliation, approval, licence or technical identity with Google.
17. Synchronous and deferred execution
Immediate responses may be complete, partial or provisional. Clients query status, consume events and handle expiry rather than blindly retrying after timeout.
HTTP codes, RFC 7807 errors and correlation identifiers are handled under versioned documentation.
18. Idempotency, retries and deduplication
Value-creating, debiting, reserving or posting operations use a unique stable idempotency key during the published window.
Retries must not create duplicate payments, stock, benefits or notifications. Partner systems should also be idempotent.
19. Compensation, reversal and reconciliation
Compensation aims to restore a functional state after failure and may not erase every external effect. Irreversible or partial operations require a business procedure.
The Organisation reconciles with source systems, resolves differences and records actor, reason and evidence.
20. Multi-tenant isolation and RLS
Row-Level Security and other controls reduce cross-tenant access. Tenant identifiers and controls must not be disabled, bypassed or improperly shared.
Integrators test authorisation and report potential leakage. No single control replaces defence in depth.
21. Traces, audit and electronic evidence
Business Core may log actor, operation, status, duration, tenant, version, timestamp, IP, device, key, error and security event with role-based access.
Logs are technical evidence subject to law and do not automatically prove physical reality, legal intent or personal guilt.
22. APIs, webhooks and integrations
Integrators follow schemas, versions, signatures, quotas, TLS, input validation and logging and verify webhook signatures and destinations.
Third-party integrations are controlled by their operators. Yowyob may suspend a compromised or abusive destination.
23. Data quality and source records
The Organisation ensures lawful origin, accuracy, completeness and currency of submitted data. Business Core must not be used to legitimise false or unlawfully obtained records.
Technical required fields do not replace domain checks. Critical data is confirmed at the appropriate source.
24. Automation, recommendations and AI
Tools may suggest schemas, rules, mappings, anomalies or optimisation. Suggestions may be wrong or biased and require validation.
Tenant data is not used to train a general model without a basis, notice, contract and required choice. Significant personal decisions are not based solely on unreviewed automation.
25. Prohibited and high-risk uses
Fraud, money laundering, malware, unlawful surveillance, discrimination, manipulation, child exploitation, unlawful weapons/content, rights violations, unauthorised extraction, attacks and unapproved security testing are prohibited.
Life-critical, medical, judicial, policing, credit, employment, insurance and safety-critical uses require specific controls, human oversight, risk assessment and approvals.
26. Sandbox, testing and production release
Real data is not used in testing without necessity and safeguards. Synthetic or minimised data and separate keys are preferred.
Before production the Organisation tests function, load, security, recovery, permissions, privacy, idempotency, compensation, accessibility and compliance.
27. Subscriptions, billing and taxes
Pricing, calls, storage, traffic, environments, support and third-party services are set in the offer. Applicable taxes and designated third-party charges remain payable.
Trials may be limited or revoked for abuse. Non-payment may result in restriction after reasonable notice.
28. Intellectual property
Yowyob retains its software, generic models, APIs, documentation, marks and know-how. The Organisation retains its domain models, data, marks, rules and content subject to third-party rights.
The licence to Yowyob is limited to delivery, security, support and improvement.
29. Confidentiality
Each party protects non-public keys, architecture, pricing, models, operations and reports with need-to-know access and appropriate downstream duties.
Standard exceptions apply to lawfully public, already known, independently developed or legally required information.
30. Personal data protection
The Privacy Notice describes roles, purposes, rights, retention, transfers and security. The Organisation is generally controller for domain data; Yowyob may be processor and separate controller for accounts, security, billing and legal duties.
The Organisation signs required agreements, informs people, handles requests and minimises data.
31. Data outside Yowyob Cloud
The entity exporting data to CRM, ERP, data lake, spreadsheet, device, email, backup, cloud, API, webhook or external provider is responsible for legal basis, security, access, retention, deletion, rights and incidents.
Deletion in Business Core does not automatically erase external copies, caches, logs or backups.
32. Security and incident notification
Each party uses proportionate encryption, MFA, access control, RLS, secret rotation, backup, monitoring, testing, patching and response plans.
Suspected compromise, cross-tenant access, key loss, injection, alteration or material outage is promptly reported while preserving evidence.
33. Documentation, support and technical changes
Documentation describes the published API but may contain errors. Versions, deprecations and migration windows are communicated according to the offer and urgency.
Support does not design the legal or sector framework and tickets must avoid unnecessary secrets or personal data.
34. Availability, maintenance and continuity
Yowyob seeks reasonable availability without guaranteeing uninterrupted or error-free operation. Network, dependencies, maintenance, attacks and force majeure may affect service.
The Organisation plans degraded mode, queues, recovery, monitoring, backups and manual procedures for critical operations.
35. Suspension, termination and reversibility
Yowyob may restrict or suspend a key, account, tenant or operation for security, illegality, abuse, non-payment, third-party harm or material breach. Urgent action may be immediate.
Exit covers export, return, deletion, evidentiary retention, key revocation, webhook shutdown and migration under contract and law.
36. Warranties and disclaimers
Each party warrants authority and rights. Yowyob provides the service with reasonable professional care but does not warrant the business, regulatory or economic outcome of a customer model.
Examples and snippets require testing. Mandatory warranties remain unaffected.
37. Liability and indemnity
Each party is responsible for its own faults and systems. Yowyob is not responsible for customer-designed rules, data, offers, decisions, transactions or integrations except for Yowyob’s own fault.
Commercial caps apply only as lawfully agreed and not where prohibited.
38. Governing law and disputes
These Terms are governed by Cameroonian law subject to mandatory rules. Parties first seek documented resolution through support and contract owners.
The competent court or agreed mechanism applies if unresolved, without preventing urgent security, confidentiality, IP or data relief.
39. Amendments and contacts
Changes are dated and material changes receive appropriate notice and a reasonable period unless legal or security urgency requires otherwise.
Contacts: legal@yowyob.com; privacy@yowyob.com; support@yowyob.com. Portal: https://business-core.yowyob.com/.
Appendix A — The seven model building blocks
Building block
Purpose
Minimum controls
Business Types
Versioned domain schema
Version, compatibility, migration, validation
Offers
Units of value and capabilities
Description, price, units, rights, availability
Actors
Operators and beneficiaries
Identity, role, segregation, authority
Rules
Trigger → condition → effect
Priority, exception, testing, traceability
Operations
Executable workflows
States, timeout, idempotency, compensation
Transactions
Value exchanges
Evidence, reconciliation, tax, proof
Configuration
Global and tenant settings
Bounds, rights, history, review
Appendix B — Responsibility matrix
Actor
Main responsibilities
Must not be assumed
Yowyob
Infrastructure, platform security, API, isolation and contracted support
Designer or guarantor of the customer domain
Organisation
Purposes, model, rules, data, users, compliance and operations
A user with no responsibility
Integrator
Code, keys, mappings, tests, security, webhooks and documentation
Yowyob agent without written appointment
End user
Fair use, accuracy and account protection
Direct party to Yowyob enterprise agreement unless stated
Third-party provider
Own service, security and legal duties
Fully controlled by Yowyob
Appendix C — Minimum operation lifecycle
Stage
Indicative state
Controls
Receipt
Accepted / rejected
Auth, tenant, schema, quota, idempotency
Validation
Valid / incomplete
Rules, rights, data, dependencies
Execution
Running / external wait
Steps, timeout, correlation, security
Finalisation
Completed / partial / failed
Result, evidence, notification
Compensation
Reversed / manual action
Irreversible effects, owner, evidence
Reconciliation
Matched / discrepancy
Source, correction, audit