Publish the details your signup actually requires, and the person's own AI assembles them against your list. They approve once on their phone; you receive those fields with a receipt and a grant they can revoke. Scope only ever shrinks from what was proposed, and the key names you prohibit are refused before anything leaves, though your installer should still ignore anything outside your manifest. There is no public self-serve B2B endpoint today; a design partner would test one bounded workflow alongside its existing verification, retention, and compliance controls.
Instead of a form, your onboarding or setup agent declares what it needs as a manifest. The user's own AI proposes the specifics, ShareLess shows the user an approval on their phone, and you receive only the approved fields with a receipt. It is a prototype, not a generally available integration.
The exact fields and config your setup needs, each with a purpose. You also name the fields it must never receive, and ShareLess refuses them at any depth in the object: once when the user's AI proposes an item, and again on the assembled release.
Any AI the user connects works out what fits and proposes the specifics. Matching is by field name, never by inspecting values: a name you banned is refused at any depth, and only the config fields you declared cross, at the values you allowed. The shape of each proposed item is matched by your own installer, not by us.
One phone approval with per-item and content controls. You receive the approved scope with a receipt and a grant the user can revoke. ShareLess does not prove identity; it proves what was approved.
When the user approves, ShareLess assembles a release and makes it available to your key. These are the fields it actually carries.
sessionId, businessId, manifestId identify the request you opened.receiptId is the id of this release. It is what you quote in your own records.items are the entries the user left switched on. Content classes stay switched off unless the user turns them on for that item, so an item arrives listing only the classes they allowed.config holds the settings you declared, limited to the scalars and options your manifest allowed.grantId is the grant the user can revoke. Store it; it is how you recognise a revocation later.There is no retention field in a release. If your manifest declares a retention setting, it travels in config as the option the user picked from the list you supplied.
A user can revoke a grant at any time. When they do, ShareLess records it and reports it the next time you pull the session, as a revoked flag and the moment it happened. ShareLess does not call you, and it does not sit between you and the data you were given: it cannot claw back the copy you already hold. Revocation is a signal you are expected to honour, not a switch that turns your own systems off.
Be clear with your own reviewers about this one. A Connect release is stored on ShareLess servers so that your key can pull it, and the items in it passed through whichever AI the user chose to run the discovery. This is not the on-device story that applies to the ShareLess vault, and we do not describe it that way. If a field is too sensitive for that path, do not put it in your manifest.
Most intake forms collect a superset because nobody knew which subset would be needed. A manifest forces that decision up front, and the release gives you a reason to point at when you decline to keep the rest.
A full bank statement to get a routing and account number. A passport scan to check one date. A credential pasted into a setup screen because there was no other way to point at an account. Each one becomes a row you now have to secure, audit, and delete.
You declare the fields, the user approves them, and you receive those fields with a receipt id and a grant id. What you never asked for never arrives, so it is not yours to protect.
We are not going to pretend this is a package install. There is no published SDK, no hosted script, and no signup form. Here is literally what it takes.
Connect authenticates a business by matching a bearer key against an allowlist held in the deployment environment. An operator edits it and redeploys. There is no route that mints a key and no form that requests one, so the only way in is to talk to us. Your API key stays on your server: the browser never sees it.
One authenticated POST, carrying your manifest inline and an optional callback URL. ShareLess stores that manifest copy on the session and works from it. There is no manifest registry, no version history, and no manifest URL anyone can fetch.
POST https://app.shareless.ai/api/connect/sessions
You get back a session id, a single-use code, the link to hand your user, and an expiry. The request stops working 24 hours after you create it, at any stage before release. Once the user approves, the released payload stays pullable with your key, and the grant it creates has no expiry of its own.
You render the button. We do not ship one you can install: the packages in our repository are unpublished and unversioned, so what a design partner gets is a reference file to copy, hosted on their own origin. The user opens the link, signs in, and their AI takes it from there.
Pull the session with your key when you are ready. Until the user approves, it answers 404 with a not_released status. If you registered a callback, approval also fires a single best-effort POST to it: https only, an eight second timeout, and no retries. Treat the callback as a nudge and the pull as the truth.
GET https://app.shareless.ai/api/connect/sessions/<sessionId>
A callback is not authentication on its own. ShareLess can sign it with a shared secret we set up with you; without that, confirm every callback by pulling the release before you act on it.
One endpoint is public and unauthenticated, so your own page can poll it while the user works. It takes the session id and returns a single word: opened, claimed, proposed, released, declined, or expired. No manifest, no proposals, no user data.
GET https://app.shareless.ai/api/connect/public/<sessionId>
The concept records the requester, user decision, requested fields, and permitted action. That record can support an operator review; it does not prove identity or satisfy a regulatory requirement by itself.
We are not offering a self-serve API or licensing program today. We want to test a bounded workflow with a team that can define the requested fields, current retention, existing verification, and a measurable success criterion.
The receiving business chooses what it retains and remains responsible for verification, security, and compliance. This prototype facilitates a user-reviewed transfer; it does not attest identity or eliminate those obligations. Where your manifest offers the user a retention choice, the window is your promise to them, and ShareLess relays it rather than enforcing it: nothing in ShareLess deletes your copy when that window lapses.
Include the step, fields requested, current retention, and the outcome you would measure.