Guidelines

When an organization requires approval for manual time, members submit manual time requests. Public API v2 lets you list those requests and approve or deny them through a single status endpoint. Creating, deleting, and batch approve/deny are not available through the API.

Collection is organization-scoped. Filter by status=submitted for the review queue. Use updated_at[start] for incremental sync.

curl "https://api.hubstaff.com/v2/organizations/<org_id>/manual_time_requests?status=submitted&page_limit=100" \
  -H "Authorization: Bearer <access_token>"

Single-record routes are shallow: GET /v2/manual_time_requests/<id>. Unknown or non-visible IDs return 404 / 12000.

Only submitted → denied is allowed. denial_reason is required.

curl -X PUT https://api.hubstaff.com/v2/manual_time_requests/<id>/status \
  -H "Authorization: Bearer <access_token>" \
  -H "Content-Type: application/json" \
  -d '{
    "status": "denied",
    "denial_reason": "Outside scheduled hours"
  }'

A plain approve creates activity for the full requested range (limits, collisions, budgets, shifts, timesheets, and so on still apply). When the approval is clean, one PUT is enough. When a warning needs an explicit decision, the API returns 422 with a stable error_code — retry the same status endpoint with the matching intent flag (see Handle approval conflicts).

curl -X PUT https://api.hubstaff.com/v2/manual_time_requests/<id>/status \
  -H "Authorization: Bearer <access_token>" \
  -H "Content-Type: application/json" \
  -d '{ "status": "approved" }'

Deny and approve are mutually exclusive paths: once a request leaves submitted, further status updates return 14451.

These are not follow-on steps after a successful approve — they are optional intent flags you send on the same status endpoint when a first attempt returns 422, or when you already know the policy to apply.

Member limits

Member-limit handling is opt-in. Pass one boolean intent; the server calculates excess time or limit increases.

# Discard excess time (keep member limits as-is)
curl -X PUT https://api.hubstaff.com/v2/manual_time_requests/<id>/status \
  -H "Authorization: Bearer <access_token>" \
  -H "Content-Type: application/json" \
  -d '{
    "status": "approved",
    "discard_exceeding_hours": true
  }'

# Raise limits and approve the full range (owner/manager)
curl -X PUT https://api.hubstaff.com/v2/manual_time_requests/<id>/status \
  -H "Authorization: Bearer <access_token>" \
  -H "Content-Type: application/json" \
  -d '{
    "status": "approved",
    "increase_limit": true
  }'

Collisions and project budget

These flags are independent of member limits.

accept_collisions

Confirms approval when the request overlaps existing time the approver is authorized to override. One flag covers ordinary tracked-time collisions and associated data within role permissions:

• Unprocessed paid time (team payments)
• Client invoices
• User (team) invoices
• Timesheets
• Integration-synced time (task or time export)

Approving with this flag may remove time from unprocessed payments and leave invoices or integrations out of sync. Only associations the actor's role may override are accepted — anything else fails the approval.

curl -X PUT https://api.hubstaff.com/v2/manual_time_requests/<id>/status \
  -H "Authorization: Bearer <access_token>" \
  -H "Content-Type: application/json" \
  -d '{
    "status": "approved",
    "accept_collisions": true
  }'

allow_above_project_budget

Allows approval when the created activity would exceed the project budget. This is project budget only — not member daily/weekly limits (use discard_exceeding_hours or increase_limit for those).

Always branch on error_code in the JSON body.

Full operation schemas live under the manual_time_requests reference tag. Machine-readable codes are listed in errors.