Looped Docs
Manage

API keys

Programmatic access for scripts, integrations, and external services

API keys let scripts, services, and third-party integrations talk to Looped on behalf of your team. Every key is scoped to a single team and a set of permissions.

The API keys page is OWNER/ADMIN only. Open it from SettingsAPI Keys.

Creating a key

  1. Click Create API Key.
  2. Give it a memorable name — "Zapier production", "Reporting service", "Joe's laptop". The name only matters to you.
  3. Pick a permission set:
    • Read All — read every resource the team has across all apps. Good for reporting / dashboards.
    • Write All — read and write everything. Use sparingly.
    • Restrict All — start from no permissions and tick exactly the scopes the integration needs. Best for least-privilege deployments.
  4. Optionally set an expiration date. After that date, the key stops working. Leave empty for non-expiring keys.
  5. Click Create.

A success screen appears with the raw key — it starts with looped_. Copy it now. Once you close that screen, the key cannot be retrieved (we only store its hash). If you lose it, revoke it and create a new one.

Hand the key to the integration that needs it (their dashboard, your team's secrets manager, an .env file, whatever).

Using a key

Send the key in the X-API-Key header on every request to https://api.looped.sh:

curl https://api.looped.sh/v1/invoices \
  -H "X-API-Key: looped_..."

The key carries the team scope — you don't pass teamId separately. The full endpoint reference lives at api.looped.sh (interactive Scalar UI) or api.looped.sh/openapi.json (machine-readable).

Editing a key

To rename a key or adjust its permissions / expiration:

  1. Click the menu on the key's row → View Details.
  2. Click Edit.
  3. Change name / scopes / expiration.
  4. Save Changes.

The key value itself does not change — your integration keeps working with the same looped_... value.

Revoking a key

Revoking immediately invalidates the key but keeps the row around so you can audit which key did what later. Use this when a key is leaked or rotated.

  1. Click the menu → Revoke Key.
  2. Confirm.

The badge flips from Active to Revoked and any further calls return 401.

Deleting a key

Deleting removes the row entirely. Use this for keys created in error or that you don't need to keep on record.

  1. Click the menu → Delete Key.
  2. Confirm.

The key disappears from the table.

Status badges

BadgeMeans
ActiveAuthenticates successfully
ExpiredPast its expiration date. Edit it via View Details to set a new expiration if you want to reactivate, or delete it
RevokedManually revoked. Cannot be reactivated — create a new key

Last-used timestamp

Each key shows a "last used" relative timestamp on the table. Useful for spotting keys that haven't run in months — candidates for cleanup.

Best practices

  • Give each integration its own key. Don't share a single key across services. Easier to rotate and audit.
  • Use Restrict All with explicit scopes for production keys. Write All is for development / personal use.
  • Set expirations on keys you'll only need temporarily (e.g. a one-off migration script).
  • Rotate keys periodically — every 90 / 180 days is a sensible default for production integrations.
  • If you suspect a leak, revoke first, ask questions later.

Are you an AI? Visit llms.txt — these docs as plain markdown.

On this page