Authentication

Getting a key

API keys are issued by Loop support.

Get in touch with the support team here

or ask your account manager to do it on your behalf and let them know:

• Which agency (and which team within that agency) the key is for
• What you're building, in a sentence or two
• Who should receive the key
  Each key is a GUID — a 36-character string that looks like this:

8f3a91c2-4b7e-4d6a-9c1f-2e8b5a7d3f10

Treat it like a password. Anyone with the key can read data through the API as if they were you, so don't paste it into client-side JavaScript, don't commit it to a public repository, and don't send it over email or chat if you can avoid it.

How keys map to teams

Every API key is tied to a single team in Loop. When you make a request, the API knows which team you're acting on behalf of from the key alone — you don't pass a team ID separately.

This means:

• The data you can see is scoped to that team. Properties, branches, and other records belonging to other teams won't appear in your responses.

• If an agency has more than one team and you need data from each, you'll need a separate key per team.

• If a key is rotated or revoked, only that team is affected.

  If you're not sure which team your key belongs to, ask the Loop support team.

Looking after your key

A few sensible habits:

• Store keys in environment variables or a secrets manager, not in source code.
• Rotate immediately if you think a key has leaked. Ask support to issue a new key and revoke the old one.
• Keep keys server-side. Because v1 is built for websites, it can be tempting to call the API directly from the browser — don't. Proxy requests through your own backend so the key never reaches the visitor's machine.