How the API works

What every endpoint has in common. Each endpoint's own parameters and answers are in the API reference.

Your key decides everything

• The key acts as you: what it writes shows you as the author, in LogQuill and in Jira.
• It reaches only the parts you ticked (its scopes), and never more than your role allows in LogQuill. Your role is checked on every call, so a change to it applies straight away.
• The site comes from the key: there's no site to name in the request.

People, days and durations

• People are named by their Jira account id (accountId), the same everywhere in Jira. Where a list takes accountId, me means you, the key's owner.
• Days are YYYY-MM-DD. A worklog's date is the day it counts for in its author's time zone, as on their timesheet. Moments (startedAt, createdAt, updatedAt) are ISO 8601 in UTC.
• Durations are in seconds: timeSpentSeconds: 5400 is 1h 30m.
• Issues are named by id: { "id": 10232 }. When you log or plan time you can name one by its key instead: { "key": "ABC-123" }.
• To show issues and projects by name, pass their ids to GET /v1/issues?ids=10232,10233 (key and summary) and GET /v1/projects?ids=10000 (key and name). Only those with time you may see; others come back under unknown.

Pages

Lists answer in pages:

{
  "results": [ ... ],
  "metadata": {
    "count": 100,
    "limit": 100,
    "next": "https://api.logquill.com/v1/worklogs?from=2026-10-01&to=2026-10-31&cursor=..."
  }
}

Fetch next as it is until it's null. A page holds 100 results unless you ask for up to 1000 with limit, and may hold fewer even when more follow: keep going while there's a next. Lists that cover a period take from and to (both included), a year at most. A cursor that isn't one a page gave answers 400 with data.reason invalidCursor: leave it out to start again.

To keep another system in step, ask only for what changed: GET /worklogs and GET /plans take updatedFrom, a moment in UTC.

Writing time

Logging, changing and deleting time through the API follows your site's rules, exactly as in LogQuill:

• required fields and work types, daily hours limits, and locked timesheets;
• only your own worklogs and plans can be changed or deleted;
• time is logged in Jira too, as you, and moves the issue's remaining estimate as in LogQuill.

One call logs one day (POST /worklogs). A plan is also one day: POST /plans with a startDate and an endDate makes one plan for each day.

Timesheets follow the same rules as in LogQuill: POST /timesheets/submit sends yours (or, as a team leader, a member's) to one of the teams in its submitTo; approve and reject are for those who review it, never its owner. The same emails go out as when it's done in LogQuill.

A timesheet covers a period (a week, or more, as your site sets it). You never need its first day: any day in it stands for the whole period, and the answer says which period it was (periodStart, periodEnd). A period that hasn't ended can't be submitted; the error then names the last one that has, in data.previousPeriod, which is usually the one you meant.

Every change is in LogQuill's audit log, as made by you "through the public API", with the start of the key.

Errors

Errors answer with a status and a body like this:

{
  "code": "FORBIDDEN",
  "status": 403,
  "message": "This key doesn't have the plans:read scope",
  "data": { "reason": "missingScope", "scope": "plans:read" }
}

data.reason on a 403:

• missingScope: the key wasn't given this part. Make a key with it.
• readOnly: the site's subscription is inactive, so keys can read but not write.
• noTimeTracking: your role doesn't track time, so you can't log or plan any.
• apiDisabled: an administrator turned the API off for the site.
• ownerInactive: your Atlassian account is deactivated.
• ownerNotInJira: Jira won't act for you, usually because you lost access to Jira or to the app.

Writes can also be refused by your site's rules, with a message saying which (a locked timesheet, a full day, a missing field).

Sending a create again

Creating a worklog or a plan is not repeat-safe: the same POST sent twice makes two, each its own Jira worklog. After an error answer (4xx, 503), nothing was made, so sending again is safe. If a create got no answer at all (a timeout, a dropped connection), list that day's worklogs or plans first, and send it again only if it isn't there. Changing and deleting are safe to repeat: a second delete answers 404. Submitting a timesheet twice is refused the second time, as it is already submitted.

Limits

Worklog and plan changes have their own limit because they go to Jira, whose allowance every LogQuill customer shares. Reading, and submitting or reviewing timesheets, costs Jira nothing.

Every answer says where you stand:

• X-RateLimit-Limit: the key's requests a minute;
• X-RateLimit-Remaining: how many are left this minute;
• X-RateLimit-Reset: seconds until the minute ends.

Past a limit, the answer is 429 with Retry-After: the seconds to wait. Jira itself may also ask LogQuill to slow down; that comes back as a 429 too, with Jira's own wait.

The API's description

The whole API is described in OpenAPI at /v1/openapi.json, for tools that generate clients or import requests (Postman, Insomnia, Bruno).