Skip to main content
API keys are the simplest way to authenticate against the fsckmsft REST API. Each key is scoped to a single workspace, so your scripts, CI pipelines, and backend services can call the API with predictable, auditable credentials — without impersonating a real user account.

​
Create an API key

1

Open API Keys settings

Navigate to Settings → Developer → API Keys in your workspace.
2

Start a new key

Click New Key in the top-right corner of the API Keys page.
3

Name your key

Enter a descriptive name that identifies the consumer — for example, GitHub Actions Deploy or Data Export Script. Good names make auditing and revocation much easier later.
4

Choose permission scopes

Select the scopes this key needs. Apply the principle of least privilege: grant only what the consumer requires.
ScopeAccess granted
read:projectsList and read project data
write:projectsCreate and update projects
read:tasksRead task details
write:tasksCreate, update, and complete tasks
read:workflowsView workflow definitions and run history
write:workflowsTrigger and manage workflow runs
adminFull workspace access (use sparingly)
5

Optionally restrict by IP

Expand IP Allow-list and enter one or more CIDR ranges (e.g., 203.0.113.0/24). Requests originating outside those ranges are rejected with 403 Forbidden. Leave the field empty to allow all IPs.
6

Copy your key immediately

Click Create Key. The full key value is displayed exactly once.
Copy your API key now and store it in a secrets manager (e.g., AWS Secrets Manager, HashiCorp Vault, or a .env file that is never committed to source control). fsckmsft does not store the raw key and cannot show it to you again. If you lose the key, you must rotate it.

​
Use your API key in requests

Pass the key in the Authorization header of every request: 
curl -H "Authorization: Bearer YOUR_API_KEY" \
     https://api.fsckmsft.org/v1/projects
Replace YOUR_API_KEY with the actual key value. Never hard-code keys directly in source files — read them from environment variables or a secrets manager at runtime.
All API endpoints require HTTPS. Requests made over plain HTTP are rejected.

​
Manage existing keys

After creation, each key appears in the API Keys list with its name, creation date, last-used timestamp, scopes, and IP restrictions.

​
Rotate a key

Rotate a key when you suspect it has been compromised or as part of your regular credential-hygiene schedule.
1

Locate the key

Go to Settings → Developer → API Keys and find the key you want to rotate.
2

Click Rotate

Select ⋯ → Rotate next to the key. fsckmsft invalidates the old key and generates a new one immediately.
3

Copy the new key

Copy the new key value — it is shown only once, just like during creation.
4

Update your consumer

Replace the old key value wherever it is stored (CI secrets, environment variables, secrets manager) before the next request is made.
Rotation is instantaneous. The old key stops working the moment you confirm the rotation, so update your consumer before rotating in production environments.

​
Revoke a key

To permanently delete a key, select ⋯ → Revoke next to it and confirm. Revocation is irreversible — you must create a new key if you need access again.

​
IP allow-listing

IP allow-listing lets you restrict which network origins can authenticate with a given key. This adds a second factor of defense: even if the key value leaks, an attacker can only use it from an approved IP address.
​
cidr
string
required
A single IPv4 or IPv6 CIDR block, e.g. 203.0.113.42/32 for a single address or 10.0.0.0/8 for a private range.
You can add up to 25 CIDR ranges per key. Edit or remove ranges at any time from the key’s detail page — changes take effect within 30 seconds.
If your CI provider uses dynamic egress IPs, use their published IP range list and keep it updated, or consider using a fixed egress NAT gateway rather than maintaining a large allow-list.

​
Security best practices

One key per consumer

Create a dedicated key for each application, script, or service. This makes rotation and revocation surgical rather than disruptive.

Least-privilege scopes

Grant only the scopes each consumer needs. An export script never needs write:workflows.

Rotate regularly

Establish a rotation schedule — quarterly at minimum — even without a known compromise.

Audit last-used

Review the Last Used timestamp on each key periodically. Keys that have never been used or are stale are candidates for revocation.