Before trusting an Enhance integration with customers, verify five things: that you can tell one customer organisation from another by more than a name, that subscription state is read rather than assumed, that single sign-on is issued for exactly one identified member, that deleted subscriptions are excluded everywhere, and that a lost outcome stops rather than retries.
Enhance models a cluster as organisations with subscriptions and members, and its API is documented publicly at apidocs.enhance.com. The integration work is not in calling the endpoints — it is in deciding what each answer entitles you to conclude. These are the checks worth doing before a real customer depends on it.
The customers listing takes a search term, and search is a filter: it narrows a page, it does not identify a row. If your integration takes the first result, it will eventually take the wrong organisation — a partial match, an archived duplicate, a name that is a prefix of another. Require an exact match, and if two organisations match exactly, refuse and ask a person. Two exact matches is a question, not a tie to break with a sort order.
Clusters keep deleted subscriptions in listings. An integration that counts rows to decide whether a customer has hosting will find two where there is one. Read the status on every path — listing, lookup, single sign-on — and exclude deleted everywhere, not just in the place you first noticed the problem.
This is a good example of a bug that only appears in production, because a fresh test cluster has no deleted subscriptions on it. Create one deliberately and leave it there.
A one-time sign-in link is issued for a specific member of a customer organisation. That means your integration has to decide whose session this is, and it must not guess. Ask for the owner role, count the active ones, and:
And count across the whole listing. A members listing is paginated, and "exactly one active owner" is a claim about the whole set. If the count and the rows disagree, or a page comes back empty while more are owed, refuse: you have not established the answer, and "could not establish" is not "there is one".
A one-time sign-in URL is a bearer credential. It should not be logged, not written to a durable queue, not put in a Location header, and not stored. Return it in a response body with Cache-Control: no-store and Referrer-Policy: no-referrer, and prefer opening it from a click handler rather than rendering it as a link — an href puts it in the DOM, in devtools, in "copy link address" and on the status bar.
Record that somebody asked, for which account, and whether it succeeded. Never record what they were given.
If you write your own reference into a subscription's friendly name so you can recognise your own creations later — a reasonable technique — remember that everybody else on a shared cluster writes whatever they like in the same field. A name that happens to look like your identifier is a candidate, not a proof. Check it against your own records of what you created, and where you cannot, treat the account as one you cannot vouch for.
| Situation | Why a retry is wrong |
|---|---|
| Timeout after a create was sent | The subscription may exist; a retry makes a second |
| Two exact customer matches | Choosing one binds a service to possibly the wrong organisation |
| Two active owners | The link would open a panel as an unintended person |
| Members listing incomplete | You cannot claim "one owner" from a partial count |
| HTTP 429 after an effecting call | The call may have been accepted before the limit applied |
GENV has an Enhance adapter implementing account creation, inspection, suspension, reinstatement, listing and single sign-on, written against the published specification and exercised against a deterministic stand-in. Its reads are verified live against a real Enhance installation, read-only — the connection check and the plan, customer and website listings, with GET requests only — and an operator can switch those reads on. Nothing that changes an account has been certified, and effecting actions remain unrouted in the shipped build, so nothing in GENV can currently change a real Enhance cluster. The checklist above is what we would work through on the day that changes.
We are not aware of a public sandbox cluster. In its absence, build against a deterministic stand-in that answers the documented shapes, and keep a real installation for controlled certification.
For reads, retry. For anything that changes state, a rate-limit response after the request was sent is an unknown outcome, not a retryable one — the call may have been accepted.
It should not. One service is one account; if a customer has two, they are two services. Anything else makes billing and suspension ambiguous.
Official documentation, each requested on 21 September 2026. Provider behaviour changes; check the source before relying on a detail.