The API You Will Actually Use

An API exists in almost every product in this category. Whether it can support a production integration is a different question with specific answers.

What to check in the documentation

Coverage. Can it read and write time entries, approvals, people, projects and rules — or only read?

Bulk operations. Creating two thousand entries one call at a time is not a migration path.

Filtering by change, so a synchronisation can ask what changed since a timestamp rather than reading everything.

Pagination that is stable while data changes underneath.

Error detail. A rejection that says only "invalid" costs days.

Versioning policy, and how long old versions live.

The questions not in the documentation

Rate limits, and whether they are per account or per token. Migration and nightly synchronisation both hit them.

Whether writes are idempotent. A retried request that creates a second entry is the failure mode that produces duplicate pay.

Whether the API enforces the same rules as the interface. Products where the interface validates and the API does not will accept records that the interface would refuse, and the difference surfaces at period close.

Whether an API write triggers the same audit trail as a manual one. If not, your edit history has holes exactly where automation touched it.

Ask these in writing. They are answerable and vendors answer them carefully when written down.

Webhooks and polling

Webhooks are better when they work: immediate, no wasted calls.

They fail silently. A missed delivery is a gap nobody notices.

Require: retry with backoff, a delivery log you can query, and a way to replay.

Where none of that exists, poll. A scheduled reconciliation that reads changes since the last run is less elegant and much easier to verify.

Most reliable arrangement: webhooks for timeliness, a nightly reconciliation for correctness. The second catches what the first dropped.

Authentication

Service accounts, not a person's credentials. Integrations keyed to an employee break when that employee leaves, and it happens more than it should.

Scoped tokens, so a read-only integration cannot write.

Rotation without downtime, which means the product must accept two valid tokens during a changeover.

Testing before committing

Ask for sandbox access during evaluation, not after signing.

Write the riskiest call: bulk create, then read back and compare.

Deliberately send bad data and read the error.

Deliberately break the connection mid-operation and see what state you are left in.

Half an hour of this tells you more than the documentation, and a vendor who will not provide sandbox access during evaluation has answered a different question.

Half an hour in the sandbox

More informative than the documentation, and it requires sandbox access during evaluation.

Write the riskiest call: bulk create, then read back and compare.

Send deliberately bad data and read the error. "Invalid" costs days; a field-level message saves them.

Break the connection mid-operation and see what state you are left in.

Retry a write and check whether you now have two entries.

A vendor who will not provide sandbox access before signing has answered a different question.

Start from an actual hand-off

For an example grounded in project delivery, review this technical use case. Then prove authentication, identifiers, retries and corrected records with your own integration consumer.