# Working hours

This page explains how per-account working hours affect your API requests, what the off-hours policies do, and how to handle a workflow that is parked until the window reopens.

## What working hours are

Each connected LinkedIn account can carry a **weekly activity window** – the hours during which Linked API is allowed to act on it. A LinkedIn account that is active around the clock looks like a user who never sleeps, which is one of the strongest automation signals there is. Giving an account a human-shaped schedule removes that signal without costing you any throughput inside the window.

Working hours are configured per account in [our platform](https://app.linkedapi.io/), next to the account limits. There is no API for changing them – they are an account-owner decision, not a per-request one.

![](/images/docs/working-hours-settings.webp)

The window is stored with an explicit timezone, so it follows the account's local wall clock across daylight-saving changes rather than drifting by an hour twice a year.

| Setting | Meaning |
| --- | --- |
| Days | Which weekdays the account is active on. |
| Time range | Start and end of the daily window, in the account's timezone. |
| Timezone | The zone the window is expressed in. Defaults to the timezone of the device you configure it from. |
| Outside working hours | What happens to requests that arrive outside the window – see below. |

An account with **no** window configured is never gated. If you have never touched this setting, nothing about your integration changes.

## Off-hours policies

The policy decides what happens to a request that arrives outside the window. It is the **Outside working hours** selector in the screenshot above.

### Queue until the window opens

The workflow is accepted and parked. It starts automatically when the window reopens – you do not need to resubmit it. This is the default for newly connected accounts.

### Reject with an error

The request fails immediately with the `outsideWorkingHours` error and nothing is queued.

```json
{
  "success": false,
  "error": {
    "type": "outsideWorkingHours",
    "message": "This LinkedIn account is outside its configured working hours."
  }
}
```

### Run anyway

Your API requests run at any time – the window is not enforced for them.

Note that this applies to **your** requests only. Work Linked API schedules for itself – inbox and network synchronisation – stays inside the window under every policy, and the cloud browser behind the account is released outside the window under every policy too. That is where the account-safety and infrastructure benefits of the schedule come from.

## Telling a parked workflow from a queued one

Every response describing a workflow that has not started yet carries a `pendingReason`. It appears both in the response to `POST /workflows` and in the [workflow result](/docs/executing-workflows) response.

```json
{
  "success": true,
  "result": {
    "workflowId": "wf-64835e7c-a0gc-40ae-8338-108f02sSe643",
    "workflowStatus": "pending",
    "pendingReason": "outsideWorkingHours",
    "message": "This workflow is scheduled and will start when the account working hours open at Mon, Aug 10, 09:00 (Europe/Berlin)."
  }
}
```

| Value | Meaning |
| --- | --- |
| `queued` | Waiting its turn behind other work on the same account. Minutes, typically. |
| `outsideWorkingHours` | Parked until the account working hours reopen. Can be the next working day. |
| `null` | The workflow is not pending. |

This distinction matters for polling. A `queued` workflow is worth polling every few seconds. An `outsideWorkingHours` one will not move until the window reopens, so polling it in a tight loop achieves nothing – back off until the time named in `message`, or surface that time to your user.

## When a parked workflow expires

A parked workflow does not wait forever. If it is still pending 7 days after it was first parked, and the window has opened at least once in that time without the workflow being started, it fails with a dedicated error:

```json
{
  "success": true,
  "result": {
    "workflowStatus": "failed",
    "failure": {
      "reason": "workingHoursWaitExpired",
      "message": "This workflow remained pending for 7 days after it was first parked by the account working hours, and was not started."
    }
  }
}
```

A workflow that expires this way never entered the `running` state, so it emits the `workflowCreated` and `workflowCompleted` [webhook events](/docs/webhooks) but no `workflowStarted`.

This is worth watching if you combine a narrow window with a high request volume: an account is only able to run one workflow at a time, so a window of a couple of hours per week puts a hard ceiling on how much work can drain through it.

## Seeing the current state

The account list in the platform shows each account's schedule underneath its connection status, and marks the ones that are outside their window right now – so you can tell at a glance why nothing is starting for an account.

![](/images/docs/working-hours-account-list.webp)

An account with no schedule line carries no window at all and is never gated.