Integrations & tokens

An integration token is an access for machines, not people: a script or cron job uses it to fetch data from Resilic without anyone signing in. The first use case is the security.txt, which has to be renewed every six months: a nightly job fetches the freshly signed file and places it on your web server – nothing is left to renew.

You’ll find the page under Settings → Integrations. Only an Owner or Admin sees it.

What a token may do

Tokens are read-only and carry an explicit scope:

Scope	What the script can fetch
security-txt:read	the signed security.txt for your company domain
provider-bundle:read	the CSAF provider bundle as a ZIP (provider metadata, key, advisories)

A token cannot change anything, publish anything or manage members. There are deliberately no write scopes.

Creating a token

1. Give it a name that says where it is used (e.g. “security.txt renewal on www-01”). It shows in the list and in the audit log.
2. Choose the scope and an expiry (90 days, one year or never). An expiry is the safe choice: a forgotten token runs out by itself.
3. Click Create token. The token is shown exactly once – copy it straight into your script or secret store. Resilic keeps only a hash; lost means create a new one.

The token starts with rsl_ and is sent as a bearer token:

Authorization: Bearer rsl_…

Example: renew security.txt by cron

On your own Linux web server (nginx, Apache, Caddy) a daily cron job is all it takes. The example is complete and built so that a failure never serves a broken file.

1. Store the token safely – readable by root only, never inside the script and never in a repository:

sudo install -m 600 /dev/null /etc/resilic/token
sudo sh -c 'echo "rsl_…" > /etc/resilic/token'

2. Create the script at /usr/local/bin/resilic-security-txt:

#!/bin/sh
# Fetches the signed security.txt from Resilic and swaps it in atomically.
set -eu
TOKEN="$(cat /etc/resilic/token)"
TARGET="/var/www/html/.well-known/security.txt"   # adjust to your web root
TMP="$(mktemp "${TARGET}.XXXXXX")"
trap 'rm -f "$TMP"' EXIT

curl -sSf --max-time 30 --retry 3 --retry-delay 10 \
  -H "Authorization: Bearer $TOKEN" \
  https://api.resilic.ai/api/integrations/v1/security-txt \
  -o "$TMP"

# Only install what looks like the signed file – never an empty or partial response.
grep -q '^-----BEGIN PGP SIGNED MESSAGE-----' "$TMP"
grep -q '^Expires: ' "$TMP"

chmod 644 "$TMP"
mv -f "$TMP" "$TARGET"

sudo chmod 755 /usr/local/bin/resilic-security-txt
sudo /usr/local/bin/resilic-security-txt   # run once by hand to check
curl -s https://your-domain.example/.well-known/security.txt | head -3

3. Cron entry – once a day, at an off-peak minute:

/etc/cron.d/resilic-security-txt

17 4 * * *  root  /usr/local/bin/resilic-security-txt

Why this shape:

• Once a day is enough. Every response is freshly signed and its Expires: date is about six months out. Calling more often gains nothing; a weekly job would be safe as well.
• mktemp + mv swaps the file in atomically. If the fetch fails (network, revoked token, maintenance), the previous valid file stays in place – and it remains valid for months.
• The two grep checks make sure only a real signed file is installed.
• The response is the exact file (text/plain, LF line endings, trailing line feed) – don’t post-process it, or the signature no longer matches.

Windows / IIS: the same as a PowerShell script, scheduled daily with Task Scheduler:

$token  = Get-Content 'C:\ProgramData\Resilic\token' -Raw
$target = 'C:\inetpub\wwwroot\.well-known\security.txt'
$tmp    = "$target.tmp"
Invoke-WebRequest -Uri 'https://api.resilic.ai/api/integrations/v1/security-txt' `
  -Headers @{ Authorization = "Bearer $($token.Trim())" } -OutFile $tmp -TimeoutSec 30
if (-not (Select-String -Path $tmp -Pattern '^-----BEGIN PGP SIGNED MESSAGE-----' -Quiet)) { Remove-Item $tmp; throw 'Unexpected response' }
Move-Item -Force $tmp $target

In IIS the .well-known directory must be allowed (request filtering: hidden segments) and .txt served as text/plain.

If your website runs on a builder or CMS without file access, the redirect to the CSAF host is the simpler route – no token needed.

Security and traceability

• Revoke a token as soon as a script is retired or the token was exposed. The next call is refused.
• The list shows Last used, so you can tell which tokens are still needed.
• Creating, revoking and use land in the audit log.
• A refused token gets a bare 401 with no reason; a token lacking the required scope a 403. Calls are limited per token (30 per minute) – far more than a daily job needs.
• Tokens are per organisation. A token from another organisation cannot read your data.