Automate Discord backups from CI with the RestoreCord API
The riskiest moment for a Discord server is the minute after someone changes it. A one-line pipeline step can take a RestoreCord snapshot first, so every change is reversible.
Short answer
Create an API key with only CREATE_BACKUPS, then call POST /api/v3/servers/{serverId}/snapshots from your pipeline before the change runs. Name the snapshot after the release, stop on 401 or 403, and retry 429 with backoff.
Why snapshot from a pipeline
Teams that manage roles, channels or bots with scripts change their server far more often than a human would. Each run is a chance to delete the wrong channel or overwrite permissions. A snapshot taken by the same pipeline gives you a rollback point labelled with the exact release that ran.
The request
Snapshot creation needs CREATE_BACKUPS and starts an asynchronous job:
curl -sS -X POST "https://restorecord.com/api/v3/servers/$SERVER_ID/snapshots" \
-H "Authorization: Bearer $RESTORECORD_KEY" \
-H "Content-Type: application/json" \
-d '{
"snapshotName": "release-'"$GIT_SHA"'",
"snapshotDescription": "Taken by CI before deploy",
"messageCount": 50
}'A successful call returns the new job's ID straight away:
{
"success": true,
"message": "Snapshot creation started successfully.",
"snapshotId": "snap_abc123"
}Log the snapshotId with your build. You can list snapshots later with GET /api/v3/snapshots, and pin an important one with a PATCH that sets pinned to true.
Plan limits still apply
| Plan | Stored snapshots | Messages per channel |
|---|---|---|
| Free | 1 | 50 |
| Premium | 5 | 200 |
| Business | 30 | 500 |
| Enterprise | 50 | 2,000 |
If your pipeline runs many times a day, set messageCount to what you actually need and pin the releases you care about, so rotation keeps them. Business and Enterprise can also schedule automatic backups in the dashboard alongside your pipeline snapshots.
Handling the response
| Status | Meaning | Pipeline action |
|---|---|---|
| 2xx | Job started | Record the snapshotId and continue |
| 400 | Invalid body or ID | Fail the step, it's a bug in the script |
| 401 | Key expired, revoked or IP-blocked | Fail and alert the key owner |
| 403 | Missing permission or plan gate | Fail, fix the key or plan |
| 429 | Rate limited | Wait with jitter and retry a few times |
| 5xx | Service or dependency error | Retry with exponential backoff, then fail |
Path IDs like {serverId} are RestoreCord's internal server IDs, not Discord guild IDs. Fetch them once with GET /api/v3/servers and store them as pipeline variables.
When you need the rollback
Restoring is a separate permission, RESTORE_BACKUPS, on purpose. Keep it off the CI key. Restore by hand from the dashboard or with a dedicated recovery key, so a compromised pipeline can create backups but never overwrite your server with one. A calm rollback usually looks like this:
- Find the snapshot named after the last good release in your build log or in the dashboard.
- Open it in the backup previewer and confirm the channels and messages you expect are there.
- Restore with a person watching, from the dashboard or with the separate recovery key.
- Revoke and replace the CI key if the incident started with a compromised pipeline.
Snapshot captured before the permission redesign.
Roles and overwrites look right in the preview.
Backup completed — 42 channels, 18 roles, 6,300 messages.
See how to scope keys and how to receive snapshot.create events, or go back to the developer home.
Pre-deploy snapshot checklist
Tick these off once and every pipeline run after that leaves a clean rollback point behind.
Key holds CREATE_BACKUPS only
No restore, pull or member permissions on anything a build runner can read.
Runner IPs allowlisted
A copied secret is useless from a laptop outside your CI network.
Server ID stored as a variable
The internal RestoreCord ID, looked up once, not the Discord guild ID.
Name carries the commit
release plus the short SHA makes the right snapshot obvious during an incident.
Failures stop the deploy
If the snapshot request fails, the change waits until it succeeds.
Key expiry in the calendar
Replace the CI key a week before it lapses so a release never fails on 401.
Add a snapshot step to your pipeline
Give CI its own key
Create a key with only CREATE_BACKUPS and allowlist your runners' IP range.
Call the snapshot endpoint
POST to /api/v3/servers/{serverId}/snapshots with a name that includes the release or commit.
Handle the response
Fail the job on 401 and 403, back off on 429 and log the snapshotId on success.
Snapshot automation questions
Make every deploy reversible
One key, one request, and your Discord server has a labelled rollback point before each change.