Date ranges and time zones

A date range consists of from_date and to_date. If you want every company that visited your website in October, for example, you send from_date=2026-10-01&to_date=2026-10-31.

The range filters by the start of a visit, not by the individual page views within it.

From date to resultCopy Anchor Link

1. 1Send a dateYou send a date, a time, or a relative value such as -7 days.
2. 2Convert to UTCWebmetic turns it into a point in time in UTC.
3. 3Filter visitsWebmetic picks the sessions that started within the range.
4. 4Read the responseEvery time in the response is in UTC.

Parameters and defaultsCopy Anchor Link

All eight Visitor Intelligence endpoints take both parameters in the query: /company-sessions, /company, /company_nace, /session, /session_user_data, /intensive-visits, /returning-visits, and /new-visits. Enrichment, contacts, and webhooks have no date parameters.

• from_date: start of the range. If you leave it out, it's -30 days, which means 30 days before the time of the request.
• to_date: end of the range. If you leave it out, it's now, the time of the request.

Accepted formatsCopy Anchor Link

Both parameters accept the same formats:

Relative values know days, hours, minutes, and years, but not weeks or months. For a week or a month, give two dates instead. Always write now in lowercase, because the API doesn't understand NOW.

If the API can't read a value, it answers with status 400 and the code INVALID_DATE. For details, see Errors.

Start and endCopy Anchor Link

• Start: from_date belongs to the range, so a session that starts exactly at that time is included.
• End: to_date no longer belongs to it, because the range ends right before that time.
• Date without time: as to_date, the whole day counts, so to_date=2026-10-31 includes October 31.

A company appears when at least one of its sessions started within the range. A visit that began before from_date is left out, even if it runs into the range.

/session_user_data returns all page views of a session that started within the range.

Time zonesCopy Anchor Link

Webmetic works in UTC and also reads an ISO date or ISO time without a time zone as UTC. We recommend sending points in time as ISO values with Z, because then they're unambiguous.

curl "https://hub.webmetic.de/company?domain=your-website.com&from_date=2026-10-01T00:00:00Z&to_date=2026-11-01T00:00:00Z" \
  -H "Authorization: wmtc_YOUR_API_KEY"

You can also give an offset, for example +02:00. In a URL, though, + stands for a space, and the API then misreads the value without an error. So write %2B or let your HTTP client encode the parameter:

curl -G "https://hub.webmetic.de/session" \
  -H "Authorization: wmtc_YOUR_API_KEY" \
  --data-urlencode "domain=your-website.com" \
  --data-urlencode "from_date=2026-10-21T00:00:00+02:00" \
  --data-urlencode "to_date=2026-10-22T00:00:00+02:00"

Times in responsesCopy Anchor Link

• API responses: in responses to GET requests, timestamps are ISO 8601 in UTC, without Z and without an offset, for example 2026-08-22T08:20:26.384000. Read the values as UTC. JavaScript reads a timestamp without a suffix as local time. So append a Z before parsing if the value has no offset: new Date(value + "Z").
• Fractions of a second: Webmetic leaves them out when they're zero, for example 2026-10-01T08:00:00. So read timestamps with an ISO parser and not by fixed position.
• Webhooks: delivered events contain every time in UTC with Z.

Next stepsCopy Anchor Link