React to uploads and downloads

The activity feed lists what happens to files and file requests on a service account’s domains: uploads, downloads, files people send, and changes to links and requests. Your system reads it every minute or so and acts on what’s new, for example posting to a chat channel or starting a scan. It’s part of every plan. Dew doesn’t push events to your system: reading the feed is how your system finds out.

Before you start, create a service account and token with the Monitoring: File activity permission. The feed shows events on the service account’s Domains, so choose the domains whose activity you need.

Read the feed

Ask for the events after the last one your system has seen:

curl -H "Authorization: Bearer dewsa_<token>" "https://files.example.com/api/admin/activity/feed?after_id=0"

{
  "success": true,
  "data": {
    "entries": [
      {
        "id": 48213,
        "timestamp": "2026-10-02T14:03:11.120000Z",
        "event_type": "file.downloaded",
        "actor": { "type": "external", "email": "bob@example.com" },
        "target": { "type": "file", "id": "kT9xQ2aZ", "name": "Q4 invoices.pdf" },
        "domain": "files.example.com",
        "metadata": { "via": "link", "size_bytes": 2483021, "owner_email": "anna@example.com" }
      }
    ],
    "next_after_id": 48213,
    "has_more": false
  }
}

1. Start with after_id=0 to read what’s stored.
2. Store data.next_after_id and send it as after_id in the next call.
3. Call again straight away while data.has_more is true, then check every minute or so.

Your system gets each event once and in order, as long as it stores next_after_id. Up to 1000 events come back per call (limit, default 500; a higher value returns 400).

Events worth reacting to

Event	When	Useful fields
file_request.received	Someone sent files to a file request	target.id (the request), metadata.file_id (the upload), metadata.file_count, actor.email
file.uploaded	A file was uploaded	target.id (the file), target.name
file.downloaded	A file was downloaded	target.id, actor.email (when the link asked for it), metadata.via
file.sharing_changed	Who can open a link changed	target.id, metadata.changes
file_request.created	A file request was opened	target.id, target.name

Every event and its fields are in the audit event reference, which the feed shares.

Keep a record of who downloaded what

To log deliveries, keep the file.downloaded events that came through a link and weren’t automated. Each has the time, the file (target.name and target.id), the downloader’s email in actor.email and their IP address in client_ip. This turns one page of the feed into CSV lines:

jq -r '.data.entries[] | select(.event_type == "file.downloaded" and .metadata.via == "link" and .metadata.automated != true) | [.timestamp, .target.name, (.actor.email // ""), (.client_ip // "")] | @csv'

• actor.email is set only when the link made the recipient prove their address, as an email-protected link does. Password-protected and open links record the time and IP address only.
• Downloads by the file’s owner, in Dew or over the API, and most link checks by email security systems are left out by this filter.
• For a single file, a download receipt is simpler: see Know when the file was downloaded.

Check it worked

Download a file on one of the service account’s domains in a private browser window, then read the feed again: a file.downloaded event for it is at the end.

If something doesn’t work

What you see	What to do
403 with “This API token doesn’t have permission for this action.”	Add Monitoring: File activity to the service account.
403 with “This API token doesn’t have permission for this action.” from a personal token	The feed is for service account tokens (dewsa_). Personal tokens can’t read it.
403 on every call, with the right permission	The system’s IP address isn’t on the Admin pages IP allowlist, if you use one. Add it in Settings → General settings → Advanced.
Events you expect don’t appear	They happened on a domain the service account doesn’t have.

The feed is in the Activity API reference.