
Integrator for Lucca
Integrating the Lucca API into your system
We connect Lucca to your business applications: leave, time tracking, expense claims and employee records. An event-driven architecture that holds under the 50 requests per minute cap, not an overnight sweep that breaks.
- Senior product team
- HRIS connectors in production
- from scoping to monitoring
Why work with a Lucca integrator and what can be connected to Lucca?
Lucca is a modular HRIS used by companies of all sizes to manage leave, time, expense reports, payroll and training. A Lucca integrator connects Lucca to your production planning tool, accounting software, access directory or data warehouse. The work involves syncing absences for planning, exporting payroll variables to the accounting software, or feeding an HR dashboard with consolidated data. The Lucca API covers all modules, with particular attention to rights management by file and shared quotas.
What a Lucca integration unlocks
Schedules adjusted on every approved leave
As soon as leave is approved, production or site planning frees the assignment. You stop discovering an absence the same morning.
Automated onboarding and offboarding
The Lucca employee directory triggers the creation, then the revocation, of application accounts, with an auditable log of every access opened.
Profitability per project
Time entered in Timmi and expenses in Cleemy meet the revenue held in the CRM. Margin per project becomes visible continuously.
Approvals from the manager's own tool
Leave requests are approved or refused from your application, without forcing your managers into yet another login.
What a Lucca integration changes for your business
Engineering in service of a measurable outcome: less HR re-entry, accurate schedules, access under control.
One single entry, everywhere
HR data is entered once in Lucca and travels on its own. Retyping time disappears, and the gaps between your tools go with it.
Schedules that match reality
Approved absences reach the scheduling tool straight away. You stop assigning work to someone who is not there.
Access that actually closes
A departure recorded in Lucca revokes the application accounts. Ghost accounts leave your exposure surface.
A connector that belongs to you
Code delivered, documented and maintainable. You are not locked into a black box or a subscription to a generic connector.
How we connect Lucca to your system
Scoping
Which Lucca modules, which API generation per resource, which establishment scope on the integration key. We settle the direction of every flow before coding.
Architecture
Webhooks for events, filtered incremental reads for catch-up, a central rate limiter. The 50 requests per minute cap is a design constraint, not a detail.
Development and testing
A single access layer hiding v3, v4 and v5, idempotent webhook handling, a retry queue. Replay on a pseudonymised dataset.
Monitoring
Alerts on delivery failures, a quota consumption counter, a health dashboard. You know a flow is broken before your HR team does.
What Lucca allows
- Leave and balances
- Reading leave and leave accounts, creating and updating them, plus leave requests and their approval or refusal decisions.
- Employee records
- Users, employment contracts, departments, legal entities and establishments. The single source for arrivals and departures.
- Time, projects and expenses
- The Timmi and Cleemy modules expose logged time, project allocation, office presence and expense claims with their cost centre.
- Event webhooks
- Notifications on employee creation, employment creation, job position opening or leave update, with at-least-once delivery.
The vocabulary of a Lucca integration
- Tenant
- Your Lucca instance, identified by its domain. Every call URL depends on it, and the rate limit applies to that domain rather than to your application.
- Integration key
- The declaration carrying the technical contact, the OAuth scopes and the list of accessible establishments. An establishment created later does not automatically fall inside the scope.
- Api-Version
- The header that pins the dated version of the new API. Without it, a change on the Lucca side can shift a response under your feet.
- Legacy v3 and v4
- The two earlier generations, still in service. You recognise them from the URL, and they share neither the same paging nor the same way of selecting fields.
- Business establishment
- The establishment as defined in v5, which replaces the older legal entity and establishment notions. A connector written on the old ones will have to be reworked.
- At-least-once delivery
- The same webhook can arrive twice and out of order. Handling has to be idempotent and reordered by the event occurrence date.
The real constraints of a Lucca integration
50 requests per minute, shared across the domain
The cap applies to the tenant, not to your application: integrations from other providers consume it too. Beyond it, the API answers 429. That rules out any full sweep of the reference data.
Five seconds of server execution
A longer request is cut off and returns 408. An overly broad request is therefore not merely slow, it fails: filtering and paging belong in the design.
The new API does not cover everything yet
Organisation and leave sit in v5, but time, expenses, training and compensation remain in Legacy v3 and v4, whose documentation admits inconsistencies between endpoints. Successive migrations have to be budgeted.
The sandbox is a paid option
There is a single test environment per account, refreshing it from production goes through support, and authorised applications are not duplicated there: keys have to be declared again.
Lucca or Silae, and what it implies
Both live in the same HR chain but do not play the same role. The choice is almost never technical: it depends on who holds the data and who runs payroll.
| Criterion | LuccaThis page | SilaePayroll engine |
|---|---|---|
| Role in the chain | HRIS: leave, time, expenses, employee records | Payroll production and filings |
| Opening access | Integration key created inside your instance | Signed contract and opening form, through a partner |
| Authentication | OAuth 2.0, token valid for 30 minutes | OAuth 2.0, token valid for 60 minutes, plus a subscription key |
| Shape of the API | REST resources, two generations side by side | A catalogue of named functions, several versions per function |
| Documented limit | 50 requests per minute per domain | 60 tokens per minute on authentication |
| Real time | Event webhooks | Asynchronous pattern with status polling |
| The right case | Plugging a schedule, a directory or project tracking into HR data | Automating variable collection and the payroll accounting entry |
We claim neither a Lucca certification nor partner status: we build on the documented public API, as the development team on your integration. The two tools are often combined rather than opposed.
What we measure on a Lucca project
The other payroll and HRIS tools
The choice follows whichever tool you already run, and who produces the payroll.
LuccaIntegrating the Lucca API into your systemThis page
SilaeThe payroll engine behind many accounting firms, with tightly framed access.
PayFitPayroll and HR in one tool, common in SMEs that keep payroll in-house.We combine Lucca with
The stack that surrounds Lucca on our projects.
Lucca integration: your questions
Three steps. First create an integration key inside your Lucca instance, with the technical contact, the OAuth scopes you need and the list of establishments to cover. Then obtain a client credentials token and cache it for its 30 minutes of validity, pinning the API version in the headers. Finally declare your webhook endpoints and build the sync around events, with a filtered incremental read for catch-up. The real difficulty is not the technical call, it is staying inside 50 requests per minute while covering resources spread over three API generations.
It depends on the modules involved, the direction of the flows and which API generation each resource requires. Pushing approved leave into a scheduling tool costs far less than a full chain mixing Timmi time, Cleemy expenses and employee records, each on a different convention. The cost of the test environment also weighs in, since the Lucca sandbox is a paid option. We scope the perimeter up front and give a firm estimate before we start.
Certification is a vendor's commercial label, useful when rolling out the HRIS itself. To connect Lucca to a custom application, what counts is experience with connectors under quota pressure and rigour on webhook handling. We claim no Lucca partner status: we build on the documented public API and act as the development team on the integration, alongside your HR team.
Yes, and it is a frequent request. The principle is to make Lucca the source of collected items (absences, time, variable elements) and the payroll software the engine that consumes them. That means handling two different worlds: REST resources under a tight quota on the Lucca side, and often contractual access with its own lead times on the payroll side. We build the connector with a deduplication key stored outside both tools, so a replay never pushes the same item twice for the same period.
Two documented limits shape the whole architecture. Throughput is capped at 50 requests per minute per domain, and that cap is shared with the other integrations on your instance, including those of other providers. Server-side execution time is capped at five seconds, which makes an overly broad request fail rather than run slowly. On top of that come the webhook constraints: three seconds to acknowledge, up to five delivery attempts spread over roughly 24 hours, at-least-once delivery and no ordering guarantee. So the design is event-driven with reconciliation, never a full sweep.
A Lucca integration project?
Let's talk. 30 minutes to identify your Lucca modules, check what the API generation covers and tell you honestly what is feasible.
Discuss my Lucca project