Legal · Security

AspisFile audit event feed

For security and SOC teams

Your account’s complete audit trail — every share, open, approval, denial, revocation, capture attempt and failed sign-in — delivered to your own SIEM or log platform as structured JSON, each record carrying its proof on a public blockchain. Read-only, account-scoped, pull-based. Available on Business and Enterprise.

What you get

Every audit event your dashboard shows, plus authentication failures and lockouts — 35 event types.
On every event: what happened, when, which document, which recipient, which sender, from which IP, location, device and platform.
On every event: the fingerprint published to Polygon with the transaction and block, so your auditors can verify a record without trusting us.
Records that cannot be altered or deleted by anyone — including AspisFile — and are retained for 10 years by default.
A stable, versioned schema (aspisfile.audit-feed.v1) and cursor pagination that never misses or duplicates a record.

How access is governed

KeysCreated and revoked by the account owner in Settings → API keys, behind passkey or password confirmation. Up to 10 per account. Shown once; only a SHA-256 hash is stored.

ScopeRead-only (audit:read). The key sees the files its account uploaded and files shared with the teams the account currently belongs to — exactly what that account sees in its dashboard. Never another tenant.

NotificationThe account owner is emailed every time a key is created, with the key name, time and source IP.

RevocationImmediate — the next request with a revoked key receives 401.

Rate limits60 requests per minute per key; 120 per minute per source address before any key is looked up.

RecordKey creation and revocation are themselves audit events (api_key_created, api_key_revoked). Using a key updates its last-used time only.

The endpoint

GET https://aspisfile.com/api/v1/export/audit-events?limit=500
Authorization: Bearer ask_…

{ "schema": "aspisfile.audit-feed.v1", "events": [ … ], "next_cursor": "…", "has_more": true }

Events are returned oldest first. Store next_cursor and pass it back as ?cursor= on the next call to receive only what came after it. ?types=file_opened,file_revoked narrows the set; unknown types are ignored. Up to 500 events per call.

Works with Splunk (scripted or modular HTTP input), Microsoft Sentinel (Logic App on a recurrence trigger), Elastic / OpenSearch (httpjson input with cursor), or any scheduler that can make an HTTP request and remember one string.

Event types

Sharingdraft_published recipient_added file_reshared link_manually_sent reminder_sent resend_requested

Accessfile_opened one_time_consumed download_initiated file_downloaded download_confirmed

Approvals and denialsapproval_requested approval_granted access_approved approval_denied access_denied approval_expired

Revocationfile_revoked revoked recipient_blocked recipient_unblocked key_destroyed file_deleted file_auto_deleted

Securityviolation_detected violation_strike auth_failed auth_locked api_key_created api_key_revoked

Feedback and signaturerecipient_commented recipient_markup recipient_responded signed_pdf_generated owner_downloaded_signed_pdf

Every event carries

id · type · timeUnique id, event type, UTC timestamp to the millisecond.

fileId and name — stamped onto the record when it is written, so it survives deletion of the document.

recipientId and email address.

actorThe signed-in sender for sender actions, with erased: true after that account is closed (the record itself never changes).

sourceIP address, city and country, device fingerprint, user agent, platform (web, desktop, iOS, Android).

metadataA fixed, documented set: access method, duration, pages viewed, last page, end reason, session id; approval, denial and revocation reasons; violation type and strike count; authentication surface, reason and attempts left; download method; signer name and time; key name and prefix. Nothing else is ever forwarded.

anchorpending until the record is included in a batch (within minutes), then confirmed with its hash, chain (polygon:137), transaction, block, batch id and leaf index.

{
  "id": "c23bd079-2f6b-45e7-80c3-ed9ba2f8d484",
  "type": "file_revoked",
  "time": "2026-10-09T20:03:30.429Z",
  "file":      { "id": "06ac8bc2-…", "name": "Mandate.pdf" },
  "recipient": null,
  "actor":     { "id": "bedf3552-…", "erased": false },
  "team_id":   null,
  "source":    { "ip": "85.244.228.47", "location": "Lisbon, PT", "device": null, "user_agent": null, "platform": null },
  "metadata":  { "reason": "all_recipients_revoked", "ip_city": "Lisbon", "ip_country_code": "PT" },
  "anchor": {
    "status": "confirmed",
    "hash":   "0x3a3b686f66944c7ffc8451df298b748d6cc31b5e43349bbaf548b78ab3ffa2ec",
    "chain":  "polygon:137",
    "tx":     "0x3bd6029c815b4311d1408c24dc94475e1e6a1deeecf0b475057490efcf96bcc7",
    "block":  94495722, "batch_id": "…", "leaf_index": 3, "anchored_at": "2026-10-09T20:05:12Z"
  }
}

Verifying a record independently

Each record’s anchor.hash is a leaf of a Merkle root published in anchor.tx on Polygon. Recompute the hash from the record, check the leaf against the root in that transaction, and the record is proven to have existed, unchanged, at anchored_at — with nothing from AspisFile but the public chain. The same proof is shown on the document’s timeline in the dashboard.

What the feed does not include

Document content — never, in any form.
Any other account’s events.
Credentials, access codes, tokens or internal instrumentation.
Push delivery, webhooks or syslog — the feed is pull-based; latency is your polling interval.
Operational telemetry (page-tile requests, risk scores) — kept separately for 90 days to 12 months and not part of the evidence trail.

Questions

For a sample pull, a test key on a trial account, or integration help, contact hello@aspisfile.com.

← Back to AspisFile