Invites, tokens & audit
In plain English
Three related things live here.
Invites are how you add a person. You enter their email and pick a role, they get a link, they click it, and they're in. The link works exactly once — so if it gets forwarded, or sits in an inbox that's later compromised, it's already dead.
Sending an invite doesn't grant anything. Access starts when they accept.
API tokens are how you give software access. If a tool needs to read your orders every night, it shouldn't be logging in as a person. A token is its own key with its own limited list of what it's allowed to touch.
Tokens start with copt_ and look like a long random string.
You'll see it once, when you create it. After that it's stored
scrambled — genuinely unrecoverable, even by us. Save it somewhere
safe immediately, and if you lose it, delete it and make a new
one.
The audit log records every permission check: who tried, what they tried, when, from where, and whether it was allowed. It records the denials too, which is often the more interesting half.
How to use it
Inviting someone
- Click "Team & Permissions", then "Invite member."
- Enter their email and pick a role.
- Send. They get a link.
- Check they've accepted. Until they do, they have no access.
Creating an API token
- Go to the API tokens section.
- Click "Create token" and give it a name describing what it's for — "nightly warehouse sync," not "token 1."
- Tick only the permissions that tool actually needs.
- Copy the token immediately and store it in a password manager. You won't see it again.
- Delete tokens you're no longer using.
Reading the audit log
- Open the audit log.
- Filter by person, action, or date.
- Look at the denials. Repeated denials mean either someone needs more access, or someone is trying to do something they shouldn't.
⏱ ~2 min per invite or token · 💳 Pro+ · 🎯 Add people and software safely
Why this matters for your business
The usual way software gets access to a shop is that somebody creates an account for it — often with full permissions, often using a shared password, often named something like "integration." It works, and it's a bad idea for three reasons.
It can do far more than it needs. It's indistinguishable from a person in any log. And when the person who set it up leaves, nobody knows what it's for or whether it's safe to turn off. Most shops running for a few years have at least one of these mystery accounts nobody dares touch.
A token fixes all three. It's clearly software, it has a name saying what it's for, and it can only do the specific things you ticked. If it's ever misused, the damage is bounded by that list.
Single-use invites solve a smaller but real problem. An invite link that keeps working is a permanent key sitting in an email inbox. Forwarded once — "can you handle this?" — and it's now in two inboxes. Single-use means the link is spent the instant it's used.
The audit log matters for two different reasons. Day to day, it answers "who changed that?" without an awkward conversation. And if you ever need to demonstrate access control to a customer or an auditor, it's the evidence.
What this typically unlocks
| What you get | Typical result |
|---|---|
| Over-privileged integration accounts | Replaced with limited tokens |
| Invite links that keep working | Eliminated — single use |
| "Who changed that?" | Answerable, including denials |
| Mystery accounts nobody can turn off | Prevented — tokens are named and scoped |
| Evidence for a security review | Available on demand |
What you actually get
How invites work
| Step | What happens |
|---|---|
| You send it | A one-time link is generated. No access is granted yet |
| They receive it | An email with the link |
| They accept | Access begins. The link is spent |
| Anyone tries it again | It doesn't work |
Why single-use matters. A reusable link is a key that lives forever in an inbox. Forwarded, leaked, or found in an old mailbox years later, it would still work. This one is dead after first use.
One thing you can't do: invite someone as Owner. Owner cannot be granted through an invite or by assigning a role. It's the one guarantee that prevents the whole system being bypassed.
API tokens
| Property | What it means |
|---|---|
| Format | Starts with copt_, followed by a long random string |
| Shown once | At creation. Never again |
| Stored scrambled | We hold a one-way fingerprint, not the token |
| Explicitly scoped | Only the permissions you tick |
| Revocable | Delete it and it stops working immediately |
Why we can't show it to you again. The token is stored as a one-way fingerprint — enough to check a token you present, not enough to reconstruct it. That's deliberate. If we could show it to you, anyone who got into our systems could see it too.
Scoping a token properly
The rule is simple: tick only what it needs.
| Tool's job | Should have | Should not have |
|---|---|---|
| Nightly sales export | Read analytics, read revenue | Anything that writes |
| Warehouse stock sync | Read and update stock | Customer data, billing |
| Reporting dashboard | Read-only across analytics | Any write permission |
| Order-to-ERP feed | Read orders | Product management, settings |
If the tool is compromised, the damage stops at that list. A read-only reporting token can leak data but cannot change or delete anything.
The audit log
Every permission check is recorded:
| Recorded | Why it's useful |
|---|---|
| Who | The person or token |
| What | The permission checked |
| When | Timestamp |
| From where | IP address and browser |
| Outcome | Allowed or denied |
Denials are recorded too, and they're often more useful.
| Pattern | What it usually means |
|---|---|
| One person, repeated denials on one thing | Their role is too narrow — upgrade them |
| Many denials across many areas | Someone exploring, or a misconfigured tool |
| Denials from an unfamiliar location | Worth investigating |
| Token denied on something it never needed | The tool changed. Check what it's doing |
Practical token hygiene
✅ One token per tool. Shared tokens can't be revoked independently.
✅ Name it for its job. "Nightly warehouse sync" tells the next person what breaks if they delete it.
✅ Store it in a password manager, not in a spreadsheet or a chat message.
✅ Delete tokens for tools you've stopped using. They're the mystery accounts of tomorrow.
✅ Rotate periodically — delete and recreate, updating the tool.
How it works (without the technical bits)
Real merchant scenarios
Scenario A — The integration account nobody dared delete
Setup. Apparel brand, six years trading. An account called "integration@" with full admin access. Nobody knew what used it. Everyone was afraid deleting it would break something.
Audit log over 30 days showed it doing exactly three things: reading orders, reading products, updating stock levels.
Action. Created a token scoped to those three things, pointed the warehouse tool at it, and deleted the old account.
| Before | After | |
|---|---|---|
| Permissions held | All 101 | 3 |
| Identifiable as software | No | Yes |
| Purpose documented | No | In the token name |
| Safe to revoke | Nobody knew | Yes |
The audit log turned a six-year unknown into a ten-minute job.
Scenario B — The forwarded invite
Setup. Merchant invited a freelance designer. The designer was unavailable and forwarded the email to a colleague — "can you pick this up?"
The colleague accepted and got access under the designer's name and email.
Caught in the audit log — the accepting IP and browser didn't match anything the designer had used before, and the pattern of activity was different.
Why single-use still helped. The link was spent, so it couldn't spread further. The merchant revoked that membership and invited the colleague properly, under their own name.
What it changed. Their process now says invites go to the person who will use them, never forwarded — and the audit log showed them why that matters.
Scenario C — A leaked token that cost nothing
Setup. Merchant's reporting token was accidentally committed to a public code repository by a contractor.
What the token could do: read analytics and revenue. Nothing else.
What happened. They spotted it in the audit log — reads from an unfamiliar location — deleted the token, created a new one, and updated the tool. Total exposure: about six hours of read-only access to sales figures.
What it would have cost with a full-access account. Products could have been changed or deleted, customer data exported, settings altered, billing touched.
The scope list turned a serious incident into an inconvenience.
Scenario D — Denials revealing a role that was too narrow
Setup. Customer-service lead kept asking a colleague to look things up for her.
The audit log showed 47 denials over three weeks, all on the same permission: reading order attribution.
Nobody had reported it. She'd assumed it was intentional and worked around it, at the cost of two people's time.
Action. Moved her from Support to a custom role with that one permission added.
Result. The workaround stopped, and the second person got about three hours a week back.
Denials aren't only about security. They're a very good signal that someone's access doesn't match their job.
Scenario E — Evidence for an enterprise buyer
Setup. B2B supplier asked during a procurement review to demonstrate access control and produce evidence.
What they showed:
| Requirement | Evidence |
|---|---|
| Individual accounts | The team list |
| Role-based access | Six roles with permission counts |
| Access logging | The audit log, filtered live |
| Immediate revocation | Demonstrated in the meeting |
| Software uses limited credentials | Token list with scopes |
| Dormant accounts closed | The 90-day policy |
Took about fifteen minutes and moved the review straight past the access-control section.
Best practices
✅ Send invites directly to the person who'll use them. Never forwarded.
✅ Confirm invites were accepted. Unaccepted means no access.
✅ One token per tool, named for its job.
✅ Tick the minimum permissions. Scenario C is the argument.
✅ Save tokens in a password manager immediately. You get one chance.
✅ Review denials monthly. They find both security issues and access that's too narrow.
❌ Don't create a person-shaped account for software. Use a token.
❌ Don't give a token full access "to be safe." It's the opposite of safe.
❌ Don't leave tokens for retired tools. They become tomorrow's mystery account.
❌ Don't ignore repeated denials. Scenario D was costing two people's time.
Plan tiers
| Capability | Free | Starter | Pro | Agency | Enterprise |
|---|---|---|---|---|---|
| Single-use invites | — | — | ✓ | ✓ | ✓ |
| API tokens with scopes | — | — | ✓ | ✓ | ✓ |
| Audit log | — | — | ✓ | ✓ | ✓ |
| Filter and export the log | — | — | ✓ | ✓ | ✓ |
| Token rotation | — | — | ✓ | ✓ | ✓ |
| Cross-store audit view | — | — | — | ✓ | ✓ |
Frequently asked
Can I see a token again after creating it? No. It's stored as a one-way fingerprint. Delete it and create a new one if it's lost.
What if an invite email doesn't arrive? Check spam, then re-send. The original link is still unused, so nothing has been granted.
Can two people share one invite link? No. It's spent on first use.
Can I invite someone as Owner? No. Owner cannot be granted by invite or by assigning a role.
How long do tokens last? Until you delete them. Rotating them periodically is good practice.
Does the audit log record failed attempts? Yes — allowed and denied are both recorded, with who, when, and from where.
How far back does the log go? Retention depends on your plan. Export anything you need to keep long term.
Should each tool have its own token? Yes. Shared tokens can't be revoked independently, so one compromised tool forces you to break the others.
See also
- Team & permissions — the roles these invites assign
- Developer API — what tokens are used with
- API keys & scopes — the technical detail
- Agency & multi-store — managing access across shops
- GDPR & consent — data-protection obligations
- Billing & plans — what's included at each tier