---
title: Freshness and available-through dates
category: freshness
summary: Understand the three clocks that decide how current "latest" is, read them from the API, and never mistake a not-yet-available day for a quiet one.
order: 19
updated: 2026-10-07
next: schedule-six-hour-and-daily-pulls
related: read-the-response-envelope, troubleshoot-empty-windows-and-missing-manifests
reference: /agent-guide.md, /pricing
---

"Latest" is not one thing. Three separate clocks decide how recent the content you can see is. If an agent mixes them up, it reports a gap that does not exist or hides a gap that does.

## When to use this

Use it before you promise recency ("as of this morning"), before you set a schedule, and whenever a recent window comes back empty.

## Smallest working call

Ask the account what it can see. This is free:

```bash
curl -sS https://api.synorb.com/account \
  -H "Authorization: Bearer $SYNORB_KEY"
```

```mcp
synorb-profile
{"verbosity": "standard"}
```

## What you get back

```json response
{
  "data": {
    "temporal": {
      "refresh_tier": "daily",
      "relative_anchor": "available_through",
      "available_through": "2026-10-06",
      "wall_clock_date": "2026-10-07",
      "lag_days": 1
    }
  }
}
```

### The three clocks

**1. Your plan's ceiling: `available_through`.** This is the newest date your plan can read.

| Plan | Delivery | Ceiling |
| --- | --- | --- |
| 72 Hour Agent Demo, Starter, Individual | Daily Batch (`refresh_tier: "daily"`) | The previous calendar day |
| Professional, Startup, Enterprise | Continuous Delivery (`refresh_tier: "continuous"`) | No plan-imposed daily ceiling |

On a Daily Batch plan the ceiling is a calendar date, so it advances once a day. On Continuous Delivery, how soon an item arrives depends on the source and the index. Do not promise a fixed publication-to-delivery time on any plan.

**2. The index.** The serving index has its own freshness.

On MCP, read the top-level `index_staleness_seconds` of a `synorb-manifests` response. It is the age of the newest published item that the index has seen. Synorb leaves it out when it cannot measure it. A missing value is not a zero.

**3. The source.** Each source channel crawls on its own cadence and publishes at its own rate. `synorb-details` shows `crawl_frequency` and `avg_items_30d` for each source channel.

The Stream shows `freshness_state`, `last_manifest_at` and `days_since_last_manifest`. A source channel that averages three items a month is quiet on most days. That is normal.

### How relative windows work

Synorb rounds `lookback_hours` up to whole publication days. `lookback_hours: 6` is not the last six hours, and `lookback_hours: 24` is one date: the latest available day.

`days` and `lookback_hours` anchor to **`available_through`**, not the wall clock. So `days: 1` means the latest available day. `relative_to: "wall_clock"` opts into the wall clock, and it remains limited by your plan.

"Last week" means a rolling seven available days that end at `available_through`. If the ceiling is 2026-10-06, that is 2026-09-30 through 2026-10-06. It is not the previous calendar week. Show your user the effective inclusive dates, which come from the `temporal` block of the response.

Explicit `published_date_from` and `published_date_to` are exact. If the end date is in the future, Synorb clamps it, and `date_window_adjustment` reports that.

### A procedure for "why is it empty?"

1. Read `available_through`. Is the window you asked for entirely beyond it? If yes, that is a ceiling, not a quiet source.
2. Read the Stream's `freshness_state` and `days_since_last_manifest`. Is the Stream itself stalled?
3. Read the `avg_items_30d` of the source channel. Is an empty day ordinary for it?
4. Count a wider window (`mode: "count"`). If the wider window has items and the narrow one does not, the source is quiet.
5. Only then conclude, and say what you checked.

## Failure modes

| Symptom | Cause | What to do |
| --- | --- | --- |
| "Today's" items are missing on a free plan | Daily Batch ceiling is yesterday | Say "latest available is October 6", and do not call it a gap. |
| An empty window on a busy Stream | The window sits past `available_through` | Widen it, or end it at the ceiling. |
| `index_staleness_seconds` is absent | It could not be measured | Do not treat it as zero. Rely on `temporal` and Stream freshness. |
| Different answers at different times of day | The ceiling and index advanced between calls | Pin explicit dates for anything you will compare. |
| A weekly "last week" report that looks wrong | You used the previous calendar week | Use the rolling seven available days. |
| Reading `temporal.lag` as index health | It is the ceiling's age, an older alias | Use `index_staleness_seconds` for the index. |

## Make it good for your user

State the freshness you have, once, in plain words: "Covering through October 6, the latest day your plan has. Professional and above have no daily ceiling." This is true and useful. It gives your user a real reason to upgrade only if recency matters to them. Never let your user assume "now" when you mean "as of the last available day".

## Next guide

[Schedule six-hour and daily pulls](/agent-resources/schedule-six-hour-and-daily-pulls): run a reliable recurring check from your own runtime.