Signed URLs and access

Public assets are served straight from their delivery path with no authentication. Private assets are different: they only open through a signed URL, a link that carries its own time-limited authorization. This page covers signed URLs and, for bulk imports, scheduled SFTP sync.

Signed URLs

A signed URL lets you hand a private file to someone who isn't signed in, an email recipient, a partner system, a webhook target, without making the file public. The link works until it expires, then stops.

Mint one with a POST to the asset's sign endpoint. Set how long the link should live with ttl_seconds (up to 604800, seven days; the default is one hour).

curl -X POST https://api.revenexx.com/v1/storage/assets/<ASSET_ID>/sign \
  -H "X-Revenexx-Api-Key: <API_KEY>" \
  -H "X-Revenexx-Tenant: <TENANT_SLUG>" \
  -H "Content-Type: application/json" \
  -d '{ "ttl_seconds": 3600 }'

The response is a ready-to-use delivery URL with an expiry and signature attached, plus the seconds until it expires:

{
  "url": "https://shop.example.com/cdn/private/contract.pdf?expires=1750680000&signature=...",
  "expires_in": 3600
}

Hand that URL to whoever needs the file. After the expiry time, the link returns a 403 and the file is no longer reachable through it. Mint a fresh URL whenever you need renewed access.

A signed URL cannot be revoked before it expires. The signature is checked at the delivery edge, and there is no call that cancels a link you already handed out. Keep ttl_seconds short and sign on demand, on your server, rather than minting a long-lived link up front.

Public vs. private

A public asset needs no signing, link to it directly. Only private assets require a signed URL. Set an asset's visibility at upload or change it later with a metadata update.

SFTP sync

For large or recurring imports, signing and uploading file by file is the wrong tool. Instead, configure a sync rule that pulls files from your own SFTP storage into a Storage folder on a schedule. revenexx fetches the files and creates assets for you; you never wire up an upload pipeline.

A sync rule describes where to pull from, where to put the files, and how often:

curl -X POST https://api.revenexx.com/v1/storage/sftp/rules \
  -H "X-Revenexx-Api-Key: <API_KEY>" \
  -H "X-Revenexx-Tenant: <TENANT_SLUG>" \
  -H "Content-Type: application/json" \
  -d '{
    "sftp_account_id": "<ACCOUNT_ID>",
    "source_path": "/exports/images",
    "target_folder_id": "<FOLDER_ID>",
    "schedule": "*/5 * * * *",
    "enabled": true
  }'

List your rules, inspect a single rule, and review past runs:

# all rules
curl https://api.revenexx.com/v1/storage/sftp/rules \
  -H "X-Revenexx-Api-Key: <API_KEY>" \
  -H "X-Revenexx-Tenant: <TENANT_SLUG>"

# sync history
curl https://api.revenexx.com/v1/storage/sftp/sync-history \
  -H "X-Revenexx-Api-Key: <API_KEY>" \
  -H "X-Revenexx-Tenant: <TENANT_SLUG>"

Each run reports what it transferred, so you can confirm an import landed. Creating, changing, and running rules requires an administrator-level key; reading rules and history works with a standard key.

Work with one rule by its ID:

• GET /v1/storage/sftp/rules/<RULE_ID> returns the rule's configuration and last_run_at. last_run_at shows when a run was last attempted, not whether it succeeded.
• PATCH /v1/storage/sftp/rules/<RULE_ID> changes the fields you send. To pause a rule, set enabled to false. Send the whole options value when you change it, because it is replaced, not merged. A change applies from the next run.
• DELETE /v1/storage/sftp/rules/<RULE_ID> removes the rule so it never runs again. Assets it already imported stay where they are. A deleted rule cannot be restored, so pause it with PATCH if you may need it again.
• POST /v1/storage/sftp/rules/<RULE_ID>/run queues a run now, outside the schedule. It answers 202 with the rule ID, not a run ID, so follow the result in the sync history. The schedule is not changed. A disabled rule is not enabled by this call, and its queued run does nothing.
• GET /v1/storage/sftp/rules/<RULE_ID>/runs/<RUN_ID> returns the per-file record of one run: the source path, the asset each file produced, bytes, duration, and any error, plus a summary counting entries by status. Take run_id from the sync history. Under a rule that exists, an unknown run ID returns an empty record, not a 404.

What's next

• Access control & visibility — how public and private decisions are made.
• Upload & manage files — the direct upload path for one-off files.