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) | ❌ | ✅ | 🎩 |
| Modify (modify) | ✅ | ✅ | |
| Delete (delete) | ❌ | ❌ |
In addition to the Request, every method could require some additional parameters like the IDs of the company and of the resource.
In this example, we'll suppose you have to manage just one Company, so we simply inserted its ID directly in the code. If instead, you need to be able to manage multiple companies, you'll need to retrieve the ID of the current company in some way. Check the Company-scoped Methods page for more info. Additionally, the PHP Quickstart contains an example of Company ID retrieval using the SDK.
🎩 Response customization
The List and Post methods include some parameters dedicated to the response customization. These parameters are passed as method arguments.
🔃 Sorting
The List methods are a particular case because they are related to a set of resources instead of a single one; this means that the API will need to assign an order to the resources that will be returned. If needed, you can explicitly define a sorting rule by passing the scope parameter.
📃 Pagination
Strictly related to the Sorting functionality is the Pagination. The List methods return a potentially huge set of resources, making it necessary to paginate the results to make the responses manageable; each method will then accept an additional set of pagination parameters, and the Response classes will contain some pagination details along with the data parameter.
🏷 Filtering
By default, the List methods will return the whole set of available resources for a certain method. If you instead want to focus on a particular subset of resources, you can apply specific filters to reduce the size of the result and retrieve only what you need.