API Developers

API Rest

L'"API Developers Back-office" ou DBO permet aux développeurs d'interfacer la Plateforme avec leurs applications grâce à une API sous forme de Web service.

Cette API leur fournit un accès direct et sécurisé aux données de tous leurs sites. Ils peuvent également créer des applications pour des tiers.

L'accès à l'API se fait via l'url https://api.kiubi.com et nécessite un compte sur la plateforme pour requêter et accéder aux données.

Tous les accès se font grâce à HTTPS, via une adresse unique: https://api.kiubi.com

$ curl -i https://api.kiubi.com/v1/sites.json

HTTP/1.1 200 OK
Date: Tue, 30 Jul 2013 08:25:32 GMT
Server: Apache
Content-Type: application/json
Connection: keep-alive
Status: 200 OK
Content-Length: 5
Cache-Control: max-age=0, private, must-revalidate

{
…
}

Le Sandbox

Le Sandbox est une vue fonctionnelle et documentée de toutes les fonctions disponibles via l'API DBO de la plateforme. Toutes les fonctions sont regroupées thématiquement. Chacune de ces fonctions est ensuite détaillée : description, URL, arguments attendus, contenu attendu dans la réponse, codes erreur possibles. Un bouton "Tester" permet de créer une requête vers l'API du site et de récupérer toutes les données de la réponse.

Le Sandbox est à la fois la documentation de l'API et aussi un outil de prototypage pour vos développements.

L'accès au Sandbox est public, tous les internautes peuvent consulter la liste des fonctions et leur documentation. Il est disponible à l'adresse : https://api.kiubi.com/console.

Pour tester les requêtes sur vos sites il est nécessaire de s'identifier au préalable. Pour cela, cliquez sur le bouton "Authentification". Vous êtes alors redirigé vers un formulaire d'identification où vous devez indiquer les identifiants et mot de passe de votre utilisateur sur la plateforme. Vous serez redirigé vers le Sandbox en mode connecté et pourrez effectuer des requêtes avec l'API.

Premier test

Pour un premier test, récupérons la liste des sites du compte. Pour cela, cliquez sur le lien "Authentification" en haut du Sandbox et connectez-vous à Kiubi. Vous serez alors redirigé vers le Sandbox en étant connecté.

Cliquez sur la ligne "sites" pour la déplier, puis sur "GET /sites.json" pour utiliser ce point d'entrée.

Cliquez sur le bouton "Tester". Le Sandbox va alors envoyer une requête à l'API et afficher le retour au format JSON dans le champ texte Response Body. Toutes les informations propres à la réponse comme les entêtes HTTP et le code HTTP sont également affichées. Le champ Request URL indique l'adresse de la requête qui a été utilisée. La liste des sites se trouve dans le nœud data de la réponse. Une réponse contient toujours les nœuds suivants :

  • meta : informations sur la réponse elle même
  • error : erreurs éventuelles
  • data : données de la réponse

Client PHP

Nous fournissons un client PHP pour vous connecter à l'API DBO. Les sources et la documentation du client sont disponibles sur GitHub à l'adresse suivante : https://github.com/Kiubi/api-dbo-PHP.

Le client requiert à minima la version 5.2 de PHP avec l'extension cURL.

Génération d'une clé personnelle

La gestion des clés personnelles de l'API DBO se trouve sur la page API de l'Espace prestataire. Chaque utilisateur peut créer, modifier et supprimer ses clés personnelles dans la limite de 10 clés par utilisateur.

Il est conseillé de générer une clé différente pour chaque application utilisée.

Chaque clé personnelle doit rester secrète car elle permet d'accéder à l'ensemble des données accessibles par l'utilisateur.

Exemples d'intégration

Récupération des 10 dernières commandes à traiter :

include 'kiubi_api_dbo_client.php';
$API = new Kiubi_API_DBO_Client('XXXXXXXXXXXXXX');
$response = $API->get('sites/monsite/checkout/orders.json?status=pending&limit=10&extra_fields=price_label');
if($response->hasSucceed()) {
    $orders = $response->getData();
}

Mise à jour des informations du compte :

include 'kiubi_api_dbo_client.php';
$API = new Kiubi_API_DBO_Client('XXXXXXXXXXXXXX');
$API->put('account/contact.json?firstname=John&lastname=Doe');

Paramètres

Les méthodes de l'API supportent pour la plupart des paramètres optionnels. Pour les requêtes GET, ces paramètres sont à reporter dans l'URL. Par exemple :

$ curl -i "https://api.kiubi.com/v1/sites.json?term=demo"

Pour les requêtes POST, les paramètres non inclus dans l'URL peuvent être passés dans le corps de la requête. Ils devront être encodés selon la RFC 1738 et l'entête de la requête devra contenir un Content-Type à application/x-www-form-urlencoded. Par exemple :

$ curl -i -d "name=Menu%20secondaire" "https://api.kiubi.com/v1/sites/monsite/cms/menus.json"

Paramètres courants

Les paramètres suivants sont utilisés très largement dans l'API et ont un fonctionnement homogène.

Paramètre Description Valeurs
extra_fields Ce paramètre permet d'augmenter le périmètre d'une réponse en ajoutant des informations complémentaires. Liste d'options séparées par des virgules
sort Ordre de tri des résultats de la réponse. Critère de tri. Pour utiliser le même critère mais décroissant, préfixer avec le caractère "-"
limit, page Paramètres de contrôle de la pagination des réponses Cf section Pagination

Paramètres optionnels de compatibilité

Les paramètres suivants sont communs à toutes les méthodes de l'API. Ils permettent d'adapter le fonctionnement de l'API à des clients n'implémentant pas tout le protocole HTTP ou avec des contraintes trop importantes pour le développeur.

Paramètre Description Valeurs
method Pour les clients ne supportant pas toutes les méthodes HTTP, il est possible d'utiliser le paramètre method pour simuler l'utilisation d'une méthode.
Une requête GET avec un paramètre method=PUT sera donc considérée par l'API comme une requête PUT. GET, POST, PUT ou DELETE
callback Nom du callback pour obtenir une réponse au format json-p. Chaine de caractères
suppress_response_code Si ce paramètre est à true, l'API désactive l'utilisation sémantique des codes HTTP. Toutes les requêtes renverront en entête un code HTTP 200 OK. Le code HTTP initialement prévu reste néanmoins lisible dans le corps de la réponse. Le bon ou mauvais déroulement d'une requête devra donc être manuellement vérifié dans les messages contenus dans le corps de la requête. Seule une indisponibilité technique de l'API peut tout de même retourner une erreur de type 500. "true" ou "false". Par défaut à "false"
force_response_mime Si ce paramètre est renseigné, le mime/type par défaut application/json du format de sortie sera substitué par cette valeur. "text/plain" ou "text/html"

Réponses

Le corps des réponses respecte une structure commune. Une réponse simple peut être la suivante :

$ curl -i https://api.kiubi.com/v1/sites.json

HTTP/1.1 200 OK
Server: Apache
Date: Tue, 30 Jul 2013 08:25:32 GMT
Content-Type: application/json
Connection: keep-alive
Status: 200 OK
Content-Length: 172
Cache-Control: max-age=0, private, must-revalidate

{
    meta: {
        success: true,
        status_code: 200,
        link: [],
        rate_limit: 1000,
        rate_remaining: 1000
    },
    error: [],
    data: [
        {
        …
        }
    ]
}

Le corps de la réponse est constitué d'un objet meta qui contient des informations relatives à la requête ainsi qu'un objet data qui contient les données qu'on souhaite récupérer. Son contenu est propre à chaque méthode de l'API.

Description du noeud META

Paramètre Description Toujours présent Valeur
meta.succes Renseigne sur le succès ou l'échec de l'appel. A la moindre erreur, le paramètre est à "false". Oui "true" ou "false"
meta.status_code Code HTTP de la réponse. Si le paramètre suppress_response_code a été utilisé dans la requête, le développeur trouvera ici le code HTTP initial de la réponse. Oui Code HTTP sur 3 chiffres.
meta.link Groupe de lien hypermédia. Explicite les interactions possibles avec la réponse. L'utilisation la plus courante est la pagination des résultats. Oui (peut être vide) Liste d'URL
meta.rate_limit Quota maximum de requêtes Oui Entier
meta.rate_remaining Nombre de requêtes restantes Oui Entier

En cas d'erreur la propriété meta.succes est à false. La réponse contient alors des paramètres supplémentaires. Un exemple de réponse avec erreur est :

$ curl -i https://api.kiubi.com /v1/sites/notfound.json

HTTP/1.1 200 OK
Server: Apache
Date: Tue, 30 Jul 2013 08:25:32 GMT
Content-Type: application/json; charset=iso-8859-1
Connection: keep-alive
Status: 200 OK
Content-Length: 5
Cache-Control: max-age=0, private, must-revalidate

{
    meta: {
        success: false,
        status_code: 404,
        link: [],
        rate_limit: 120,
        rate_remaining: 120
    },
    error: {
        code: 4401,
        message: "Le site n'existe pas",
        help: ,
        fields: []
    },
    data: null
}

Une réponse d'erreur contient des paramètres d'erreur supplémentaires.

Description du noeud ERROR

Paramètre Description Toujours présent EN CAS d'ERREUR Valeur
Error.code Numéro de l'erreur rencontrée Oui Entier
Error.message Message d'erreur global. Typiquement une phrase. Oui Chaine de caractères
Error.help Lien vers une page de l'aide permettant de résoudre l'erreur Oui URL
Error.fields Liste détaillée des erreurs. Oui Tableau
Error.fields.[n].message Message d'erreur Oui Chaine de caractères
Error.fields.[n].field Paramètre de la requête à l'origine de l'erreur Oui Chaine de caractères
Error.fields.[n].extra Eventuelles précisions sur l'erreur Non Variable

Codes HTTP

Code HTTP Signification
200 La requête s'est bien déroulée
301 Redirection permanente
302 Redirection temporaire
304 Ressource non modifiée depuis la dernière requête
400 La syntaxe de la requête est erronée
403 Accès refusé
404 Ressource non trouvée
405 Méthode HTTP non autorisée
413 La requête est trop volumineuse
500 Erreur interne du serveur
503 Service temporairement indisponible ou en maintenance

Format et Encodage

La réponse d'une requête api est encodée en UTF-8. En cas d'erreur d'encodage, l'API renvoie une erreur "Caractère non autorisé" et un code HTTP 400.

Format des dates

Le fuseau horaire de l'API est "Europe/Paris". Toutes les dates et heures s'entendent dans ce fuseau aussi bien à la lecture qu'à l'écriture de données.

Toutes les dates sont retournées aux formats suivants :

Champ Format Exemple
champ YYYY-MM-DD 2012-04-23

Toutes les dates horodatées sont retournées aux formats :

Champ Format Exemple
champ YYYY-MM-DD HH:II:SS 2012-04-23 12:54:03
champ+'_timestamp' Timestamp unix 1335178443

Format de retour

L'API supporte le format JSON. Le format de retour est précisé dans l'URL de la requête par l'extension indiquée (.json).

Sans extension, le format de la réponse est par défaut le JSON. Le format de réponse est également reprécisé dans l'entête Content-Type (application/json).

Pour des besoins de rétrocompatibilité, le Content-Type peut être forcé à text/plain ou text/html, à l'aide du paramètre force_response_mime.

Authentification

Un token d'authentification (ou clé personnelle) est obligatoire pour chaque requête sur l'api DBO. Ce token peut être passé en paramètre ou en entête.

En entête :

$ curl https://api.kiubi.com/v1/sites.json?access_token=XXXX

En paramètre :

$ curl https://api.kiubi.com/v1/sites.json -H 'Authorization: token XXXX'

Obtention d'un token

Les tokens des utilisateurs sont gérés dans le backoffice. L'API permet également d'obtenir un token temporaire, valable 24 heures en échange du login et mot de passe d'un utilisateur :

$ curl https://api.kiubi.com/v1/auth/token.json?method=POST&login=...&password=...

{
  "meta": {
    "success": true,
    "status_code": 200,
    "rate_limit": 1000,
    "rate_remaining": 1000,
    "link": []
  },
  "error": [],
  "data": {
    "token": "...TOKEN...",
    "expiration_date": '2019-02-11 14:21:55',
    ...
  }
}

Le token est retourné dans le champ data.token. Attention toute fois à bien anticiper la date d'expiration de ce token indiqué dans le champ data.expiration_date.

Hypermédia

Les réponses contiennent un paramètre meta.link qui peut contenir un ensemble de liens contextuels à la ressource. Ces liens explicitent les URLs vers les ressources directement liés à la ressource courante.

Les développeurs sont vivement encouragés à suivre ces liens plutôt qu'à les reconstruire eux-mêmes. Cela facilite également la prise en compte d'évolutions futures de l'API.

Pagination

Les ressources retournant une liste d'éléments sont paginées. Par défaut, une page est composée de 20 éléments. Le paramètre limit des requêtes permet de diminuer cette valeur ou de l'augmenter (typiquement jusqu'à 40, mais certaines requêtes supportent plus). Une valeur supérieure à la limite maximale sera refusée.

Le paramètre page contrôle le numéro de page. Les pages sont numérotées à partir de 0 avec une valeur croissante. La première page a le numéro 0, la deuxième le 1, etc.

Paramètre Description Valeur
limit Nombre d'éléments par page Entier de 1 à 40. 20 par défaut.
page Numéro de la page Entier à partir de 0. 0 par défaut.

Les ressources paginées contiennent des liens de pagination évitant au développeur d'avoir à les construire lui même. Ces liens reprennent tous les paramètres indiqués par la requête initiale :

Paramètre Description Valeur
meta.link.first_page Lien vers la première page URL
meta.link.next_page Lien vers la page suivante Contient une URL sauf pour la dernière page ou le paramètre est à "false".
meta.link.previous_page Lien vers la page précédente Contient une URL sauf pour la première page ou le paramètre est à "false"
meta.link.last_page Lien vers la dernière page URL
meta.items_count Nombre d'éléments total Entier
meta.items_per_page Nombre d'éléments par page Entier
meta.current_page Page courante Entier

Cache

L'API supporte les mécanismes de cache HTTP. Les réponses sont accompagnées d'entêtes de cache que le développeur devrait respecter. Les entêtes ETag et Last-Modified peuvent être utilisée indifféremment dans les réponses.

Si une de ces entêtes est présente et que la ressource n'a pas été modifiée depuis le dernier appel, une réponse "304 Not Modified" sera alors retournée en réponse. Les réponses 304 ne sont pas comptabilisées dans le quota d'utilisation de l'API, c'est un très bon moyen d'optimiser sa consommation.

Etag

Une réponse peut contenir une entête Etag qui indique un numéro de série. Pour tout rappel ultérieur d'une même ressource, il est fortement conseillé au développeur d'inclure dans sa requête une entête If-None-Match contenant le numéro de série de l'élément.

$ curl -i https://api.kiubi.com/v1/sites.json

HTTP/1.1 200 OK
Cache-Control: private, max-age=60
ETag: "644b5b0155e6404a9cc4bd9d8b1ae730"
Status: 200 OK
Vary: Accept, Authorization, Cookie

$ curl -i https://api.kiubi.com/v1/blog/posts.json -H 'If-None-Match: "644b5b0155e6404a9cc4bd9d8b1ae730"'

HTTP/1.1 304 Not Modified
Cache-Control: private, max-age=60
ETag: "644b5b0155e6404a9cc4bd9d8b1ae730"
Last-Modified: Thu, 23 Jul 2013 11:25:05 GMT
Status: 304 Not Modified
Vary: Accept, Authorization, Cookie

Last-Modified

Une réponse peut contenir une entête Last-Modified qui indique une date. Pour tout rappel ultérieur d'une même ressource, il est fortement conseillé au développeur d'inclure dans sa requête une entête If-Modified-Since contenant cette date.

$ curl -i https://api.kiubi.com/v1/blog/posts.json

HTTP/1.1 200 OK
Cache-Control: private, max-age=60
Last-Modified: Thu, 23 Jul 2013 11:25:05 GMT
Status: 200 OK
Vary: Accept, Authorization, Cookie

$ curl -i https://api.kiubi.com/v1/blog/posts.json -H "If-Modified-Since: Thu, 23 Jul 2013 11:25:05 GMT"

HTTP/1.1 304 Not Modified
Cache-Control: private, max-age=60
Last-Modified: Thu, 23 Jul 2013 11:25:05 GMT
Status: 304 Not Modified
Vary: Accept, Authorization, Cookie

Redirections

L'API peut utiliser les mécanismes de redirection HTTP (codes HTTP 301 et 302) lorsque cela est nécessaire. Le développeur devra toujours prévoir l'éventualité de recevoir une redirection en réponse à une de ses requêtes. Dans ce cas la réponse contient une entête Location qui indique l'URL à laquelle le développeur est invité à renvoyer sa requête. Un exemple de redirection :

HTTP/1.1 301 REDIRECT PERMANENT
Server: Apache
Date: Tue, 30 Jul 2013 08:25:32 GMT
Content-Type: application/json; charset=iso-8859-1
Connection: keep-alive
Status: 200 OK
ETag: "a00049ba79152d03380c34652f2cb612"
Location: "/v1/new/endpoint.json"
Content-Length: 5
Cache-Control: max-age=0, private, must-revalidate

{
    meta : {
        success : true,
        status_code : 301,
        link : { location : "/v1/new/endpoint.json" },
        rate_limit: 120,
        rate_remaining: 120
    },
    data : null
}

Le paramètre meta.link.location reprend la valeur de l'entête Location. Si le paramètre suppress_response_code est à true dans la requête, le code HTTP est un code 200. Il revient au développeur de tester le statut présent dans meta.link.status_code et de refaire un appel à l'URL indiquée dans meta.link.location.

Redirection 301 : c'est une redirection permanente. Toutes les requêtes vers la ressource désignée devront s'effectuer sur la nouvelle URL.

Redirection 302 : l'utilisation d'une nouvelle URL est temporairement nécessaire. L'URL d'origine est cependant toujours à utiliser pour adresse la ressource.

Les réponses 301 & 302 ne sont pas comptabilisées dans le quota d'utilisation de l'API.

Quota

Le quota d'utilisation de l'API DBO a été fixé pour en permettre une utilisation confortable. Chaque clé donne droit à 1 000 requêtes sur une durée de 15 minutes. A chaque requête, le nombre de requêtes restantes est décrémenté de 1. Au bout de 15 minutes, le quota est restauré à 1 000.

La quantité de requêtes restantes est indiquée dans chaque réponse dans le noeud meta.rate_remaining. Le point d'entrée /rate permet également de récupérer cette valeur sans consommer de quota.

$ curl -i https://api.kiubi.com/v1/rate.json

HTTP/1.1 200 OK
Date: Tue, 30 Jul 2013 09:12:01 GMT
Content-Length: 114
Content-Type: application/json

{
    meta: {
        success:true,
        status_code:200,
        link:[],
        rate_limit: 1000,
        rate_remaining: 1000
    },
    error:[],
    data:null
}

En cas de dépassement de quota, l'API renverra une erreur 403 :

$ curl https://api.kiubi.com/v1/sites.json

{
    meta: {
        success: false,
        status_code: 403,
        rate_limit: 1000,
        rate_remaining: 0,
        link: []
    },
    error: {
        code: 4300,
        message: "Vous avez épuisé votre quota de requête, attendez quelques minutes pour restaurer votre quota.",
        help: ,
        fields: []
    },
    data: null
}

Les requêtes qui ne consomment pas de quota sont celles vers le point d'entrée /v1/rate ou celle générant une réponse 301, 302 ou 304 (cf. sections Cache et Redirections). L'utilisation du cache est le meilleur moyen de limiter sa consommation.

Si ces quotas sont insuffisants pour votre site, contactez nous !