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_max
ou 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 |
0 |
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 :
- 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.
- soumettre le devis : on va faire des vérifications, et donner un prix aux éléments qui nécessite une quotation
- 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 :
- commencer un devis pour un ClientLegalEntity
- 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é
- ajouter une autre section en reprenant à l’étape 2 (si nécessaire)
- soumettre le devis : on va faire des vérifications, et donner un prix aux éléments qui nécessite une quotation
- 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
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 - Commande
Actions concernant les commandes
Le WebService Commande est composé de plusieurs méthodes et elles se situent aux adresses suivantes :
Pour l’environnement de test opérateur :
Pour l’environnement de production :
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 |