Iplicit API
Iplicit API gives your Drupal site an authenticated client for the Iplicit cloud accounting API.
Other modules can then read and write your Iplicit data, everything from contacts and customer accounts through to products, prices, sale quotes and orders, invoices, payments and receipts, without anyone having to work out the login flow, the session tokens, the mandatory Domain header or where to keep the credentials.
It is a generic API client rather than a finished integration. What you get is one settings page and a set of services: no content types, no fields, nothing syncing away on its own. If what you want is to push Commerce orders into Iplicit, that belongs in a separate module which depends on this one.
How it works
Iplicit will not accept an API key on every call. Instead you log in with a domain, a username and an API key, you get back a session token that lasts about thirty minutes, and you have to send a Domain header with every request after that.
The session manager takes care of logging in and caches the token until it expires, so you end up logging in roughly twice an hour rather than on every single request. The client adds the token and the Domain header to each request, reads Iplicit's ProblemDetails error bodies and throws typed exceptions when something goes wrong. If a cached token comes back with a 401, it quietly logs in again and has one more go.
Sitting above the client are 28 resource classes, one for each Iplicit API tag. They are generated from Iplicit's pinned OpenAPI specification, so the method names, path parameters and pagination arguments match the real API rather than somebody's best guess at it. Every method carries a @see link straight to its page in the Iplicit API documentation.
Developer documentation
The module's README.md is where the detail lives. It covers:
- Credentials, installation and configuring things per environment
- Wiring resource classes into your own module
- Pagination and error handling
- Why you should call this from the background rather than during a page request
- Regenerating the resource layer from the OpenAPI specification
For endpoints, request bodies and what the fields actually mean, head over to the Iplicit API documentation.
Features
- Session handling: Tokens are cached in the default cache bin and reused until they expire, and if one gets rejected the client simply logs in again
- Key module integration: Only the key ID goes into
iplicit_api.settings, sodrush config:exportnever writes your secret out toconfig/sync - Full endpoint coverage: 28 resource classes and 183 methods, all generated from the OpenAPI specification
- Plain arrays: Methods take and return decoded arrays, so when Iplicit adds a field to a response you can read it straight away rather than waiting for a module update
- Typed exceptions: Everything that goes wrong implements
IplicitExceptionInterface, with narrower classes for configuration, authentication and request problems - Logging: Failures go to the
iplicit_apichannel with the method, URI, status and error body. Credentials are always redacted - Connection test: A Save and test connection button tells you the domain, the API version and when the token expires
Configuration
There is just the one settings page, at Configuration → Web services → Iplicit API (/admin/config/services/iplicit), sitting behind the restricted Administer Iplicit API permission.
- Enable the Iplicit API: turn this off and the site makes no calls to Iplicit whatsoever
- Base URI, domain and username: the connection details Iplicit gives you
- API key: a key supplied by the Key module
- Advanced: request timeout, debug logging, and logging of successful responses
The resource classes are not registered as services, because most sites only ever use a handful of the 28. Register the ones you need in your own module.
Requirements
- Drupal 10.3 or later, or Drupal 11
- PHP 8.3 or later
- Key 1.19 or later, which Composer installs for you
- An Iplicit account with API access. The Iplicit API documentation is the place to start