If your platform creates Legal Entities for its own customers, a scheme that getpeppr cannot verify automatically no longer looks as though it is still being processed.
What was misleading
The gateway already knew the internal answer: unsupported_scheme. No registry
had rejected the customer, but no automatic validator was active either. The
public API flattened that answer to pending.
That left an integrator with the wrong instruction: wait. Polling could continue indefinitely because there was no active job to finish and no terminal status to handle.
What changes
GET /v1/legal-entities and GET /v1/legal-entities/:id now return:
{
"status": "unsupported_scheme"
}
SDK 4.7.0 adds that value to LegalEntityStatus and adds the matching
legal_entity.unsupported_scheme webhook event. Its payload carries the same
status and no failure reason, because no registry made a decision.
if (event.type === "legal_entity.unsupported_scheme") {
showManualReviewPath(event.data.legalEntityId);
}
Endpoints subscribed to * receive the event automatically. If your webhook
endpoint explicitly selected the previous four legal_entity.* names, add
legal_entity.unsupported_scheme to that list.
What does not change
This status is not sendable and does not bypass the Trust Layer. Contact support before sending under that identifier scheme.
Internally, the row remains resumable. If getpeppr adds an automatic validator
for the scheme later, verification can start without recreating the Legal
Entity. That future retry does not make today's public answer pending: today,
no work is active.