Kantata OX's API provides access to the majority of Kantata OX's data model. The API authenticates requests using OAuth2 tokens and exists primarily to allow scripts and 3rd-party applications to access and manage Kantata OX data on behalf of Kantata OX users.
Kantata OX API Documentation (1.0.0)
Requests must be sent via HTTPS and can be in either JSON or Rails structured x-www-form-urlencoded format. Responses will always be returned in JSON format. Dates and times are returned as ISO 8601 formatted strings. All requests to the API must have URLs relative to the base API URL:
https://api.mavenlink.com/api/v1/
All requests to the Kantata OX API must be authenticated with an OAuth bearer token. See the application workflow for details on how to register an application with Kantata OX and obtain OAuth bearer tokens.
To authenticate using the Authorization header, set the header's value to Bearer <token>. So, if your token was abc123, your HTTP request would include the header Authorization: Bearer abc123.
For example, authenticating a request using curl would mean running a command similar to this one:
curl -H "Authorization: Bearer abc123" "https://api.mavenlink.com/api/v1/workspaces.json"
All requests to the Kantata OX API require an Authorization header. For brevity, future API request examples in this documentation will not include the example Authorization header parameter.
OAuth 2.0 provides an evolving, standardized inter-application authentication workflow for the Web. To build an application that interacts with Kantata OX on behalf of your users, you will need to register your application, and then obtain an OAuth token for each of your users.
Register and manage OAuth2 applications that can connect to Kantata OX at the application management page as a Kantata OX account administrator. You'll need a paid Kantata OX account in order to register applications with us. Applications have a name and a callback URL for OAuth2.
If you only want to use the Kantata OX API for yourself, or as a backend connector, you must still register an Application, but then you can get an OAuth token for yourself on the Application's page. If you want your application to be able to use the Kantata OX API on behalf of other users, read the next section.
Every request to the Kantata OX API must be accompanied by a valid OAuth token, indicating that your application has been authorized by the Kantata OX user in question. When you register an application with us, we'll provide you with a secret key. That key is unique to your application, and shouldn't be shared with anyone else. Treat it like a password. You'll need it to request user tokens.
To authorize your application for Kantata OX API access and obtain a user token, follow the below steps for each Kantata OX user:
Note: If you are using an OAuth2 library, many of these steps will be handled for you.
Request a short-term code, granted when the Kantata OX user agrees to allow your application access.
Send your user to
/oauth/authorizewith the REQUIRED parametersclient_id,response_type, andredirect_uri.client_idis the ID assigned to your application by Kantata OXresponse_typemust be set to "code"redirect_urimust be set to a URL where your application can accept codes and then exchange them for access tokens. It should match theredirect_urispecified when you registered your application.
Here is an example URL that an application located at "myapp.com" might use. (Linebreaks are not included in the URL.)
https://app.mavenlink.com/oauth/authorize?response_type=code&client_id=abc123&redirect_uri=http%3A%2F%2Fmyapp.com%2Foauth%2Fcallback
The user will be asked by Kantata OX if they want to authorize your application to interact with Kantata OX on their behalf.
If something goes wrong (like the user refused to authorize your application), Kantata OX will redirect to the
redirect_uriwith query parameters providing information about the error. For example, if authorization is denied, the user will be redirected to:$REDIRECT_URI?error=access_denied&error_description=The+resource+owner+or+authorization+server+denied+the+request.
If the user allows your application, then Kantata OX will redirect to the
redirect_uriwith query parameters providing your application with a time-limited code that your application can exchange for an access token within the next 5 minutes. Here is an example redirection with granted access:$REDIRECT_URI?code=abc123
Your application exchanges the code for an access token
Now that your application has a code, it should make a POST request directly to Kantata OX at
https://app.mavenlink.com/oauth/tokento exchange the code for an access token that will allow continued interaction with the Kantata OX API. The request must include theclient_id,client_secret,grant_type,code, andredirect_uriparameters.client_idis the ID assigned to your application by Kantata OXclient_secretis the secret token assigned to your application by Kantata OXgrant_typemust be set to "authorization_code" in order to exchange a code for an access tokencodeis the value that was returned in thecodequery parameter when Kantata OX redirected back to yourredirect_uriredirect_uriis the exact same value that you used in the original request to /oauth/authorize
If the request is invalid for some reason, an error response like the one described above will be returned. However, the parameters will be returned in the response body, encoded as JSON, instead of in the URL encoded as query parameters.
If the request is valid, Kantata OX will provide a response body, encoded in JSON, containing
access_tokenandtoken_type.access_tokenis the token that your application will use to authenticate requests to the Kantata OX API as this usertoken_typewill be "bearer"
Your application uses the access token to make authenticated requests to the Kantata OX API
At this point, your application can use the access token to authenticate requests made to the Kantata OX API as described above in the Authentication section.
Security Scheme Type: OAuth2
Flow type: authorizationCode
Authorization URL: https://app.mavenlink.com/oauth/authorize
Token URL: https://app.mavenlink.com/oauth/token
Kantata OX OAuth access tokens do not expire and must be treated with the same security that you would treat client credentials such as passwords. All requests must be made over SSL and all user security credentials must be stored using industry best practices. If a user revokes your application's access, usage of the token will result in an error.
Kantata OX API responses come back as JSON. All GET responses will be of a format similar to the following:
{ "count": 2, "results": [{ key: "workspaces", id: "10" }, { key: "workspaces", id: "11" }], "workspaces": { "10": { id: "10", title: "some project", participant_ids: ["2", "6"], primary_counterpart_id: "6" }, "11": { id: "11", title: "another project", participant_ids: ["2", "8"], primary_counterpart_id: "8" } }, "users": { "2": { id: "2", full_name: "bob" }, "6": { id: "6", full_name: "chaz" }, "8": { id: "8", full_name: "jane" } } }
As you can see, Kantata OX API responses can return multiple data types simultaneously, transferring objects and their associations in a single response. In this example, the developer has likely requested the /workspaces.json endpoint, asking for inclusion of those workspaces' participants and primary counterparts. These associations have come back in the top-level object called users. The developer should always use the returned results array to retrieve the canonical results from an API request. This is because some objects may have associations of the same type and can thus be mixed together with their associations in the JSON. For example, stories (tasks) have sub_stories which are the same type of object, so looking directly at the returned stories key when stories have been requested to include their sub_stories will be confusing and will include both. Instead, iterate the results key to determine exactly which top-level objects matched your query and in what order.
The follow sections explain how to customize further the Kantata OX API responses to your needs.
Large lists of items may be returned in pages. The JSON response will contain a key named count with a value of the number of objects returned by the entire query. If that number is greater than the number of objects returned by the request, additional objects may be requested by setting the parameter page, the parameter per_page, or both.
If you would like to start at a specific offset you may alternatively use limit and offset parameters. If both limit and offset are passed then page and per_page are ignored, otherwise behavior falls back to page and per_page.
page- type: Integer
- default: 1
per_page- type: Integer
- default: 20
- maximum: 200
usage- workspaces.json?page=2&per_page=15
-or-
limit- type: Integer
- minimum: 1
offset- type: Integer
- minimum: 0
usage- workspaces.json?limit=15&offset=10
While each API endpoint returns a paginated listing of the data available, it is sometimes more useful to request only one (or only a few) items. The Kantata OX API provides two ways to do this. The first, via the only parameter, allows you to request one or more resources directly by ID. To request the data for a single Workspace with an ID of 5, make an API request to the URL GET /api/v1/workspaces.json?only=5. Multiple IDs can be supplied in a comma separated list, like GET /api/v1/workspaces.json?only=5,6,7. The returned JSON will contain only the objects with those IDs.
only- type: Comma separated Integers
- default: not applicable
usage- workspaces.json?only=5,6
Additionally, we support traditional RESTful routes, such as GET /api/v1/workspaces/5.json. These routes also support our standard filters and includes, both detailed below. Unlike only requests to our "index" routes, these "show" routes will generate a 404 response if the requested resource cannot be found. Sometimes this is due to default filters being applied, so be sure to check the filter defaults applied in the specific documentation for the requested resource. More on filters below.
Many API endpoints also provide an optional set of filters that can be applied to the data that will be returned. Each filter, and the logic behind it, is documented on the individual endpoint pages, but the general form is a URL query parameter or request parameter like filter1=arg1&filter2=arg2, where filter1 and filter2 are the names of two different filters, and arg1 and arg2 are the arguments to each filter, respectively. Additionally, some filters have default values, which indicates that they are automatically applied to your request with their default value. Default values are applied both on "index" (GET /workspaces.json) requests and "show" (GET /workspaces/1.json) requests.
Some objects returned by the API may have associations that are not included in the JSON response by default. Those associated objects can be requested by adding an include parameter to the request. For example, to request both a list of posts, and the users that created those posts, you could request /posts.json?include=user. The response will consist of a JSON object with an array of result mappings under the "results" key, a "posts" key with a hash of post objects, keyed by id, and a "users" key with a hash of user objects, again keyed by id. To find the user that created a particular post, just use the post object's "user_id" key to find the user object keyed with the same id.
Multiple associations may be fetched simultaneously by adding comma-separated values to the include parameter. For example, to fetch the user and replies associated with post 6, you might request /posts.json?only=6&include=user,attachments, which would supply both the users and the attachments that belong to the posts returned in the response.
Example
curl -H "Authorization: Bearer abc123" "https://api.mavenlink.com/api/v1/posts.json?include=user,attachments"
{ "count": 1,
"results": [ { "key": "posts", "id": "16270634" } ],
"posts": { "16270634": { "id": "16270634", "message": "Hello World", "has_attachments": true, "user_id": "2", "workspace_id": "2249167", "attachment_ids": ["6700107"] } },
"users": { "2": { "id": "2", "full_name": "John Doe", "email_address": "johnny_doe@example.com" } },
"attachments": { "6700107": { "id": "6700107", "created_at": "2013-04-15T16:48:48-07:00", "filename": "turtle.jpg", "filesize": 16225 } } }
Some objects returned by the API may have fields that are not included in the JSON response by default. Those optional fields can be requested by adding an optional_fields parameter to the request. For example, to request a list of stories and include the optional field can_edit, you could request /stories.json?optional_fields=can_edit. Each story in the response will include the requested optional field in their JSON.
Multiple optional fields may be requested simultaneously by adding comma-separated values to the optional_fields parameter. For example, to fetch stories and include both can_edit and can_post fields in the response, you can request /stories.json?optional_fields=can_edit,can_post.
Example
curl -H "Authorization: Bearer abc123" "https://api.mavenlink.com/api/v1/stories.json?optional_fields=can_edit,can_post"
{ "count": 1, "results": [ { "key": "stories", "id": "1941361" } ], "stories": { "1937928": { "title": "Example Story", "description": "example description", ... "subtree_depth": 0, "ancestry_depth": 0, "can_edit": true, "can_post": true, "time_trackable": true, "time_estimate_in_minutes": null, ... "parent_id": null, "root_id": null, "id": "1937928" } }, "meta": { "count": 1, "page_count": 1, "page_number": 1, "page_size": 20 } }
Each endpoint in the Kantata OX API allows ordering by various fields. If we're missing a sort field that you need, please ask! See the specific endpoint documentation for endpoint-specific details.
When ordering, supply order with the name of a valid sort field for the endpoint and a direction. For example, order=created_at:desc.
Some API endpoints support text search, however only some filters can be combined with search, and results will be returned ordered by relevancy to the search query. Search does not apply to only requests. If search is unavailable the response will contain a system error describing the problem.
To make a search request, simply add a search parameter to the request. For example, to search for stories with "estimates" in the title, assignee names, or other fields, request /stories.json?search=estimates
If there is an error while processing your request, the response will include an HTTP status code indicating the error. Errors are currently returned as a top-level errors key with an array of error objects. For example, on OAuth failure you will receive a HTTP 401 with the following JSON body:
{ errors: [ { type: "oauth" message: "Invalid OAuth 2 Request" } ] }
System errors will look like:
{ errors: [ { type: "system" message: "Your account has been canceled" } ] }
And model validation errors look like:
{ errors: [ { type: "validation", message: "Please give your project a title", field: "title" }, { type: "validation", message: "Please select a role for this project", field: "creator_role" } ] }
When too many requests are made in a short amount of time, the API may reply with the HTTP code 429 Too Many Requests. In that case, simply retry your request after a small delay.
There are general rate limits applied to all requests. The following endpoints also have their own rate limits:
- Create a workspace -
POST /api/v1/workspaces - Get workspaces -
GET /api/v1/workspaces - Create a workspace invitation -
POST /api/v1/workspaces/{id}/invite - Create an account invitation (i.e. Create a new user) -
POST /api/v1/account_invitations - Resend an account invitation -
PUT /api/v1/account_invitations/{id}/resend - Create custom field value -
POST /api/v1/custom_field_values - Get custom field values -
GET /api/v1/custom_field_values - Create a project snapshot -
POST /api/v1/project_snapshots
Please see the Knowledge Base for the exact rate limits.
Please note that we reserve the right to change the limits at any time. In addition, if we determine that someone is using the API improperly, we may adjust the limits further.
All API requests will timeout after 3 minutes. Timeouts typically occur when there is a lot of data to return. You can use the following strategies to avoid your requests timing out:
- Break up your request into smaller requests
- Apply a date filter to your request
- If you are polling multiple endpoints in order to export data or sync Kantata data to a third-party system, use the Subscribed Events API instead. You can get recently updated objects in one request.
Download OpenAPI description
Overview
Languages
Servers
https://api.mavenlink.com/api/v1
A change is called a Subscribed Event, and the type of change is called a Subscribed Event Type.
Note: Only Account Administrators can access Subscribed Events.
Operations
Up to 9 days of trackable changes ("events") for an account can be accessed via the Subscribed Events API. For a list of all the event types tracked by Subscribed Events, please see the Knowledge Base. Note that only Account Administrators can access Subscribed Events.
Some actions performed in Kantata OX can generate multiple events. For instance, approving an Expense Report will generate expense_report:updated and expense:updated events. Note that events for the same action are not guaranteed to appear in the exact order the changes were completed.
Also note that although we try to create events within a few minutes of an action being performed, events may take some time to appear.
Additionally, events may sometimes be duplicated. Your application should handle duplicate events appropriately.
Operations
The Organizations feature in Kantata OX is composed of two independent trees: Department and Geography. Each has its own hierarchy structure. Users and Workspaces are associated to exact positions in these two trees via Organization Memberships. The corresponding API fields are geography_id and department_id.
A user's position in these two trees determines what objects they can see in Kantata OX—they can see objects associated with every department and geography going up the hierarchy from their selected department and geography.
Operations
Skills are used in Kantata OX to describe capabilities of users for the purposes of resource planning. They can be associated with a user through a Skill Membership. A user can be associated with up to 200 skills. This model includes categories such as 'Skill', 'Language', 'Certification' and 'Other'.
Operations
A User Group Membership represents the connection of a user to a Workspace Group. You must be an Account Administrator to use these endpoints.
Operations
This object allows you to view the names, ISO codes, and symbols of currencies supported by Kantata OX.
Operations
If Custom Fields represent the fields themselves, Custom Field Values represent the values in/of those fields. The Custom Field Values object allows you to view, create, update, and delete these values.
Operations
The Custom Fields object allows you to view, create, update, and delete extra fields for additional Estimate, Project, Group, Resource, Task, and User information. If Custom Fields represent the fields themselves, Custom Field Values represent the values in/of those fields.
Operations
This object allows you to export specific data sets from Kantata OX. You can view the full schema of available data sets using this endpoint.
To use this endpoint, you need to be an account administrator.
Operations
Request
Returns a list of the available data sets to export—as well as the respective available columns within each data set, which could include custom fields. The response will include unique key values for each individual data set and for each column. You will need to properly pass these keys in when you generate your data export.
- https://api.mavenlink.com/api/v1/exports/available_datasets
- Payload
- curl
- Ruby
- JavaScript
- Python
- C#
- Go
No request payloadResponse
application/json
{ "datasets": { "property1": { "key": "string", "display_name": "string", "columns": [ { "key": "string", "display_name": "string", "description": "string", "type": "string" } ] }, "property2": { "key": "string", "display_name": "string", "columns": [ { "key": "string", "display_name": "string", "description": "string", "type": "string" } ] } } }
This object allows you to export specific data sets from Kantata OX. You can create or cancel exports. You can also view the full schema of available data sets, view details for all exports, and download exports.
To use these endpoints, you need to be an account administrator.
Operations
An Attachment is a file asset that is attached to another Kantata OX object. Depending on the type of object, the file is used or displayed in different ways. The objects that Attachments can be attached to are: Post and Expense.
To create an Expense or Post with an Attachment, use the resulting attachment_id from the Attachment creation request in the parameters of the Expense or Post creation request.
Operations
External References allows users see which objects (one of Assignment, BillingMilestone, CustomField, CustomFieldChoice, CustomFieldSet, CustomFieldValue, Estimate, EstimateScenario, EstimateScenarioResource, Expense, ExpenseBudget, Invoice, Participation, Post, RateCard, Role, Skill, StatusReport, Story, StoryAllocationDay, Submission, SurveyAnswer, SurveyQuestion, SurveyResponse, SurveyTemplate, TimeEntry, TimeOffEntry, User, Vendor, Workspace, WorkspaceAllocation, WorkspaceGroup, or WorkspaceResource are synced with third party systems. This allows you to view the sync status of items in addition to the integration specifics for a synced object.
Objects that are synced with a third party system have external integration attributes that include the corresponding ID of the third-party object with which it is synced, a link that allows you to view the object in the third party system, the status of the external object in the external system, the status of the sync, and a link to exceptions.
Operations
Billing milestones allow you to set up billable items in a project that are separate from the Task Tracker work and have invoicing rules. A set of billing milestones in a project is known as the Billing Schedule.
Operations
This object allows you to view or edit foreign currency exchange rates, depending on your Foreign Exchange Access Group Set permissions. If you are not a member of an Access Group with Foreign Exchange (FX) permissions, an account administrator will need to add you to one. If you are an account admin that needs FX permissions, you can add yourself to an Access Group with the FX permissions you require.
Operations
Insights Access Groups allow you to manage classic Insights access for users. An Insights Access Group Membership represents the connection of a user to an Insights Access Group.
Note: To manage access to dynamic Insights, use Access Group Memberships instead.
Operations
Built with an easy-to-use, modern, and intuitive dashboard editor, Insights dynamic dashboards are based on the same powerful data engine as classic dashboards and help you make data-driven decisions for projects, staffing, and more. Use this API to get information about dynamic dashboards on your account.
Operations
This object allows you to manage scheduled exports of classic Insights reports from Kantata OX. An export of a classic Insights report that is scheduled to recur is called a scheduled job. You can create, update, and delete scheduled jobs. You can also view details of all the exports for a scheduled job, view the details of each export individually, and download the most recently exported report.
To use these endpoints, you need to be an account administrator.
Operations
Users can create Invoices in a Kantata OX project. An Invoice must have at least one line item (a time entry, expense, fixed fee item, or additional item). By default, the recipient of an invoice is the primary client in the project. Manual formatting options are available to define the format and information that should be displayed on an invoice.
Invoices can only be created and viewed by participants with financial permission in a project.
Operations
Workspace Invoice Preferences specify the default values that are applied to new invoices created for the specified project. It is only used for projects that have financials enabled.
These preferences can only be created and updated by users who can manage invoice preferences on the project. This can be found by querying can_manage_invoice_preferences on Workspace.
Operations
An Attachment is a file asset that is attached to another Kantata OX object. Depending on the type of object, the file is used or displayed in different ways. The objects that Attachments can be attached to are: Post and Expense.
To create an Expense or Post with an Attachment, use the resulting attachment_id from the Attachment creation request in the parameters of the Expense or Post creation request.
Operations
Project snapshots capture the state of a project at a specific point in time. Snapshots are useful for gaining a historical perspective on a project, and for comparing the current state of a project to a previous state.
Project financials, tasks, and resources are all captured in a snapshot, as well as project and task custom field values.
To use these endpoints, you must have the Edit Financials permission or higher in a project.
Operations
Project Templates are sets of tasks and attributes that can be applied to new or existing projects. A single template can be used on any number of projects. A project template's tasks are all stored in an attribute located on the project template object called raw_json. It is a JSON hash of all the stories that has been turned into a string and is stored on the object.
Operations
A participation represents the relationship between a participant and a project, including a participant's permission level, whether they're a provider or client, and many other properties. See the 200 status code response sample for an example of participation properties you can access.
Operations
The Project Accounting Records object allows you to view, create, and delete financial records related to revenue recognition, forecasting, and earned value.
Operations
Workspace Invoice Preferences specify the default values that are applied to new invoices created for the specified project. It is only used for projects that have financials enabled.
These preferences can only be created and updated by users who can manage invoice preferences on the project. This can be found by querying can_manage_invoice_preferences on Workspace.
Operations
A workspace resource is the object that is tied to assignments and allocations within a Workspace.
Workspace Resources can be:
- Named Resources: Resources with a user_id.
- Unnamed Resources: Resources with no user_id.
With workspace resources it is possible for a user to have many resources with different roles within a single workspace. Workspace resources can be assigned to tasks via Assignments.
e.g. In an example workspace, 'the Accounting Project', we could have 3 workspace resources:
- Alice as an Engineer in the Accounting Project
- Alice as an Designer in the Accounting Project
- Bob as a Designer in the Accounting Project
With workspace resources, Alice could be assigned to one task as an Engineer and use the Engineer rate for that task, and another task be assigned as a Designer and thus the designer rate would be used there.
When a named workspace resource is created, if role_id is not specified, it will default to the user's primary role within the project (see primary role definition below). When the workspace resource is created, label with be generated based on the user's primary role.
Operations
Rate Card Roles belong to a Rate Card Version and represent the bill rate, in cents per hour, for a specific Role. For example, the rate for the role of Developer may be 2000 cents per hour. It is not necessary, however, to create a Rate Card Role for every role on your account if the rate is the same as the default rate on the Rate Card Version. When an explicit Rate Card Role does not exist for a role on the account, the default rate on the Rate Card Version is used to calculate the total bill rate.
Rate Card Roles can only be accessed, edited, or deleted by an Administrator on the account.
Operations
In the Rate Card system, Rate Card Set Versions represent snapshots of a Rate Card Set, that take effect on the set published date. A Rate Card Set Version owns a copy of each Rate Card Version of a Rate Card in the associated Rate Card Set.
Rate Card Roles can only be accessed, edited, or published by an Administrator on the account.
Since Rate Cards and Rate Card Versions are immutable after they are published and in use, generating a Rate Card Set Version is the correct process for making any changes. When a new Rate Card Set Version is created or cloned, all of the Rate Card Versions from the old Rate Card Set Version are copied to a new one.
Operations
A Rate Card Set represents a group of Rate Cards with multiple currencies that can be bundled together. A Rate Card Set belongs to an account and can have several Rate Card Set Versions, each representing the effective version for a specified date.
If the Rate Card feature is enabled, an account will always have an account default Rate Card Set. Rate Cards belonging to the account default Rate Card Set are applied to projects by default when a Rate Card is not explicitly set.
Additional custom Rate Card Sets can be created after the Rate Cards feature has been enabled on the account. This can be done by making a request to the activations endpoint.
Operations
Each Rate Card Table Row represents a role and its rates and currencies for a specific Rate Card Set Version.
Operations
Rate Card Versions represent a snapshot of a Rate Card at a specified point in time. They are used to set the default rate. Rate Card Versions belong to a Rate Card Set Version and own many Rate Card Roles.
Rate Card Versions cannot be explicitly created. This is done through the creation of Rate Cards or Rate Card Set Versions.
Operations
Rate Cards belong to a Rate Card Set and represent the currencies in that set. Rate Cards have many Rate Card Versions which represent the effective version of a Rate Card at a specified point of time. Rate Cards are accessible to users with Financial access (Project Lead or higher) on the account. However, they can only created, modified or deleted by Administrators on the account.
Operations
A Recommendation suggests a User for an Unnamed Resource (or some other un-staffed position). The system recommends Users based on how well they match the attributes of a target resource. Attributes include, but are not limited to:
- Role
- Skill(s)
- Single Choice Custom Field(s)
- Allocation(s).
Operations
Survey Answers (Legacy) appear on and can be responded to through surveys. Survey Answers (Legacy) are required to have a value for the answer (i.e. answers must have at least one choice selected or a non-null value). Additionally, only one value type can be specified for the answer (e.g. specifying a date value as well as choice values is invalid).
Note: This feature requires the Surveys (Legacy) account add-on. This feature is unrelated to Pulse surveys.
Operations
The Assignments object allows you to view and manage task assignments for named or unnamed resources.
Note: Because Daily Scheduled Hours are a part of Assignments, they can be affected when an assignment changes.
Operations
Daily Scheduled Hours (also called Story Allocation Days) is the allocation of time for a resource to spend on a specific task, on a specific day. Daily Scheduled Hours are part of Assignments, so if an Assignment is deleted, so are its Daily Scheduled Hours.
Operations
Story dependencies define relationships between tasks and the sequence in which they must be completed in order to close a project. A dependency is between two tasks (stories) in a project (workspace), with one being the predecessor (source) task, and the other the successor (target) task. Each relationship is characterized by the type of dependency and lag between tasks. There are four (4) types of dependencies:
- Finish to Start (FS)—The predecessor ends before the successor can begin.
- Start to Start (SS)—The predecessor begins before the successor can begin.
- Finish to Finish (FF)—The predecessor ends before the successor can end.
- Start to Finish (SF)—The predecessor begins before the successor can end. Lag is the number of days between the predecessor task ending and the successor task beginning. To learn more about dependencies, see our Gantt Chart Dependencies article.
Operations
Line Item Locks provide a way for you to lock time in the past so that previous time entries cannot be edited or updated and new time entries cannot be created before the selected lock date.
Line Items can be locked to any Saturday in the past on a per-account basis.
Keep in mind that this feature does not lock the ability to invoice approved time entries, nor does it lock the submission or approval of expenses.
Also note: Line Item Locks cannot be modified or deleted. If you would like to move the lock date forward, simply create a new lock at a later date, and your account will be locked at the new date. Once your account has been locked, the lock cannot be moved earlier, or removed.
Operations
Timesheet Submissions hold a set of time entries for a specified week, and can be approved, rejected, or canceled.
You can enable timesheet submissions and approval in your project settings. Once enabled, time entries must be approved through a Timesheet Submission before it is invoiceable.
Note: Each Timesheet Submission can only be associated with a single project. So when a timesheet is submitted through the UI with time entries for multiple projects, a separate Timesheet Submission object is created for each project in the backend.
This section contains endpoints to approve, reject, or cancel a single timesheet submission. To approve, reject, or cancel multiple timesheet submissions at once, see Timesheet Approvals, Timesheet Cancellations, and Timesheet Rejections.
Operations