Integrations: What a Logo on the Page Actually Means
Vendors publish a logo wall and let you assume every tile means the same thing. It never does. The four genuinely different kinds of integration, what each one is actually worth, and the two questions that tell you which kind a logo represents.
Every operations platform has an integrations page and every integrations page is a grid of logos. What the grid never tells you is that the tiles are four completely different products. One means "we will post a message into your Slack channel". One means "we hold OAuth tokens and push records into your Salesforce nightly". One means "we will accept an HTTP request from anything you can point at us". And one means "we have a working two-way client for a payment rail with money moving through your own credentials".
Those four have wildly different value and wildly different failure modes. Being able to tell them apart is most of what integration evaluation is.
The four kinds, in ascending order of how much they can go wrong
What a logo on an integrations page can mean
Notification out
An event happens here and a message appears somewhere your team already looks — Slack, Teams, Google Chat, Discord, Telegram, WhatsApp, email or SMS. One direction, no state, and if it fails you have missed a message rather than corrupted a record. This is most of every logo wall in the industry and it is genuinely useful.
Records pushed out
Customers, contacts or deals copied into another system on request — Salesforce, Notion, Airtable, Mailchimp, Google Sheets. One direction, and it holds state, which means it can create duplicates if the matching key is wrong. Ours upserts against an external-id field you add, which is the whole reason that setup step exists.
Files archived out
Documents copied to your own storage as they are created — Google Drive, Dropbox, OneDrive, S3. Fires on the event rather than on a schedule, which is the right design: an archive that runs nightly is an archive that is wrong all day.
Two-way transactional
A real client against a real API where something irreversible happens — M-Pesa collections and disbursements through your own Daraja credentials, eTIMS invoice transmission to KRA, card collection through Paystack. This is the only category where a failure costs you money rather than information, and the only one worth interrogating in detail.
Anything inbound
A single authenticated, optionally HMAC-signed inbound webhook that turns an external event into a notification here, and can trigger a workflow. One door rather than a per-vendor list, which is honest about what it is: a general-purpose receiver, not a Shopify integration.
Note what is absent from that list: nothing pulls data in on a schedule from another business system. There is no bank feed, no statement import, no marketplace order poller. Inbound is push-only, through the door above.
The two questions that decode any logo
Ask these about every tile that matters to you
Which direction does data move, and what triggers it?
Weak answer
"It syncs."
What to ask next
Push, pull or both? On an event, on a button, or on a schedule? A "sync" that turns out to be a manual button is not wrong — it is just a different thing from what you were about to plan around.
Whose credentials, and whose account does the money or the data land in?
Weak answer
"It's all handled."
What to ask next
For payments this is the whole question. Funds moving through your own Daraja shortcode with your own keys is a completely different risk position from a vendor sitting in the settlement path. Ask where the money lands before it reaches you.
Platform apps versus bring-your-own-key
A distinction worth understanding because it decides how long setup takes and who is exposed if something goes wrong.
OAuth through a platform app
- You click connect, sign in to Google or Microsoft or Salesforce, and approve.
- Setup is a minute. No keys to paste, nothing to keep safe.
- Refresh tokens are held per organisation, so a revoked grant breaks only you.
- The catch: the connection depends on the platform app staying approved by Google or Microsoft, which is not something you control.
- Used here for Drive, Dropbox, OneDrive, Sheets, Workspace, Microsoft 365, Salesforce and Google sign-in.
Bring your own credentials
- You paste a key, a token or a webhook URL from your own account.
- Setup is five to twenty minutes and needs someone with access to the other system.
- The advantage: it is entirely yours. Nothing sits between you and the provider, and your rate limits and your billing are your own.
- Also the honest answer for anything involving money — your Daraja credentials, your Paystack keys, your eTIMS credentials.
- Used here for Teams, Discord, Google Chat, Slack in webhook mode, Telegram, WhatsApp, all three SMS providers, Mailjet, Mailgun, Brevo, Mailchimp, Notion, Airtable, S3, PandaDoc, eTIMS, M-Pesa and Paystack.
Single sign-on has one step nobody expects
A user has to sign in with their password once and link their Google or Microsoft account before they can use it to sign in. The callback rejects an unlinked account deliberately — otherwise anyone who could create an account with a matching email address at the identity provider could walk into your organisation. It is one extra step at onboarding and it is the correct design.
The scheduling gap, stated plainly
Record and calendar syncs run when somebody presses "sync now", which dispatches a queued job. There is no nightly automatic sync wired up. Document archiving is the exception and is event-driven, firing as documents are created — which is the right way round, since an archive that catches up at 3am is wrong for the whole working day.
For most SMEs this matters less than it sounds, because the records being pushed out are contact-level rather than transactional. But if you were planning to have your CRM continuously current without anyone touching a button, know now that it is a button.
What to actually integrate, in order
-
One notification channel, on day one
Wherever your team already argues about work — usually a WhatsApp group or a Teams channel. Route approvals and low-stock alerts there. This is twenty minutes of setup and it is the integration that changes behaviour, because it puts the system into a place people already look.
-
Payments, if you collect through M-Pesa
The auto-match of a C2B payment quoting an invoice number to that invoice is the highest-value integration in the product for a Kenyan business, and it removes an entire daily reconciliation task.
-
eTIMS, if you are VAT-registered in Kenya
Not optional in practice. Set it up before go-live rather than after, because retrofitting fiscal references onto invoices already issued is unpleasant.
-
Storage archiving, when you have documents worth keeping twice
Event-driven, so once it is on it looks after itself. Useful mostly as insurance and as a way of getting your own files somewhere you control.
-
Everything else, only when someone asks for it by name
Integrations added speculatively are configuration nobody maintains. If no member of staff has asked for the Airtable connection, connecting it creates an unowned data flow.
Our take
Decode every logo into one of the four kinds before you value it, and interrogate only the transactional ones properly — those are the only integrations where failure costs money instead of information. Connect one notification channel immediately, because it is cheap and it changes behaviour. Then leave the logo wall alone until somebody asks for a tile by name.
See what each tile actually does
Notification channels, record pushes, event-driven document archiving, a single signed inbound door, and real two-way clients where money moves — each one described by direction, trigger and whose credentials, rather than by a logo.
See plans & pricingFrequently asked questions
What kinds of integration are there?
Four that behave differently: notifications pushed out to a chat or messaging channel; records pushed out to a CRM or database; documents archived out to your own storage as they are created; and genuine two-way transactional clients where something irreversible happens, such as a payment or an invoice transmission. Plus one inbound door — an authenticated, optionally signed webhook. Only the transactional kind is worth interrogating in detail, because it is the only one where failure costs money rather than information.
Do the integrations sync automatically?
Document archiving to your storage is event-driven and fires as documents are created. Record and calendar syncs — Salesforce, Notion, Airtable, Mailchimp, Google and Outlook calendars — run when someone presses "sync now", which dispatches a queued job. There is no nightly automatic sync wired up, so if you were planning on a continuously current CRM, know that it is a button.
Whose credentials do the integrations use?
It depends on the connector. Google, Microsoft, Dropbox and Salesforce connect through OAuth against a platform app, so there is nothing to paste. Everything involving money or compliance is bring-your-own: your own Daraja credentials for M-Pesa, your own Paystack keys, your own eTIMS credentials. For payments that distinction is the whole risk question — funds move through your own shortcode and we are never in the settlement path.
Can data be pulled in from other systems on a schedule?
No. Inbound is push-only, through a single authenticated webhook that can carry an event name to trigger a workflow. There is no bank statement feed, no marketplace order poller and no scheduled pull from any external business system. If your plan depends on something being fetched hourly, that has to be built by whoever owns the other end pushing to the inbound door.
Which integration should we set up first?
One notification channel, wherever your team already discusses work. Twenty minutes of setup and it is the integration that actually changes behaviour, because approvals and stock alerts start appearing in a place people already look. Then M-Pesa if you collect through it, since auto-matching a C2B payment that quotes an invoice number removes a daily reconciliation task, and eTIMS if you are VAT-registered in Kenya.
Why does single sign-on need a password login first?
Because the callback rejects an unlinked account by design. A user signs in with their password once and links their Google or Microsoft account, after which they can sign in with it. Without that step, anyone able to create an account with a matching email address at the identity provider could walk into your organisation. One extra step at onboarding, and the right trade.
