Logging Work via the API

Due to our privacy-first approach, detailed in this article, you must use the Jira REST API to create work logs. When creating work logs, you can also include JetTime-specific metadata as part of the work log properties. For details on JetTime metadata, refer to JetTime Work Log Metadata article.

To create work logs, refer to the Jira API documentation for creating work logs via POST.

Example JSON Body

{
  "comment": {
    "content": [
      {
        "content": [
          {
            "text": "I did some work here.",
            "type": "text"
          }
        ],
        "type": "paragraph"
      }
    ],
    "type": "doc",
    "version": 1
  },
  "started": "2025-01-02T13:04:16.208+0000",
  "timeSpentSeconds": 3600,
  "properties": [
    {
      "key": "jettime",
      "value": {
        "schemaVersion": 2,
        "timeSpentSeconds": {
          "BILLABLE": 600
        },
        "fields": {
          "EXPENSE": 240.45,
          "INTERNAL": false,
          "WORK_TYPE": "Consulting"
        },
        "account": {
          "name": "Acme Corp",
          "key": "ACME"
        },
        "team": {
          "name": "Mobile Developers",
          "key": "MOBILE"
        },
        "functionRole": {
          "name": "QA",
          "key": "QA"
        },
        "timeZone": "Europe/Berlin"
      }
    }
  ]
}

Explanation of Key Fields

• timeSpentSeconds (top level). Regular Time, Jira's own time spent. For a Regular Time of zero, send 0 here and add "REGULAR": 0 to the property's timeSpentSeconds — a 0 without "REGULAR": 0 reads as Regular Time left empty (why).
• BILLABLE. This key under timeSpentSeconds represents a custom time category. Custom time category keys, such as BILLABLE, are defined in the JetTime app UI when you create the category, along with its other parameters (for example, display name and attributes). Send the category's seconds, or null when nothing was entered.
• fields. These keys represent custom work log fields configured in the JetTime app UI. Each key, such as EXPENSE, INTERNAL, or WORK_TYPE, is defined in the UI when the custom work log field is created, alongside its type (for example, numeric, text, boolean). A numeric field with nothing entered takes null:
  • EXPENSE. Tracks financial expenses in numeric values.
  • INTERNAL. A boolean field indicating whether the work is internal or external.
  • WORK_TYPE. A text field describing the type of work performed (for example, Consulting).
• account. Represents the client or project account, defined in JetTime's Accounts section, with attributes like name and key.
• team. The team the work was logged under, with the same name and key attributes.
• functionRole. The function role the work was done under, again as name and key. Together with the team, this is what lets a report split one person's hours across the roles they play.
• timeZone. The time zone the work was done in, as an IANA time zone name such as Europe/Berlin (details). JetTime shows the work log on that zone's day and clock; started stays the true moment with its offset. Leave it out and JetTime uses the author's Jira profile time zone.

Write the key of an account, team, or role that exists in the app — that is what JetTime matches on, and an unknown key leaves the entry with no account, team, or role attached. Set null, or leave the field out, when there is none. The name is stored alongside as a readable snapshot and is never read back, so it does not have to be kept in sync.

The work log author is the native Jira author, the account the work log is created as. To log work for someone else, see Managing Work Logs for Others via the API.

Using this example, you can seamlessly integrate JetTime's metadata into your Jira work logs while maintaining privacy and flexibility for your time tracking needs.