Give access the safe way.
What we need from each kind of platform, how to grant it, and how to take it back. Anything secret goes only through your secure customer dashboard, and you stay in control.
Every access and API key request lives in your dashboard.
Whatever a platform needs, we ask for it in one place only, and you send it in one place only. That makes it easy to spot a fake request.
Requests come from the dashboard
When we need access, an API key or a login, the request appears in your customer dashboard with the platform, the exact permission and the reason. We do not request access by email, chat or the contact form.
Answers go to the dashboard
Enter the key, token or login in the request itself. If a platform uses an invitation or app approval instead, mark the request done there so we know to look.
Anything else is not us
If a message, form or chat ever asks you to send a password or API key, do not reply with it. Open your dashboard, and tell us through the contact form without any secret in it.
The forms refuse secrets
Our contact, quote and upload forms detect what looks like a password or API key and stop the message, so a key can never reach us by accident.
What we need, platform by platform.
Open the tab that matches your tools. Each lists what we need and exactly how to grant it.
Payment platforms hold the most sensitive data we touch, so we ask for the least.
| Need | How to grant it |
|---|---|
| Read access to payments, customers and refunds | Create a restricted API key in the platform’s developer settings with read permissions only for the objects we need, then enter it in your dashboard under your project’s Access tab. |
| Webhooks for live events | We give you an endpoint address and a signing secret in your dashboard. You paste them into the platform’s webhook settings. |
| Test mode first | We build against the platform’s test mode with test keys you enter in your dashboard, then switch to live with your approval. |
| Write access (rare) | Only if the scope needs us to create or change records, and only for the specific objects. |
| Refunds and disputes | Read access to see them. We do not issue refunds on your behalf unless the scope says so. |
A full secret key can move money. If a platform only offers full keys, tell us before sharing and we will propose an alternative.
CRMs and helpdesks usually support dedicated users with limited roles and app authorization.
| Need | How to grant it |
|---|---|
| A user for the automation | Invite a dedicated user (for example ‘automation@yourcompany’) with a custom role limited to the objects and actions required. |
| App authorization (OAuth) | Approve the connection on the platform’s consent screen. Review the requested permissions and revoke it from the connected-apps page at any time. |
| Field mapping | A list of the fields to read or write, including any custom fields and picklist values. |
| Sandbox | A sandbox or developer account where one exists. Otherwise a small set of test records. |
| Seats and licenses | Some platforms charge for an extra user. Tell us if so and we will use app authorization instead. |
Workspaces share data by page, folder, channel or sheet, so we ask for access to exactly those.
| Need | How to grant it |
|---|---|
| Notion | Create an integration, share only the specific pages or databases with it. Connections cannot see anything not shared. |
| Google Sheets and Drive | Share the specific spreadsheet or folder with a service user or authorize an app. Prefer ‘editor’ only on the sheets involved. |
| Slack and Teams | Add the app to the channels it needs. Bots can only post where they are invited. |
| Airtable and similar | Create a scoped personal access token limited to the bases and scopes required and enter it in your dashboard. |
| Shared drives | Give access to a single folder rather than the whole drive. |
Store platforms need access to orders, products and customers, and sometimes to inventory and shipping.
| Need | How to grant it |
|---|---|
| Shopify and similar | Create a custom app in the admin with only the required scopes, or invite a staff account with limited permissions. |
| WooCommerce and WordPress | Generate a REST API key with read or read/write permission for a dedicated user (never an administrator’s own account) and enter it in your dashboard. |
| Marketplaces | Authorize our app through the marketplace’s seller-authorization flow. |
| Staging | A staging copy of the store, if you have one, for testing before live. |
| Shipping and fulfillment tools | A scoped API key limited to labels, rates and tracking, entered in your dashboard, or an app authorization. |
Messaging and chatbot platforms involve customer conversations, so permissions and templates matter.
| Need | How to grant it |
|---|---|
| WhatsApp, SMS and voice | Approved sender numbers and message templates. We use the provider’s console roles, not your login. |
| Chatbot builders | A project invitation with the ‘builder’ role. We avoid ‘owner’. |
| Forms and lead ads | App authorization to read submissions. We confirm what consent text is stored with each lead. |
| Email marketing | A scoped API key limited to the lists, tags and campaigns required, entered in your dashboard, or an app authorization. |
| Social platforms | Business or page roles that allow the actions required, authorized through the platform’s own flow. |
Four ways to grant access, from safest to last resort.
We use the first method that works for a platform. The last is rare, and we explain why when we need it.
1. App authorization (OAuth)
You approve a consent screen that lists permissions. No password or key changes hands, and you revoke it from the platform.
2. A dedicated user
You invite a user with a limited role. It appears in the audit log and you remove it at handover.
3. A restricted key
You create a key with only the needed permissions and enter it in your secure customer dashboard. It is never sent by message, form or email.
4. A shared login (last resort)
Only if a platform offers nothing else. You enter the login details in your dashboard, we say why we need them, use a dedicated account, and you rotate it at handover.
Six rules we never break.
Whatever the platform, these rules hold. If a request ever seems to break one, question it.
No passwords
We never accept a password in a message, form, file or email. Login details go only into your secure customer dashboard.
Smallest scope
The narrowest permission that does the job. Read before write.
Dedicated accounts
We use a dedicated user or app authorization, never a colleague’s personal login.
Secrets via the dashboard
If a key must be shared, enter it in your secure customer dashboard. Never email, chat or form.
Sandbox first
Test with test data before touching live records.
You stay in control
You can see and revoke every permission at any time.
Taking access back.
Your handover document lists every permission we used. Revoking them takes minutes.
- 1
List
The handover document lists each connection, key, role and webhook we used.
At delivery - 2
Rotate
You rotate or delete any keys created for the project.
Same day - 3
Revoke
Remove our dedicated user and disconnect app authorizations.
Same day - 4
Confirm
Tell us it is done. We delete our working copies 90 days after handover.
Within 90 days
Questions about access.
The things security teams and cautious owners ask before granting a single permission.
What if our IT team controls access?
Send them the access and requirements page. It lists exactly what we need for each kind of platform, why we need it and how to grant it with the least permission possible. We can also put a short written request in your customer dashboard that your IT team can attach to their own ticket, so the approval trail is clear on both sides.
Do you need admin access?
Almost never. We ask for the narrowest role or scope that does the job, and prefer a dedicated user or an app authorization over an administrator account. If a platform truly leaves no alternative for a required action, we tell you which action, why it needs elevated rights and what we will do with them, so you can decide whether to proceed or choose a different approach.
What if there is no sandbox?
We test with a small set of real or dummy records that you choose, clearly labeled so they are easy to spot and remove. The first run is read-only wherever possible, and we only switch on writing after you have seen what the automation would do. Where a platform has a test mode or a free developer account, we use that first, and we say so in the plan.
Can I watch what you do?
Yes, and we encourage it. Most platforms keep an audit log of every action taken by a user or an app, and because we use a dedicated user or app authorization, our actions are easy to tell apart from yours. Looking at that log during a project is a good habit, and it also confirms at handover that we only touched what the scope covered.
How do I send a key or login that must be shared?
Only through your secure customer dashboard. After payment you are redirected to log in, and every request for access or an API key appears there with the platform, the exact permission and the reason. Enter it in that request. Never send a password, key or token by message, form, file or email, because those leave copies you cannot control.
Will adding a user cost me a license?
On some platforms it can, because each extra user is a paid seat. If that applies to you, tell us and we will use an app authorization or a service account instead, where the platform allows one. We flag this in the access plan before you invite anyone, so a license cost is never a surprise on your next invoice.
What if my approver is away?
Tell us who else can approve, or when the approver returns. The delivery clock waits for access, so a delay on your side does not use up your delivery window. If the wait goes beyond five business days we pause the clock formally and restart it the day access arrives, and we keep your place in the queue so the project resumes without re-planning.
Can I give read-only access first?
Yes, and we prefer it. We start read-only so we can study your data and prove the logic without any risk of changing records. Write access is requested only when the build genuinely needs it, for the specific objects involved, and usually only for the final testing and go-live steps. You can take it back at any time.
What happens to the access after the project?
Your handover document lists every connection, key, role and webhook we used, with steps to revoke each one. You rotate or delete the keys made for the project and remove our dedicated user, which takes minutes. We delete our own working copies 90 days after handover, or sooner if you ask. Nothing keeps working in the background without you knowing.
Is it safe to use my own login?
We would rather not. Sharing a personal login mixes your actions with ours in the audit log, can break when you change your password and breaks the rule that credentials belong in the dashboard only. A dedicated user or an app authorization is safer for you and cleaner for everyone, and it can be removed in one step without affecting your own account.
What about two-factor authentication on the platform?
Keep it on. Dedicated users and app authorizations work with two-factor authentication, and we never ask you to turn it off or to share one-time codes. If a platform makes two-factor awkward for a service account, we explain the options, which usually means an app authorization or a key created from your own authenticated session.
What if the platform asks for a security review of the app?
Tell us as soon as you know. Some platforms review an app before approving it, which can add days to the schedule and is outside our control. When we know about a review, we put it in the plan with an estimated date, adjust the delivery window honestly and, where possible, build against a sandbox in the meantime so the work is ready when approval arrives.
Ready to get started?
Tell us your platforms and we will tell you exactly what access, if any, is needed.