Work connections
Your organisation's identity provider and document store, surfaced as two vendor-neutral connections. Read live, never synced, and never mirrored.
Two things about your organisation can be connected to Keepable: the work directory (your identity provider) and the work storage (your document store). The provider is named when you connect and nowhere else, which is why everything below is vendor-neutral.
GET /connectionsConnecting is not in this API. It is an interactive admin-consent redirect to the provider, so it cannot be a headless call; your administrator does it once in the portal. This API reads and uses what is already connected.
What connecting changes for sign-in
Your identity provider is already connected to Keepable, for login. The work directory is not a second relationship with it; it is permission to read the one that is already there. Building it separately would mean connecting the same provider twice, under two consents, with two token stores and two things to revoke, and two ways for them to drift apart.
So one admin consent lights up both legs, and the sign-in page can then tell your people apart from everybody else's:
Before you connect, your team signs in with a passkey or a one-time email link. Someone who chooses the work-account path is told, by name, that their domain is not set up for it yet.
After you connect, anyone at your email domain who chooses that path is routed to your provider. The check is on the DOMAIN, so it is the same answer for everybody in your organisation and it reveals nothing about who has an account.
They become a member the first time they sign in, not when you connect and not when somebody finds them in a search.
Disconnecting stops sign-in and search at once. Members who already materialised stay, because they are Keepable rows by then rather than directory entries.
Nothing is ever synced
There is no roster import, no drive mirror, and no SCIM. That is the design, not a missing feature.
- Sign-in creates membership just in time. Somebody who signs in through SSO becomes a member at that moment.
- Directory search is proxied live and stores nothing.
- A searched person becomes a member on first sign-in, not when you find them.
- Storage is browsed live, and bytes enter Keepable exactly once, when you attach a file.
The payoff is that offboarding scales with the members who actually use Keepable, not with the size of your directory. There is no mirror to drift, and no stale copy of your staff list to answer for.
Searching the directory
GET https://api.keepable.co/sender/v2/directory/search?q=adeyemi
Authorization: Bearer {{KEEPABLE_TOKEN}}Needs directory.read, which is deliberately not members.read: members are
people already in Keepable, and this reaches live into a system Keepable does
not own.
Use it to address a route step at somebody who has not signed in yet. They become a real member the first time they do.
Browsing storage
GET /storage/items?q=facility
POST /storage/readNeeds storage.read, again separate from documents.read for the same reason:
those are the documents already in Keepable, this is your own drive.
POST /storage/read returns a file's decoded content without sealing it,
for when you need to look before you attach. To bring it in, use
POST /documents/from-storage.
Both scopes reach outside Keepable into systems you own. A key holding them is a path into your directory and your drive, so grant them only to integrations that genuinely route or attach, and rotate promptly if one is exposed.