This document describes the known limitations of the iPaaS.com integration with Clockify at the time this documentation was written. They come from the current integration design and from what the Clockify API offers, and they apply to all subscribers using this integration.

Employee, Timesheet and Timesheet Entry move from Clockify TO iPaaS.com only. Clockify members and time are never created, changed or removed FROM iPaaS.com, and a FROM iPaaS.com mapping collection for them is refused with CLKF-BIZL-1004. Customer Company is the only data written to Clockify, as Clockify clients. Clockify projects, tasks, tags, expenses and invoices are not transferred as records of their own; a time entry carries its project, client and task names.

What this means for you: Use Clockify as the place where members and time are managed. Changes to employees or timesheets made in iPaaS.com, or in another system connected to iPaaS.com, do not reach Clockify. Companies can go in either direction. The client's address is not mapped TO iPaaS.com by default; to keep it on the company, create a Customer Company custom field and map the client's Address to it. If your workflow needs other Clockify data, submit a feature request through your iPaaS.com partner channel.

There is no separate initial load. Existing Clockify clients and members arrive with the first client/poll and member/poll runs, and existing time goes back as far as Timesheet Poll Days (1 to 366 days) on the first timesheet/poll run. iPaaS.com companies that existed before the Customer Company FROM iPaaS.com triggers were turned on go to Clockify only when they are next saved, or when sent with Manual Sync, one company at a time.

What this means for you: Set Timesheet Poll Days to the period of past time you want before the first timesheet poll runs. To send many existing iPaaS.com companies at once, use bulk sync using Postman.

Polls run when a scheduled event in iPaaS.com starts them; the integration does not start them by itself. The Clockify lists the integration reads (clients, workspace members, and each member's time entries) have no "changed since" filter (Clockify API documentation, read 2026-11-06), so each client/poll and member/poll run sends every client or member again, and each timesheet/poll run reads the time entries that started within Timesheet Poll Days. An edit to a time entry that started before that window arrives only by its webhook trigger or by Manual Sync of its timesheet. Time entries always travel with their timesheet: they are not polled, triggered or sent by Manual Sync on their own. Email and name changes to members have no webhook trigger and arrive with the next member/poll run.

What this means for you: Create a scheduled poll event for each poll you use. Run client/poll and member/poll at a modest interval, such as once a day, because each run updates every client or member in iPaaS.com and other systems that take companies or employees are told about each one. Use the webhook triggers for changes during the day where your Clockify plan allows them. Run member/poll before the first timesheet/poll, so each employee exists before their time arrives.

A client deleted in Clockify, a time entry deleted in Clockify, and a member removed from the workspace stay in iPaaS.com as they were last sent: Clockify keeps no record of them to send. The integration also never deletes a Clockify client; a delete from iPaaS.com is refused with CLKF-BIZL-1005.

What this means for you: Archive clients and deactivate members in Clockify instead of deleting or removing them. An archived client reaches iPaaS.com with the custom field Clockify Archived set to Yes, and a deactivated member with Clockify Status INACTIVE. Correct deleted time in the system that receives timesheets from iPaaS.com, or use Approved weeks mode, which sends approved time only.

A client that is already archived, and a member who was invited or declined the invitation, are not added to iPaaS.com while they have never been sent. Once a record is linked, its later changes arrive, including archiving and status changes. A deactivated member is still added, with Clockify Status INACTIVE, because their recorded time needs the employee.

What this means for you: An invited member appears in iPaaS.com after they join the workspace and their next transfer runs (a trigger or member/poll). A skipped record logs no error, and its transfer shows only that nothing was sent.

A Clockify client that is not linked yet is matched to the iPaaS.com company with the same name (for example one that came from your CRM), and updates it instead of adding another. A matching company already linked to another Clockify client stops the transfer with CLKF-BIZL-1008. At the time this documentation was written, an iPaaS.com company that has a Department is not found by this match, and another company with the same name is created. iPaaS.com allows two companies with the same name only when their departments differ, so same-named companies are always affected.

What this means for you: Before turning on Customer Company TO iPaaS.com, check that each client's name matches one iPaaS.com company without a department. If your companies use Department, leave those clients out with the collection's filter (for example by returning false for their names) and keep those companies up to date another way. Removing a duplicate company does not help, because the client adds a new one on its next transfer. If your workflow needs matching on more than the name, submit a feature request through your iPaaS.com partner channel.

Each time a client reaches iPaaS.com (its webhook trigger or a client/poll run), the company takes the client's name, and its email and note when Clockify has them. In the other direction, a field edited in Clockify since the integration last wrote the client is not overwritten: the update FROM iPaaS.com stops with CLKF-BIZL-1003 until that edit has reached iPaaS.com. After the integration writes a client, the client's note in Clockify ends with a sync line such as [iPaaS.com sync … 12345], which is how it recognizes edits made in Clockify and its own earlier clients.

What this means for you: Decide which system owns each company field before turning on both directions. A company edited in iPaaS.com or by a CRM is set back at the next client transfer unless it was sent to Clockify first, so keep the customer/company/updated trigger on, or make the change in Clockify. Leave the sync line in the client's note: deleting it lets the next update from iPaaS.com overwrite the client. The sync line never appears in the company's description in iPaaS.com.

The Customer Company FROM iPaaS.com template sends the company's name, email and description (as the client's note). The client's address, archived flag and currency are written only if you add those mappings. A currency other than the workspace's own needs that currency in the workspace, which Clockify offers on its Pro plan and higher (Clockify pricing, read 2026-11-04). The client's cc email addresses and Clockify custom fields are not written.

What this means for you: Add the Address, Archived or CurrencyId mapping if you need them. Choose a Collision Handling Method on the collection before sending companies, so a company whose name matches an existing client is handled the way you intend; the template does not set one. If your workflow needs the client's cc emails or Clockify custom fields written, submit a feature request through your iPaaS.com partner channel.

A member matched by email to an existing iPaaS.com employee (for example one from your HR or payroll system) is linked to that employee instead of adding another, and does not overwrite the employee's first name, last name or picture: Clockify fills them only while they are empty. Clockify holds a member's name as one field; for a new employee, the last word becomes the last name and the rest the first name ("Mary Ann Smith" gives "Mary Ann" and "Smith"), and a one-word name has no last name. Two iPaaS.com employees cannot share an email, and an employee already linked to another member stops the transfer with CLKF-BIZL-1006.

What this means for you: A member renamed in Clockify keeps the employee's existing name in iPaaS.com. Change the name in iPaaS.com, or in the HR system that owns it.

iPaaS.com replaces the whole record on each update TO iPaaS.com. The default TO iPaaS.com collections therefore map every standard field: fields Clockify does not hold carry forward iPaaS.com's current value with the DestinationValue function. For Customer Company these are Department, PhoneNumber, FaxNumber, Url, AccountNumber, TaxIdNumber and ParentCompanyId, and the blank-value fallbacks of EmailAddress and Description. A mapping removed from a TO iPaaS.com collection blanks that field in iPaaS.com at the next update. Updates FROM iPaaS.com to Clockify read the client first, so client fields the collection does not map keep their Clockify value.

What this means for you: Keep these mappings in place. To preserve a field you add later, map it with a Dynamic Formula that returns its current value, for example DestinationValue.PhoneNumber mapped to PhoneNumber. Don't remove a required mapping: a company's Name, an employee's email and names, or a timesheet's employee.

Each subscription sends either every time entry (Time entries mode) or every approved week (Approved weeks mode). Changing the mode on a subscription that already sent timesheets sends the same hours again in the new form, and the earlier timesheets stay. A trigger of the other mode can't be turned on (CLKF-BIZL-1007). At the time this documentation was written, a Timesheet Mode change takes up to about a minute to apply, and a timesheet sent in that minute is not transferred and logs no error.

What this means for you: Choose the mode before the first sync. To change it: turn off the old mode's timesheet triggers, change the mode, wait a minute, then turn on the new mode's triggers and resync anything sent during that minute. Running both modes for the same workspace in two subscriptions sends the same hours twice; filter one of them out in the receiving system's collection.

Timesheet approval is part of the Clockify Standard plan and higher (Clockify pricing, read 2026-11-04). At the time this documentation was written, on a plan without approval, the transfer fails with CLKF-AUTZ-1001, which asks for the API key of a workspace owner or admin; the cause is the plan, not the key. Clockify's API cannot list rejected approval requests (Clockify API documentation, read 2026-11-06), so a rejected week, or a week that was submitted but never approved, is not sent and logs no error. The timesheet poll reads approved weeks only, so a withdrawn approval reaches iPaaS.com only by the APPROVAL_REQUEST_STATUS_UPDATED webhook trigger, and the week's timesheet and entries then show WITHDRAWN_APPROVAL. A week holds many entries, so the timesheet's project, task and tag fields are empty in this mode; each Timesheet Entry carries its own.

What this means for you: Use Time entries mode on Free and Basic workspaces; changing the API key does not fix the error. In Approved weeks mode, keep the APPROVAL_REQUEST_STATUS_UPDATED trigger on. A withdrawal made while it was off is not sent later, so correct that week in the receiving system.

Clockify counts API requests per workspace: 30 requests per hour on the Free plan, 20 per second on the Basic, Standard and Pro plans, and 50 per second on Enterprise (Clockify API documentation, read 2026-11-06). Every API key used on the workspace shares that limit. In testing on a Free workspace, each request counted against the limit for one hour after it was made. When a transfer reaches the limit, the transfer stops with CLKF-EXTN-1002. The code and iPaaS.com's message that the transfer will be retried later appear in the transfer's activity log; no error is added to the Error Logs. While the limit lasts, iPaaS.com also holds this subscription's other transfers in the same direction. On the Free plan, a time-entry poll of a large workspace can use up the hour's requests; the poll keeps its place and continues at the next run, so bringing in past time can take several runs. A transfer that fails because Clockify does not answer at all is recorded in Dashboard / Integration Monitoring / Error Logs with CLKF-EXTN-1001.

What this means for you: On the Free plan a poll of a large workspace, or a burst of transfers, can take hours to finish, and other tools using the same workspace slow it further. A paid Clockify plan raises the limit from 30 requests an hour to 20 or more a second. iPaaS.com retries a transfer stopped by the limit, and the transfers it held in the same direction arrive late too. If the record hasn't arrived an hour or so after the limit frees up, resend it with Manual Sync.

Clockify allows 3 webhooks per workspace on the Free plan; 10 per Clockify user, up to 100 per workspace, on the Basic, Standard and Pro plans; and 100 per user, up to 300 per workspace, on Enterprise (Clockify API documentation, read 2026-11-06). Each webhook trigger you turn on in iPaaS.com creates one Clockify webhook, owned by the user whose API key the subscription uses. A trigger that would pass the limit is refused with CLKF-EXTN-1009.

What this means for you: On the Free plan, turn on at most three triggers and use the scheduled polls for the rest. On paid plans, use the API key of a user with no other webhooks, so the subscription has all ten.

Turning a trigger off removes its Clockify webhook. At the time this documentation was written, a webhook was occasionally left in Clockify after its trigger was turned off. A subscription deleted with its triggers still on leaves its webhooks in Clockify, where they keep using the plan's webhook slots.

What this means for you: Turn triggers off one at a time, and before deleting the subscription. A workspace owner or admin sees the workspace's webhooks in Clockify under Preferences > Advanced > Manage webhooks (Clockify Help Center, read 2026-11-06). If deliveries continue after a trigger is turned off, contact iPaaS.com Support.

A subscription connects one Clockify workspace, named by its Workspace Id. Use the id from the address bar of the workspace's settings page in Clockify; the workspace id shown in the CAKE.com account console is a different id and is refused with CLKF-AUTH-1004. Changing the Workspace Id of a subscription that already ran is not supported: records linked in the old workspace aren't updated, the old workspace's webhooks stay, and, at the time this documentation was written, the timesheet poll keeps its saved place from the old workspace, so it can skip members in the new one.

What this means for you: To connect another workspace, create a new subscription. Turn off the old subscription's triggers before you retire it. If your workflow needs several workspaces in one subscription, submit a feature request through your iPaaS.com partner channel.

The default Employee TO iPaaS.com collection does not map member rates. They can be added to your own Employee custom fields from the member's HourlyRateAmount (billable rate) and CostRateAmount (cost rate), with their currencies. Billable rates need the Clockify Basic plan or higher, and cost rates the Pro plan or higher (Clockify pricing, read 2026-11-04); on other plans, validate what these fields hold in a staging environment before relying on them in production.

What this means for you: Map the rate fields only if your Clockify plan has them. Clockify holds rates in cents, so map them with the CentsToAmount function described in Clockify Mapping Functions (2500 becomes 25).

This document covers the seventeen known limitations of this integration. For detailed technical documentation on individual mapping collections, refer to the Clockify Mapping Collections articles.