PHP SDK
The Fatture in Cloud PHP SDK is a PHP library that offers models and methods to interact with the Fatture in Cloud v2 REST API.
If you want to know more generic information about our SDKs, please check the SDK Overview page.
☑️ Requirements and Dependencies
This SDK supports PHP 7.1 and later. It is mainly based on the Guzzle HTTP Client.
⬇️ Download and Installation
The SDK code and detailed documentation can be found in the GitHub repository.
🎻 Installation with Composer
The SDK is published into Packagist and it can be installed using Composer:
composer require fattureincloud/fattureincloud-php-sdk
Make sure you always import the newest version of our SDK, you can check which version is the latest on Packagist
🔧 Installation without Composer
If you can't install our library using composer there are three routes you can take:
- the first and recommended one is to download the latest release of the sdk Phar Archive, then you can simply include it in your project.
require_once('./fattureincloud-php-sdk.phar');
- the second route is to download our sdk using php-download and include it in your project
- the third route is to create your own custom autoloader and download all the dependencies (transitive included) as explained here.
👷 SDK Structure
Our SDK is mainly split into two different packages:
- Api: Here you can find the classes that implement our API methods, you will need an instance of one of those classes to actually call our APIs.
- Model: This package contains all the classes that represent our API requests and responses; when using one of the methods above, you'll have to manage some of those classes.
There are some special classes in the Model package:
- The classes with a name ending for Request can be used as request body for one of our methods.
- The classes with a name ending for Response will be returned after the execution of one of the methods. Instances of all the other classes will be used to compose the requests or responses for our methods.
You can think about Request and Response classes as wrappers: each one of them are dedicated to a single method of the API, and they will most of the time contain a single attribute called data, that contains the real body of the request or the response represented through a composition of the other classes. Each method will accept at most one instance of the Request classes and will return at most one instance of the Response classes.
Let's take for example the Modify Supplier method.
It is included in the SuppliersApi class, it accepts one instance of the ModifySupplierRequest class and it returns an instance of the ModifySupplierResponse class. In both cases, the data parameter will contain an instance of the Supplier class, that represents the modifies to apply to the supplier (for the request) and the final status of the supplier (for the response).
In contrast, the List Suppliers method is still contained in the SuppliersApi class, but it doesn't need any request body and returns a single instance of the ListSuppliersResponse class, where the data parameter will contain an array of instances of the Supplier class.
📢 API calls
The API methods can be categorized as follows:
Category (prefix) | Request Body | Response Body | Notes |
---|---|---|---|
List (list) | ❌ | ✅ | 🎩 + 🔃 + 📃 + 🏷 |
Create (create) | ✅ | ✅ | |
Get (get) | ❌ | ✅ |