Generating an API token for the open API

Where to generate tokens

The open API lets your own code read and write Avago data, and every request is authenticated with a token. Generate tokens from the API or Developer area of your settings. Create a separate token for each integration or script rather than reusing one everywhere — that way you can revoke a single token without breaking everything else, and the audit log tells you exactly which integration did what.

Per-scope permissions

Tokens are scoped, so each one only carries the permissions it actually needs. When you create a token, grant the narrowest set of scopes that does the job:

• Read-only scopes for something that just pulls data.
• Write scopes only where the integration needs to change things.
• Separate scopes per resource, so a token for form submissions can't touch billing.

Least privilege is the rule: a leaked read-only token is far less damaging than a leaked all-access one.

The audit log

Every token's activity is recorded in an audit log. It shows which token did what and when, which is your trail if something looks wrong. Review it periodically, and if you ever see activity you don't recognise, revoke the token immediately and issue a fresh one.

What never to expose client-side

This is the rule that matters most:

• Never put an API token in front-end code, a public repository or anywhere a browser can read it.
• Tokens belong on a server you control, in environment variables or a secrets store.
• If a token is ever exposed, treat it as compromised — revoke it and rotate to a new one.

Webhooks are often the safer choice for getting data out of Avago — they push events to your server without you holding a powerful write token in the open at all.