Documentation

Actuellement, deux versions de l’API cohabitent:

  • La version 2 (v2), la plus à jour et complète, qui bénéficie des dernières fonctionnalités et qui sera maintenue.
  • La version legacy, est une reprise de l’API de l’ancien système d’informations pour faciliter la transition. C’est une solution de temporaire pour vous permettre de continuer à utiliser nos services le temps que vous puissiez migrer vers la v2. Notez cependant que cette version est dépréciée, ne bénéficie pas de toutes les dernières fonctionnalités, et ne profitera pas des améliorations futures. Il se peut que certains produits ne soient pas/plus disponibles à la commande sur celle-ci. C’est pourquoi nous vous invitons à migrer.

Que vais-je trouver ici ?

Principalement de la documentation sur notre système d’informations pour vous aider à vous interfacer avec. Pour cela vous trouverez :

  • des informations sur l’organisation de notre système
  • des exemples de code
  • des descriptions de nos procédures

1 - Concepts

Les concepts clés de notre système

Pour que vous ayez les tenants et aboutissants de notre système vous trouverez ici une présentation rapide de l’architecture de celui-ci. Ainsi vous n’aurez pas à deviner la mécanique qui est implémentée derrière nos routes.

1.1 - Concepts

Les concepts clés de notre système

Les objets

Notre groupe

Le SI vous permet de commander auprès de diffèrentes entitées du groupe Infra-Corp : Prizz Telecom, Prizz Infrastructure, Qotico Telecom… cela dépend des contrats que vous avez signé.

Chaque entreprise est représentée par une LegalEntity.

Nos clients

Vous êtes les ClientLegalEntity et vous êtes liés avec nous (une LegalEntity) par des ClientContract que vous pouvez obtenir sur votre objet ClientLegalEntity attribut contracts.

Chaque contrat dans cette liste vous indique :

  • un catalogue PriceList, chaque catalogue représentant une famille de produits. Par exemple L2 Premium, L2 basic, FON, etc…
  • le délai de paiement des factures paymentTermDays
  • vatReverseCharge, la mise en place ou non de l’autoliquidation de la TVA

Le catalogue

Chaque ClientContract vous donne accès à une PriceList, en l’état cette liste ne vous sera pas très utile. Il faut que vous regardiez du côté des offres pour connaître le prix des accès.

Pour interpréter les PriceList il faut en effet prendre une Offer, trouver le MainOfferItem (qui est un item d’une PriceList) qui constitue la base de l’offre. Ensuite vous aurez une liste de groupes pour lesquels il faudra choisir des PriceListItem pour construire votre produit.

Les devis

Les devis sont matérialisés par les CommercialOffer. Pour commander ou modifier un service on passera toujours par un devis qu’il faut accepter en le signant.

Sections

Les devis sont découpés en sections, chaque section comportant un ensemble d’items destinés à un produit (par exemple un accès). Dans ce cas il y aura une ligne pour le produit, une autre pour la bande passante, la GTR… Le tout regroupé dans une section.

Quand un devis est signé, chaque section est transformée en ServiceContract, le nom de la section sera repris dans la description du ServiceContract, vous pouvez y mettre de quoi identifier votre client final (il y a aussi un autre champ pour votre référence de service).

Principaux attributs

Les attributs principaux :

  • rcTotal : total hors taxes des coûts récurrents, vous y trouverez par récurrence (mois, annéee…) le coût de la prestation.
  • rcVATTotal: la part de TVA pour chaque récurrence
  • nrcTotal: total hors taxes des coûts non récurrents, autrement dit les FAS (frais d’accès au service)
  • nrcVATtotal : la part de TVA pour les FAS (frais d’accès au service)
  • submitDate : Date à laquelle le devis vous a été soumis, la valeur est nulle tant que le devis est à l’état de brouillon
  • signDate : Date de signature, la valeur est nulle tant que le devis n’est pas accepté
  • deliveryDelay : Délai de livraison de la prestation (en jours)
  • sections : Les différents services que vous commandez

Signature

Deux méthodes de signatures existent :

Vous pouvez toujours nous transmettre vos devis signé à l’ADV.

Ou vous pouvez utiliser notre nouvelle procédure de signature automatisée (avec envoi d’un code de validation par mail). Il faut que la proposition soit validée de notre côté (attribut submitDate non nul), le code de validation est envoyé à un contact défini au moment de la validation. Une fois reçu, le contact peut nous soumettre le code sur cette route, qui fera office de signature.

Le contrat de services et les services

Un ServiceContract est la matérialisation d’une section de CommercialOffer (devis), lorsque ce dernier est validé et signé, sous forme d’un groupement de Services. C’est donc le passage de l’état de proposition commerciale, à celui de service fourni.

Lors de cette conversion, une Section de CommercialOffer devient un ServiceContract, et un Item de Section de CommercialOffer devient un Services.

Créé lors de la validation d’un devis les ServiceContract sont les points de regroupement d’un ensemble de Services.

Sur l’attribut services d’un ServiceContract, vous trouverez les Services qui le composent, à l’image de ce que vous pouvez trouver dans les devis.

Chaque service à son propre statut :

  • new : nouveau, juste après la validation du devis
  • staging : en cours de construction, le métier a déjà commencé à travailler dessus
  • active : en service
  • ending : résiliation en cours, il peut encore être opérationnel le temps que la clôture soit actée
  • terminated : le service est clôturé, et inactif

Les processus

C’est par leur intermédiaire que vous allez interagir avec les objets. Chaque action ne peut être réalisée que dans un Workflow en utilisant une transition. Vous serez en mesure de déclencher certains workflow et d’utiliser certaines transitions dites manuelles.

Un Workflow s’éxécute sur un objet directement, en lui attribuant un état initial, et en régissant, à la manière d’un automates les changements d’états possibles de l’objet à l’aide de transitions, jusqu’à un état final.

Un Workflow cadre donc une partie du cycle de vie possible d’un objet (une opération; de création, de signature, d’envoi, …).

Un Workflow est composé de transitions, qui permettent de le faire avancer. Une transition est définie par :

  • Un état possible d’entrée (état dans lequel le Workflow doit être positionné pour pouvoir prétendre à éxécuter la transition)
  • Une liste d’états de sortie, correspondant à l’un des états dans lequel le Workflow sera présent à la fin de l’éxécution du code de la transition.
  • Le contenu du code de la transition, qui va effectuer tous les tests et les règles métiers qui vont décider du changement d’état du Workflow.
  • Le type de la transition (automatique ou manuelle).

Un Workflow va donc, à partir de son état initial, dérouler automatiquement les tansitions dites “automatiques” jusqu’à se retrouver

  • soit dans un état final (pouvant matérialiser le succès comme l’échec de l’opération souhaitée)
  • soit bloqué par une transition dite “manuelle” nécéssitant l’action humaine d’une personne de vos équipes, comme des notres (par exemple pour un devis, l’étape de validation du devis par nos équipes, ou l’étape de signature par la personne référrente de vos équipes).

Un fois le blocage manuel résolu, il recommencera à enchainer les transitions jusqu’à un nouveau blocage manuel ou l’atteinte d’un état final.

1.2 - Zones d'éligibilités

Ce document a pour objectif de vous présenter le fonctionnement de notre éligibilité et comment sont déterminés les FAS.

Lors d’un test d’éligibilité plusieurs jeux de données sont mobilisés. Dans la plupart des cas c’est la distance aux câbles qui est importante.

Ce que nous appelons “distance aux câbles” est une estimation approximative du chemin à construire pour rendre une adresse éligible et c’est à partir de cette valeur que nous allons construire notre prix dans le cas général.

Il existe des exceptions, où la zone peut être difficile à construire, dans ce cas la zone est “sur devis”. C’est le cas de la Zone 6 du L2 Premium par exemple.

Une autre exception dans des zones où le réseau est suffisamment dense, ou que nous souhaitons densifier rapidement, pour ne pas demander de FAS .

Dans ce cas, la réponse d’éligibilité est “surclassée” en zone 1, c’est pourquoi il ne faut pas essayer de reproduire le calcul de votre côté en partant de la distance.

Enfin, dans l’offre Basic v2, le FAS est fixe dans un intervalle de distance puis calculé, la distance peut vous permettre de détecter le passage de ce seuil à 250m actuellement.

Le prix des FAS de nos offres dépend également de la durée d’engagement.

Il existe aussi un surcoût lorsque la zone où se trouve la porte de collecte et le point de livraison se trouvent dans des zones éloignées (s’applique pour le Var).

Où trouver les zones dans les réponses d’éligibilités

response[].combinations[].attributes

Sur chaque combinaison les distances sont rappelées en vous basant sur les attributs nrc_built_cable_d_maxou nrc_built_cable_d_min vous pouvez déduire la zone. Si la zone est une zone où nous devons faire une étude pour décider si l’on peut raccorder l’attribut nrcToEstimate a pour valeur true.

Rappel : une zone ne donne pas un prix constant, nous vous recommandons d’utiliser les attributs de distance en combinaison de l’attribut nrc si la construction de votre prix n’est pas basée sur notre prix mais fixe.

    "combinations": [
        {
          "combinationId": "contract:284&offer:1&items:71,73,111,115,149,536",
          "total": 9900,
          "totalWithoutNrc": 9900,
          "nrc": 0,
          "attributes": {
            "offer_type": 1,
            "bw_down": 10,
            "bw_down_guaranteed": 10,
            "bw_up_guaranteed": 10,
            "bw_up": 10,
            "grt_hours": 4,
            "grt_in_working_hours": true,
            "has_grt": true,
            "commitment_months": 60,
            "nrc_built_cable_d_max": 300,
            "nrc_built_cable_d_min": 0,
            "construction_time_in_days": 42,
            "national": 0
          },
          "nrcToEstimate": false
        },

response[].priceListItemsGroups.nrc

Sans parcourir les combinaisons vous pouvez accéder directement au FAS dans le groupe NRC (non recurrent costs)

          {
            "id": 115,
            "name": "prizz Liaison L2 FAS ZONE 1",
            "productName": "Liaison L2 FAS ZONE 1",
            "attributes": {
              "eligibility_string": "f1",
              "nrc_built_cable_d_max": 300,
              "nrc_built_cable_d_min": 0,
              "construction_time_in_days": 42
            }
          }

Aperçu des zones par offre

L2 Premium

Description Interval d_min d_max note
L2 FAS ZONE 1 0 à 300m 0 300
L2 FAS ZONE 2 300 à 500m 300 500
L2 FAS ZONE 3 500 à 700m 500 700
L2 FAS ZONE 4 700 à 1000m 700 1000
L2 FAS ZONE 5 1000 à 2000m 1000 2000
L2 FAS ZONE 6 2000 à 5000m 2000 5000 estimation sur étude

L3 Internet

Description Interval d_min d_max note
L3 FAS ZONE 1 0 à 300m 0 300
L3 FAS ZONE 2 300 à 500m 300 500
L3 FAS ZONE 3 500 à 700m 500 700
L3 FAS ZONE 4 700 à 1000m 700 1000
L3 FAS ZONE 5 1000 à 2000m 1000 2000
L3 FAS ZONE 6 2000 à 5000m 2000 5000 sur devis !

L2 Basic v1

Il n’y avait pas de FAS

L2 Basic v2

Description Interval d_min d_max note
L2 Basique FAS selon engagement 0 à 2500m  2500 au delà de 250m ajout d’un surcoût par mètre supplémentaire
L2 Basique sur devis     estimation sur étude

2 - API

Application Programming Interface

Nous mettons à votre disposition la même API que celle utilisée par l’Espace Client, vous pourrez donc réaliser toutes les actions de celui-ci et plus encore.

Nos interfaces sont documentées avec la spécification OpenAPI (anciennement Swagger), une documentation générée vous permet de découvrir toutes les méthodes mises à votre disposition.

La spécification/définition de l’API au format yaml est téléchargeable, à l’aide de OpenApi-Generator qui vous permettent de générer très rapidement un “client” dans le langage de votre choix à partir de cette spécification.

Nous publions un client en PHP sur GitHub. Si vous souhaitez ajoutez un language n’hésitez pas a nous solliciter.

Nouveautés

décembre 2024

  • Ajout de l’estimation de la distance à construire dans les réponses de tests d’éligibilités voir response[].distance

novembre 2024

octobre 2024

août 2024

  • Ajout des combinaisons d’offres dans les réponses d’éligibilités, l’attribut ‘combinationId’ est unique à chaque offre et prochainement il sera possible de passer commande avec : voir response[].combinations

juillet 2024

  • Ajout de la liste des rôles liés a une entité légale voir la clé roles
  • Ajout de la date de première activation d’un service_contract

mai 2024

avril 2024

  • Les contacts sont ajoutés dans les réponses des devis, contrat de services et clients sur la clé contacts une autre clé configuredContacts vous permet de les lister avec leur rôle
  • Nouvelle route pour ajouter des commentaire sur les contrat de services : /service_contracts/{id}/comments

mars 2024

2.1 - Authentification

Obtenir un jeton d’accès

Fonctionnement

Pour interroger l’API vous avez besoin d’un jeton d’accès, vous pouvez utiliser un jeton que vous pourrez générer depuis l’Espace Client.

Les tokens créés sur l’interface de production ne sont pas utilisables sur la plateforme de développement. Pour vos développement vous pouvez créer vos tokens sur l’espace client de tests.

Pour vos requêtes il faut ajouter un header Authorization et le jeton précédé de :

  • Token si c’est un jeton généré dans l’application

L’API legacy permet d’obtenir des access token, dans ce cas prefix est différent :

  • Bearer dans le cas d’un accessToken

Exemple en PHP

Ajoutez le client de l’API à votre projet

composer require infracorp/api-client-extranet

Pour obtenir une instance du client :

<?php

use Infracorp\Extranet\Client as PrizzTelecom;

require_once(__DIR__ . "/vendor/autoload.php");

$config = PrizzTelecom\Configuration::getDefaultConfiguration()
    ->setApiKey('Authorization', 'remplacez par votre token')
    ->setApiKeyPrefix("Authorization", "Token");

$prizzTelecom = new PrizzTelecom\Api\DefaultApi(
    new GuzzleHttp\Client(),
    $config
);

Par défaut le client se connecte à une plateforme de tests, pour passer en production il faudra changer l’hôte de l’objet $config avant le new.

$config->setHost($config->getHostFromSettings(2));

Exemple avec curl

Voici un exemple d’appel cURL par token pour récupérer la liste des entités légales sur lesquelles vous disposez d’un contrat client en cours de validité :

export url_api="https://dev.prizz-telecom.fr/"
export token="abcdefghijklmnopqrstuvwxyz"
curl --location "${url_api}/external-api/v2/legal_entities" --header "Authorization: Token ${token}"

Dans les exemples suivant on assumera que les variables $url_api et $token sont bien définies.

2.2 - Tests d'éligibilité

Comment faire des tests d’éligibilités depuis l’API

Prérequis

Présentation

Le test d’éligibilité est asynchrone, une fois la demande envoyée vous obtenez un identifiant qui vous permet de suivre le traitement de la requête et d’obtenir les résultats quand celle-ci sera terminée.

participant Client as client
participant PrizzAPI as prizz
entity EligibilityProcess as elig
database SIG as sig

group Create query
client -> prizz : CreateEligibility
prizz -> elig : create process
activate elig
prizz -> client : return eligibility_id
end

group Fetch #1
client -> prizz : q1
prizz -> client : answer with pending status
end group

elig -> sig : query
sig -> elig : results
elig -> elig : make offers
deactivate elig

group Fetch #2
client -> prizz : q2
prizz -> client : answer with done status and results
end group

Première étape : connaître son ID client

Pour faire un test nous avons besoin de savoir pour quel client il est effectué. Votre token pouvant être associé à plusieurs entreprises. Cela nous permet de trouver les bon contrats et tarifs associés.

Vous devez donc connaître l’id de votre client, pour cela vous pouvez interroger cette route.

foreach ($prizzTelecom->getClientLegalEntities()->getItems() as $legalEntity) {
    echo $legalEntity->getName() . " - " . $legalEntity->getId() . "\n";
}

// output :
// PRIZZ TELECOM - 32
//
// l'id a utiliser est 32
curl --request GET \
     --location "${url_api}/external-api/v2/client_legal_entities" \
     --header "Authorization: Token ${token}" \
     | jq '.items[]|{name:.name, id:.id}'

# output:
# {
#  "name": "PRIZZ TELECOM",
#  "id": 32
# }

Parcourez le tableau items de la réponse afin de localiser le client pour lequel vous souhaitez effectuer un test d’éligibilité, notez son id (que nous appellerons {id_client} pour la suite de cet exemple).

Vous pouvez en faire un élément de configuration de votre projet, cet identifiant est stable.

Créer un test d’éligibilité par adresse

Vous pouvez maintenant créer un nouveau test d’éligibilité. L’adresse, est au format texte. Elle doit être la plus précise possible et avoir un numéro dans la voie.

Documentation de la méthode.

$eligResult = $prizzTelecom->createEligibility(
    "111 Rue Réaumur, 75002 Paris",
    $legalEntity->getId() // 32
);

// Output :
// Array
// (
//    [0] => 43
// )
export address="111 Rue Réaumur, 75002 Paris";
export id_client=32;
curl --request POST \
     --location "${url_api}/external-api/v2/eligibility" \
     --header "Authorization: Token ${token}" \
     --header "Content-Type: application/json" \
     --data "{\"address\": \"${address}\", \"clientId\": ${id_client}}"

Vous devriez récupérer l’id du test effectué dans la partie responses, 43 dans le cas présent. Obtenir un id ne dit pas que l’adresse est éligible, mais qu’elle va être testée.

Créer un test d’éligibilité par latitude et longitude

Pour faire un test avec des coordonnées longitude, latitude il suffit de ne pas remplir le paramètre address mais lon et lat.

$eligResult = $prizzTelecom->createEligibility(
    client_id: $myClientLegalEntity->getId(),
    lon: 2.326099666185542,
    lat: 48.867587467406395
);

// Output :
// Array
// (
//    [0] => 43
// )
lon="2.326099666185542";
lat="48.867587467406395"
id_client=32;
curl --request POST \
     --location "${url_api}/external-api/v2/eligibility" \
     --header "Authorization: Token ${token}" \
     --header "Content-Type: application/json" \
     --data "{\"lon\": \"${lon}\", \"lat\": \"${lat}\", \"clientId\": ${id_client}}"

Obtenir le résultat du test

Comme indiqué précédemment, les tests d’éligibilité étant asynchrones, vous n’aurez pas le résultat lors de la création de la requête d’éligibilité. Il vous faut faire appel cette méthode pour obtenir le résultat : méthode.

$resp = $prizzTelecom->getEligibility(45);

foreach ($resp->getResponse() as $resp) {
    echo $resp->getCode() .
        " : " . $resp->getRcMin() / 100 .
        " -> " . $resp->getRcMax() / 100 . " " .
        "pricelist #" . $resp->getPriceListId() . "\n";
}

// Output :
// FON EVENTS : 5400 -> 5400 pricelist #4
// FON MAN : 350 -> 400 pricelist #7
// L2 Basique : 99 -> 200 pricelist #13
// L2 EVENT : 4500 -> 5050 pricelist #18
// L2 PREMIUM : 119 -> 699 pricelist #20
curl --request GET \
     --location "${url_api}/external-api/v2/eligibility/${id_test}" \
     --header "Authorization: Token ${token}"

En cas de succès, vous trouverez le résultat de l’éligibilité dans la partie response du retour.

2.3 - Souscription de services

La souscription passe par la création d’un devis sur cette offre. Cette API vous permet de créer vos devis. L’API est à votre disposition est assez riche, aussi, il existe plusieurs méthodes pour souscrire à une offre en utilisant différents cheminements.

Prérequis

Souscription

La souscription passe par la création d’un devis sur cette offre. Selon comment vous exploitez la réponse de l’éligibilité plusieurs méthodes sont à votre disposition pour créer vos devis :

  • rapide (recommandée) : ce que nous appelons le ‘fastOrder’ , vous permet de lancer une commande à partir d’une combinaison fournie dans la réponse d’éligibilité
  • sur mesure méthode plus complexe a mettre en oeuvre, mais qui permet de faire un devis sans passer par l’éligibilité le test étant réalisé pendant le passage de la commande. Elle vous permet de passer les éléments (débit, engagement, GTR) directement.

2.3.1 - Commande rapide

Commande rapide à partir d’une combinaison du test d’éligibilité

Créer un devis via FastOrder

La séquence est la suivante :

  1. effectuer un test d’éligibilité à l’adresse à raccorder et choisir la combinaison désirée. La chaîne de caractères de l’attribut combination_id va nous permettre de créer un devis avec les items désirés.
  2. soumettre le devis : on va faire des vérifications, et donner un prix aux éléments qui nécessite une quotation
  3. signer le devis

Choisir une combinaison

foreach ($resp->getResponse() as $resp) {
	if ($resp->getCode()=='ContractName') { //Nom du contrat recherché
    	foreach ($resp->getCombinations() as $combination) {
        	if ($combination['attributes']['bw_down'] == 100 && $combination['attributes']['grt_in_working_hours'] == false && $combination['attributes']['commitment_months']==12 ) { 
				//exemple d'une combiaison recherchée débit 100M engagment 12 mois avec une GTR HNO
				$combination_id = $combination['combination_id'];				
			}
		}
	}
}
$elig_ctx_id = ; $eligResponse->getId(); // int | identifiant du contexte d'éligibilité
$combination_id = $combination_id; // string | valeur de la combinaison choisie parmi les choix proposées dans la réponse de l'api éligibilité 
$fast_order = new \Infracorp\Extranet\Client\Model\FastOrder(); 
$fast_order->setName("Exemple Nom du client final"); // string | nom de la section du devis  
$fast_order->setClientReference("Ref_Interne"); // falcutatif | nom de votre référence interne. Vous permettra de retrouver votre commande avec votre référence.
$fast_order->setCombinationId($combination_id);
try {
    $commercialOffer= $prizzTelecom->fastOrder($elig_ctx_id, $fast_order);
} catch (Exception $e) {
   	echo 'Exception when calling DefaultApi->fastOrder: ', $e->getMessage(), PHP_EOL;
}

Si l’appel à FastOrder est un succès, elle vous retourne l’identifiant du devis créé. Celui contient les items correspondant à la combinaison choisie. Vous pouvez retourner consulter le devis il doit être à jour.

$result = $prizzTelecom->getCommercialOffer($commercialOfferId);

Demander la validation du devis

Une fois que vous avez terminé les modifications du devis vous pouvez nous le soumettre.

$prizzTelecom->submitCommercialOffer($commercialOffer->getId());

Une fois validé par nos services, la procédure de signature sera lancée. Vous recevrez un code par mail pour confirmer la commande.

Si vous voulez intégrer le mécanisme de signature vous pouvez valider le devis avec le code comme ceci :

$prizzTelecom->signCommercialOffer(
    $commercialOffer->getId(),
    (new SignCommercialOffer())->setCode("123456")
);

2.3.2 - Commande sur mesure

Cette méthode permet de créer des commandes en jouant sur tous les éléments du devis

Créer un devis sur mesure

La séquence est la suivante :

  1. commencer un devis pour un ClientLegalEntity
  2. ajouter une section : une section correspond a un service / accès
    • créer la section (associée à un ClientContract)
    • définir l’offre dans la section : par exemple, si c’est un accès : donner l’adresse a raccorder, la section sera remplie d’éléments qui formeront une première proposition
    • personnaliser l’offre dans la section : c’est à cette étape que vous pouvez modifier le début et l’engagement, a l’étape précédente c’est une offre “par défaut” qui vous a été proposé
  3. ajouter une autre section en reprenant à l’étape 2 (si nécessaire)
  4. soumettre le devis : on va faire des vérifications, et donner un prix aux éléments qui nécessite une quotation
  5. signer le devis

En voici un, à titre d’exemple. Dans cette page nous allons employer des termes en “français” et qui sont a associer à des objets “machine” dont le nom est anglicisé au sein de l’API, pour éviter des confusions nous vous invitons à consulter ce lexique en cas de doute

Commencer un devis

Trouver votre entité commerciale

$myClientLegalEntity = null;
foreach ($prizzTelecom->getClientLegalEntities()->getItems() as $clientLegalEntity) {
    if ($clientLegalEntity->getName() == "My Company name") {
        $myClientLegalEntity = $clientLegalEntity;
    }
}

Note

Vous pouvez stocker l’id de cette entité, ce sera probablement un élément de configuration de votre côté. Il n’est pas nécessaire de le rechercher à chaque fois.

Faire un test d’éligibilité et sélectionner l’offre

On suppose qu’on veut souscrire un “L2 PREMIUM”. Première étape, on fait un test d’éligibilité.

$eligResult = $prizzTelecom->createEligibility(
    "111 Rue Réaumur, 75002 Paris",
    $myClientLegalEntity->getId()
);

On parcours les proposition de l’éligibilité pour ne retenir que le L2 PREMIUM. On récupère en passant l’id de l’offre et de la liste de prix.

$price_list_id = null;
$offer_id = null;
foreach ($eligResult->getResponses() as $response_id) {
    $ret = $prizzTelecom->getEligibility($response_id);
    foreach ($ret->getResponse() as $response) {
        if ($response->getCode() == 'L2 PREMIUM') {
            $price_list_id = $response->getPriceListId();
            $offer_id = $response->getOfferId();
        }
    }
}

Choisir un contrat

Le ClientContract (contrat), c’est la glue entre un ClientLegalEntity (vous) et une PriceList. Il faut en choisir un pour commencer une section. A noter qu’il peut il y avoir plusieurs ClientContract pour la même PriceList pour avoir une liste de contacts personnalisés, différents profil de configuration de la porte de collecte.

$myContract = null;
foreach ($myClientLegalEntity->getContracts() as $contract) {
    if ($contract->getPriceList()->getId() == $price_list_id) {
        $myContract = $contract;
    }
}

Créer le devis

Il faut fournir en plus de votre ID celui de l’entité légale, on peut le trouver sur la liste de prix.

$legalEntityId = $prizzTelecom->getPriceList($price_list_id)->getLegalEntity()->getId();

$commercialOffer = $prizzTelecom->createCommercialOffer(
    [
        "legalEntityId" => $legalEntityId,
        "clientLegalEntityId" => $clientLegalEntity->getId()
    ]
);

Note

Vous pouvez stocker l’id de la legalEntity, ce sera probablement un élément de configuration de votre côté. Il n’est pas nécessaire de le rechercher à chaque fois.

Ajouter une section au devis

Les devis sont découpé en sections, ainsi vous pouvez commander plusieurs prestations dans le même devis. Chaque section est liée à un contrat, et à un nom. C’est ce nom qui sera présenté pour la facturation (vous disposez aussi d’un champ “référence client” que vous pourrez définir après validation du devis. Il faut également préciser à nouveau l’adresse du livraison du service. Un ultime test d’éligibilité est refait juste avant le remplissage de la section.

$sectionParams = (new CreateCommercialOfferSection())
    ->setClientContractId($myContract->getId())
    ->setName("My new final customer");

$eligAddress = new SetCommercialOfferSectionOfferEligibility();
$eligAddress->setAddress("111 Rue Réaumur, 75002 Paris");

$section = $prizzTelecom->createCommercialOfferSection(
    $commercialOffer->getId(),
    $sectionParams
);

$offerParam = new SetCommercialOfferSectionOffer();
$offerParam
    ->setOfferId($offer_id)
    ->setEligibility($eligAddress);

$prizzTelecom->setCommercialOfferSectionOffer(
    $commercialOffer->getId(),
    $section->getId(),
    $offerParam
);

Après cet appel, vous obtenez un devis avec une offre de “base” que vous pouvez déjà consulter dans l’espace client. Vous pouvez la modifier en mettant à jour la section.

Personnalisation : choix du débit, de la durée d’engagement

$itemsParameters = new UpdateCommercialOfferSectionItems();
$itemsParameters ->setBandwidth('100'); // il s'agit du débit en mb/s
$itemsParameters ->setGrt('4HNO'); // c'est la GTR au format : délai en heures suivi de son type HO ou HNO (cf paramètres utiles) 
$update_commercial_offer_section_items->setCommitment('12'); // c'est l'engagement en mois
//$update_commercial_offer_section_items->setExpress('7'); // certaines offres disposent d'une option Express en jours, permettant un raccordement plus rapide contre rémunération.
$prizzTelecom->updateCommercialOfferSectionItems(
    $commercialOffer->getId(),
    $section->getId(),
    $itemsParameters
);

Vous pouvez retourner consulter le devis il doit être à jour.

Demander la validation du devis

Une fois que vous avez terminé les modifications du devis vous pouvez nous le soumettre.

$prizzTelecom->submitCommercialOffer($commercialOffer->getId());

Une fois validé par nos services, la procédure de signature sera lancée. Vous recevrez un code par mail pour confirmer la commande.

Attention

Attention : le contenu du devis peut avoir changé s’il y avait des éléments qui nécessitaient une estimation. Si vous voulez intégrer le mécanisme de signature vous pouvez valider le devis avec le code comme ceci :

$prizzTelecom->signCommercialOffer(
    $commercialOffer->getId(),
    (new SignCommercialOffer())->setCode("123456")
);

2.3.3 - Suivi de commande

Suivre l’avancement d’une commande

Après la signature d’une commande

Une fois que vous avez soumis et signé le devis, il y a une étape de vérification et de validation de celui-ci par nos services. Cette étape terminée, un pack de services, avec une référence de contrat de service, est créé pour chaque section du devis. Il vous est nécessaire de récupérer cette référence de contrat de service afin de pouvoir effectuer le suivi de la commande. Pour cela, il est préférable de créer une cron pour surveiller l’apparition de cette référence.

$commercialOffer = $prizzTelecom->getCommercialOffer($commercialOfferId);
foreach ($commercialOffer->getSections() as $section) {
    $serviceContract = $section->getServiceContract();
}

Suivi de la commande

Une fois la référence de contrat de service récupérée, vous pouvez effectuer le suivi de la commande,

  • soit via l’id du contrat de service $serviceContract = $prizzTelecom->getServiceContract($serviceContract->getId());
  • soit via le nom du contrat de service $serviceContract = $prizzTelecom->getServiceContractByName($serviceContract->getName());

Et voici une partie des informations contenues dans le contrat de service, qui vous permet notamment de suivre l’activation du lien.

$serviceContract = $prizzTelecom->getServiceContract($serviceContractId);
    echo "Nom : ".$serviceContract->getName()."\n";
    echo "RefService : ".$serviceContract->getRefService()."\n";
    echo "RefClient : ".$serviceContract->getRefClient()."\n";
    echo "Statut : ".$serviceContract->getStatus()."\n";
    echo "Date souscription : ".$serviceContract->getSubscriptionDate()->format("Y/m/d H:i:s")."\n";
    echo "Date activation : ".$serviceContract->getActivationDate()->format("Y/m/d H:i:s")."\n";
    echo "Offre : ".$serviceContract->getOffer()->getName()."\n";
    foreach ($serviceContract->getServices() as $service) {
        echo "- Produit : ".$service->getProduct()->getName()."\n";
        echo "- Statut : ".$service->getStatus()."\n";
        echo "- Date activation : ".$service->getActivationDate()->format("Y/m/d H:i:s")."\n";
        echo "- Quantité : ".$service->getQuantity()."\n";
        echo "- Prix unitaire : ".$service->getUnitPrice()."\n";
        echo "- Remise : ".$service->getUnitPriceDiscount()."\n";
        echo "- Adresse : ".$service->getHouseNumber()." ".$service->getHouseNumberComplement()." ".$service->getStreetName()." ".$service->getPostalCode()." ".$service->getCityName()."\n";
    }

2.4 - Obtenir les prix d'une offre sans passer par un devis

Sur vos contrats vous avez accès à des listes de prix, celles-ci ne permettent pas à elles seule de calculer une offre parce qu’il existe des règles (exceptions) qui peuvent faire varier le prix. Jusque là, il fallait passer par la création d’un devis pour connaître le prix définitif (hors FAS a estimer).

Vous pouvez interroger notre API pour obtenir les combinaisons possible sur ces deux endpoint :

  • offers/{id}/contexts
  • offers/{id}/contexts/shortened

et tester votre combinaison d’items sur ce endpoint

  • offers/{id}/context

Obtenir l’ensemble des combinaisons possibles pour une offre

Pour utiliser ces routes ils vous suffit de passer l’identifiant d’une liste de prix, vous pouvez trouver cet identifiant en parcourant la liste de vos contrats en parcourant l’attribut contracts.

Comme il peut il y avoir beaucoup de combinaisons la réponse peut être volumineuse et peut lisible, c’est pourquoi vous pouvez aussi utiliser une version ou chaque proposition est résumée :

Les deux routes prennent les même arguments

Exemple

offers/{idOffre}/contexts?priceList={priceListId}

Les principal combinaisons pour nos offres

Offre Id offre priceList pour Prizz Infrastructures priceList pour Prizz Télécom
L2 PREMIUM 1 24 25
L2 BASIC 5 16 17
L3 INTERNET 4 29

A titre de comparaison, voici un élément de la version résumée

[{
        "offerId": 1,
        "isValid": false,
        "total": 9900,
        "totalWithoutNrc": 9900,
        "items_id": [71,149,73,115,105],
        "hasToEstimateProducts": false,
        "attributes": {
            "offer_type": 1,
            "bw_down": 10,
            "bw_down_guaranteed": 10,
            "bw_up_guaranteed": 10,
            "bw_up": 10,
            "national": 0,
            "commitment_months": 36,
            "construction_time_in_days": 42,
            "eligibility_string": "f1"
        }
	      
}]

et le même dans sa version longue

[{
        "offerId": 1,
        "isValid": false,
        "total": 9900,
        "totalWithoutNrc": 9900,
        "items": [
            {
                "priceListId": 24,
                "product": {
                    "productCode": "pl2",
                    "group": null,
                    "id": 3,
                    "name": "Liaison L2",
                    "attributes": {
                        "offer_type": 1
                    }
                },
                "commercialCode": "pl2",
                "description": "Liaison L2",
                "insideOfferOnly": true,
                "toEstimate": false,
                "active": true,
                "id": 71,
                "createDate": "2024-03-19T15:41:32+01:00",
                "lastModifiedDate": "2024-03-19T15:41:32+01:00",
                "name": "prizzl2",
                "unitPrice": 9900,
                "unitPriceStr": "99.00",
                "unit": null,
                "vat": "TVA_FR_NORMAL",
                "recurrence": "monthly"
            },
            {
                "priceListId": 24,
                "product": {
                    "productCode": "pl2_local",
                    "group": {
                        "type": "national",
                        "name": "national_L2 PREMIUM"
                    },
                    "id": 42,
                    "name": "Liaison L2 collecte locale",
                    "attributes": {
                        "national": 0
                    }
                },
                "commercialCode": "pl2_local",
                "description": "Porte de livraison locale : accès dans la même zone",
                "insideOfferOnly": true,
                "toEstimate": false,
                "active": true,
                "id": 149,
                "createDate": "2024-03-19T15:41:32+01:00",
                "lastModifiedDate": "2024-03-19T15:41:32+01:00",
                "name": "prizzl2_local",
                "unitPrice": 0,
                "unitPriceStr": "0.00",
                "unit": null,
                "vat": "TVA_FR_NORMAL",
                "recurrence": "monthly"
            },
            {
                "priceListId": 24,
                "product": {
                    "productCode": "pl2020",
                    "group": {
                        "type": "bandwidth",
                        "name": "bandwidth_L2 PREMIUM"
                    },
                    "id": 4,
                    "name": "Liaison L2 10Mbps",
                    "attributes": {
                        "bw_down": 10,
                        "bw_down_guaranteed": 10,
                        "bw_up_guaranteed": 10,
                        "bw_up": 10
                    }
                },
                "commercialCode": "pl2020",
                "description": "Débit 10Mb/s",
                "insideOfferOnly": true,
                "toEstimate": false,
                "active": true,
                "id": 73,
                "createDate": "2024-03-19T15:41:32+01:00",
                "lastModifiedDate": "2024-03-19T15:41:32+01:00",
                "name": "prizzl2020",
                "unitPrice": 0,
                "unitPriceStr": "0.00",
                "unit": null,
                "vat": "TVA_FR_NORMAL",
                "recurrence": "monthly"
            },
            {
                "priceListId": 24,
                "product": {
                    "productCode": "pl2_nrc_Z1B",
                    "group": {
                        "type": "nrc",
                        "name": "nrc_L2 PREMIUM"
                    },
                    "id": 25,
                    "name": "Liaison L2 FAS ZONE 1",
                    "attributes": {
                        "construction_time_in_days": 42,
                        "eligibility_string": "f1"
                    }
                },
                "commercialCode": "pl2_nrc_Z1B",
                "description": "FAS ZONE 1",
                "insideOfferOnly": true,
                "toEstimate": false,
                "active": true,
                "id": 115,
                "createDate": "2024-03-19T15:41:32+01:00",
                "lastModifiedDate": "2024-03-19T15:41:32+01:00",
                "name": "prizz Liaison L2 FAS ZONE 1",
                "unitPrice": 0,
                "unitPriceStr": "0.00",
                "unit": null,
                "vat": "TVA_FR_NORMAL",
                "recurrence": null
            },
            {
                "priceListId": 24,
                "product": {
                    "productCode": "pl2_cmt_36",
                    "group": {
                        "type": "commitment",
                        "name": "commitment_L2 PREMIUM"
                    },
                    "id": 20,
                    "name": "Liaison L2 Engagement 36 mois",
                    "attributes": {
                        "commitment_months": 36
                    }
                },
                "commercialCode": "pl2_cmt_36",
                "description": "Engagement 36 mois",
                "insideOfferOnly": true,
                "toEstimate": false,
                "active": true,
                "id": 105,
                "createDate": "2024-03-19T15:41:32+01:00",
                "lastModifiedDate": "2024-03-19T15:41:32+01:00",
                "name": "prizzLiaison L2 Engagement 36 mois",
                "unitPrice": 0,
                "unitPriceStr": "0.00",
                "unit": null,
                "vat": "TVA_FR_NORMAL",
                "recurrence": "monthly"
            }
        ]
    },
    ]

Tester directement une combinaison

Cette route vous permet de tester une combinaison pour une offre que vous formez vous même. Les éléments qui la compose doivent appartenir à la même liste de prix.

offers/1/context?items[]=121&items[]=536&items[]=73&items[]=71&items[]=113&items[]=149

{
    "offerId": 1,
    "isValid": true,
    "total": 104900,
    "totalWithoutNrc": 14900,
    "items": [
        {

L’attribut isValid de la réponse confirme que la combinaison que vous testez est correcte.

A savoir pour construire vos listes d’items

Chez nous, une offre, c’est un item de base associé à une liste d’items qui appartiennent à un groupe qui lui même correspond à un choix que l’on peut faire pour définir un accès. Par exemple, il y a un groupe pour la bande passante, un autre pour la durée d’engagement etc..

Lorsque vous consultez un item d’une liste de prix il faut regarder la clé product qui contient elle même une clé group

En règle général, chaque groupe doit contenir au moins un élément.

Listes des groupes par offre

L2 PREMIUM

type min max
bandwidth 1 1
commitment 1 1
express 0 1
grt 1 1
national 1 1
nrc 1 1

L2 BASIC

type min max
bandwidth 1 1
commitment 1 1
express 0 1
grt 1 1
nrc 1 1

L3 INTERNET

type min max
bandwidth 1 1
commitment 1 1
express 0 1
grt 1 1
nrc 1 1
subnet 1 1

2.5 - Subnet attribué à un L3

Déterminer l’IP attribuée à un service

Sur un contrat de services vous trouverez les détails du subnet attribué à votre service L3.

Les attributs sont placés sur deux clés :

  • la clé consolidatedAttributesStagingOrNew qui contient les valeurs souhaitées pour votre service lorsque celui-ci n’est pas encore livré ou est en cours de mise à jour
  • et la clé consolidatedAttributes contient les valeurs de production.

Exemple :

    ...
    "consolidatedAttributes": {
        "subnet": "192.0.2.24/30",
        "subnet_gateway": "192.0.2.25",
        "subnet_mask": "255.255.255.252",
        "subnet_range": [
            "192.0.2.26"
        ]
    },
    ...

2.6 - Doc de référence

Consulter la documentation généré automatiquement à partir du code de l’API

Elle vous attend là : https://dev.prizz-telecom.fr/openapi-external.html

3 - Legacy API

Documentation de l’ancienne API

Attention : cette API ne doit plus être utilisée pour de nouveaux projets, dorénavant il faut utiliser cette API

Les méthodes de l’API de l’ancien SI sont encore maintenues mais en utilisant l’architecture du nouveau SI.

Les concepts et l’approche de modélisation des données étant sensiblement différents, il peut y avoir quelques différences dans le comportement (voir encadré sur cette page).

Toutes les actions de la nouvelle API (v2) ne sont pas réalisables avec l’ancienne (v1). S’il vous manque une fonctionnalité il faut porter votre regard vers la nouvelle et le cas échéant nous faire remonter le besoin.

Nous insistons sur le fait que le portage de la v1 de l’API est une solution de dépannage pour vous permettre de continuer à utiliser nos services le temps que vous puissiez migrer vers la v2, et nous vous invitons à migrer au plus vite vers la v2 pour bénéficier du confort et de la meilleure expérience possible.

3.1 - Authentification

Obtenir un access token

Attention : cette API ne doit plus être utilisée pour de nouveaux projets, dorénavant il faut utiliser cette API

Le WebService Authentification est composé d’une méthode POST auth se situant à l’adresse suivante :

Cette méthode permet d’obtenir l’access token indispensable pour l’authentification et ainsi pourvoir consommer nos webservices.

La méthode auth prend deux paramètres :

  • email : il s’agit de l’email correspondant au login, il est rattaché aux droits d’utilisation des API dans notre SI.
  • mdp : le mot de passe correspondant.

Exemple d’appel :

curl -X POST "https://my.prizz-telecom.fr/sicom/auth" -H "accept: */*" -H "Content-Type: application/json" -d "{
\"email\": \"votrelogin\", \"mdp\": \"votremotdepasse\"}"

En retour vous obtiendrez l’acces token si votre compte est valide

3.2.1 - Création d'un contact

Création d’un nouveau contact

Cette méthode POST permet d’ajouter un nouveau contact à la liste.

Lors de la création d’une commande, un idContact pourra être indiqué dans le JSON aux endroits suivants pour y rattacher un contact :

  • contactsGTR / idContact : pour être informé des maintenances ou incidents en HO ou HNO
  • idContacts : pour être notifié des commentaires et avancées de la commande
  • idContactCommande : pour indiquer le créateur de la commande

La méthode est accessible : Sur l’environnement de test :

Le descriptif de la méthode est disponible ici :

3.2.2 - Liste des contacts

Obtenir la liste des contacts

Cette méthode GET permet l’obtention des identifiants de contacts opérateur. Ces identifiants seront utilisés lors de l’appel au WS de commande pour indiquer les contacts en suivi de la commande ou à avertir en cas d’incident.

Il est possible de créer de nouveaux contacts via https://my.prizz-telecom.fr/ dans la rubrique Administration/Utilisateurs.

La méthode est accessible : Sur l’environnement de test :

Sur l’environnement de production :

Le descriptif de la méthode est disponible ici :

3.2.3 - Liste des portes

Obtenir la liste des portes de livraison

Cette méthode GET permet l’obtention des codes des portes de livraison.

Sur l’environnement de test :

Sur l’environnement de production :

Il s’agit de la liste des portes de livraison possibles et dont vous devrez nous communiquer le code lors d’une commande de type L2.

Chaque porte est constituée des informations suivantes :

  • code : il s’agit du code de la porte à nous communiquer pour une commande de type L2
  • lib : description de la porte
  • site : localisation de la porte
  • bandwidth : débit de la porte en mb
  • is_default : si true, il s’agit de la porte par défaut sur laquelle nous effectuons la livraison.

Le descriptif de la méthode est disponible ici :

3.2.4 - Souscription FON

Passer une commande de type FON

Cette méthode permettait la prise de commande de type FON.

Elle a été discontinuée pour la V1 de l’API.

3.2.5 - Souscription L2

Passer une commande de type L2

Cette méthode POST permet d’effectuer une commande de type L2.

Sur l’environnement de test :

Sur l’environnement de production :

Détail des attributs du JSON :

  • idOffre : code Offre fourni par les WS éligibilité par la valeur idOffre.
  • idOptions : liste (pouvant être vide) de valeurs fournies par les WS éligibilité par idOption. L’option doit correspondre à l’offre à laquelle elle appartient.
  • contactsGTR : le type doit être soit HO pour Heures Ouvrées soit HNO pour Heures Non Ouvrées. Le contact doit être un contact de la liste des contacts Opérateurs fournie par le WS contacts. Il est possible de créer de nouveaux contacts via https://my.prizz-telecom.fr/ dans la rubrique Administration / Utilisateurs.
  • adresse : il s’agit des informations sur l’adresse à raccorder.
  • contactSite : il s’agit des informations pour contacter la personne nous permettant d’accéder au local du site à raccorder : nom / numéro de téléphone / mail / horaires auxquels nous pouvons joindre la personne.
  • idContactCommande : identifiant du contact correspondant à la personne effectuant la commande (paramètre facultatif).
  • idContacts : liste des contacts assurant le suivi de la commande. Ces contacts recevront les notifications par mail. La liste des contacts Opérateurs possibles est fournie par le WS contacts.
  • infosActivationService :
  • refPorte : valeur correspondant au code de la porte de Livraison fourni par le WS interfaceLivraison. Si vous n’avez pas encore de porte de livraison, merci de contacter l’ADV.
  • siteUtilisateurFinal : liste fermée devant correspondre à l’une des valeurs suivantes : « Transparence aux CVLAN (QinQ) », « Flux tagué C-VLAN », « Flux non tagué »
  • porteLivraison : liste fermée devant correspondre à l’une des valeurs suivantes : « Transparence aux CVLAN (QinQ) », « Flux tagué C-VLAN », « Flux non tagué »
  • interfaceLivraison : chaînes de caractères correspondant à « 10/100/1000 Base T », « 1000 Base SX », « 1000 Base LX » ou éventuellement une autre valeur à indiquer.
  • nvlanSite : Si vous avez choisi « Flux tagué C-VLAN » pour le siteUtilisateurFinal, vous pouvez spécifier un N° de Vlan pour le site.
  • nvlanPorte : Si vous avez choisi « Flux tagué C-VLAN » pour la porteLivraison, vous pouvez spécifier un N° de Vlan pour le site.

En cas de retour “succès”, l’information importante de la réponse est la valeur « ref ». Elle contient la référence commerciale de votre commande et vous permet de retrouver facilement votre commande sur le site https://my.prizztelecom.fr/ ou d’obtenir le suivi de la commande via l’API de suivi.

Le descriptif de la méthode est disponible ici :

3.2.6 - Suivi de commmande

Suivre l’état d’avancement d’une commande

Cette méthode GET permet de suivre l’état d’avancement d’une commande.

Sur l’environnement de test :

La méthode prend donc en paramètre la référence de la commande dont le suivi est souhaité.

Exemple d’appel :

curl -X 'GET' 'http://sandbox.prizz-telecom.fr/sicom/histoCommandes/suivi/XXXXXXXXX -H 'accept: */*' -H 'Authorization: Bearer votreToken

Le descriptif de la méthode est disponible ici :

3.3 - Catalogue

Récupération des offres catalogue

Attention : cette API ne doit plus être utilisée pour de nouveaux projets, dorénavant il faut utiliser cette API

Le WebService Catalogue est composé d’une méthode GET se situant à l’adresse suivante :

Cette méthode permet de lister les offres au catalogue. Il s’agit de l’ensemble des couples « offre – frais d’accès au service » éligibles et possédant un identifiant produit unique idProduit, que l’on peut retrouver dans l’api éligibilité avec l’attribut idOffreFas.

La méthode ne prend aucun paramètre, uniquement le token d’authentification.

Exemple d’appel :

curl -X GET "https://my.prizz-telecom.fr/sicom/catalogues" -H "accept: */*" -H "Authorization: Bearer votreToken"

Le retour est un JSON composé d’une liste de produits composés des attributs suivants :

  • famille : nom de la famille
  • idProduit : identifiant du produit et correspondant à idOffreFas de l’api éligibilité.
  • libelle : libellé du produit
  • engagement : engagement en mois.
  • debitDescendantMax : débit descendant maximal en Mb/s
  • debitDescendantGaranti : débit descendant garanti en Mb/s
  • debitMontantMax : débit montant maximal en Mb/s
  • debitMontantGaranti : débit montant garanti en Mb/s
  • prixHt : prix HT de l’offre
  • prixSurDevis : booléen indiquant si le prix de l’offre est « sur devis »
  • recurrent : booléen indiquant si le prix l’offre est récurrent
  • periodicite : périodicité de l’offre si celle-ci est récurrente
  • zone : zone commerciale
  • fasSurDevis : booléen indiquant si les FAS sont sur devis
  • fas : montant Ht des FAS

Le descriptif de la méthode est disponible ici :

3.4 - Éligibilité

Tests d’éligibilités

Attention : cette API ne doit plus être utilisée pour de nouveaux projets, dorénavant il faut utiliser cette API

Le WebService Eligibilité est composé de deux méthodes POST et elles se situent aux adresses suivantes :

Pour l’environnement de test opérateur :

Pour l’environnement de production :

Éligibilité via une adresse

La première méthode permet de savoir si une adresse donnée est éligible et de connaître les offres disponibles ainsi que le coût des frais d’accès au service.

La méthode eligibilites/operateur prend en paramètre un JSON composé de :

  • codePostal : code postal de l’adresse à tester
  • numero : numéro de la rue
  • rue : le nom de la rue sans le type de voie
  • typeVoie : le type de la voie de l’adresse à tester
  • ville : ville de l’adresse à tester
  • idOffres (facultatif) : liste des identifiants d’offre. L’API filtrera la recherche sur les offres demandées.
  • civilite (facultatif) : civilité de la personne demandant le test d’éligibilité. 1 pour Monsieur 2 pour Madame.
  • nom (facultatif) : nom de la personne demandant le test d’éligibilité.
  • prenom (facultatif) : prénom de la personne demandant le test d’éligibilité.

Exemple d’appel :

curl -X POST "https://my.prizz-telecom.fr/sicom/eligibilites/operateur" -H "accept: */*" -H "Authorization: Bearer
votreToken" -H "Content-Type: application/json" -d "{ \"codePostal\": \"75001\", \"numero\": 14, \"rue\": \"SaintRoch\", \"typeVoie\": \"rue\", \"ville\": \"Paris\"}"

Les descriptifs des méthodes sont disponibles ici :

4 - Lexique

Quelques mots de lexique

Dans cette documentation beaucoup de termes vont se mélanger entre leur version française, et leur notation “machine” anglicisé au sein de l’API. Voici un tableau récapitulatif afin de s’y retrouver :

Français API Note
Catalogue PriceList -
Client ClientLegalEntity -
Contrat client ClientContract Contract associant un client au catalogue d’une société, permettant au client de souscrire aux offres du catalogue
Contrat de service ServiceContract Contrat matérialisant une section de devis une fois celui-ci validé et signé
Devis CommercialOffer -
Facture Invoice -
Offre Offer Une offre catalogue
Processus Workflow Les processus permettant de faire évoluer les états des différents objets
Section CommercialOfferSection Une section de catalogue
Service Service -
Société / Entité légale LegalEntity Une des entitées du groupe Infra-Corp : Prizz Telecom, Prizz Infrastructure, Qotico Telecom…sur lesquelles il est possible de souscrire des services