Authentication

Getting a key

API keys are issued by Loop support. Get in touch with the support team (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.