Integration
Diagnostics
This call goes out from the CRM server with the organisation’s M2M token. There is no employee session involved: clear the cookies and it answers the same.
How this console talks to TripleEnable
- Who calls
- The server of this CRM, never the agent’s browser. Neither the M2M token nor the secret that requests it reach the workstation: it is checked by opening the network tab.
- Issuing
- POST /v1/b2b/credentials. The claims are composed by this server reading the roster record; only the customer identifier comes from the browser.
- Verifying
- POST /v1/b2b/presentations opens the session in TripleEnable’s verifier and returns the OID4VP link. This organisation has no verifier and no verification key.
- Alerting the mobile
- POST /v1/b2b/wakeups. The response is the same whether the holder has a wallet or not — deliberately: if it distinguished, it could be used to find out who has the app by trying identifiers — so it does not confirm that anything rang.
- Following a verification
- This server does not ask te-api whether a verification has finished. The outcome arrives on its own, over a signed webhook to POST /api/webhooks/te-api, and is written to this organisation’s journal. The ceremony screen reads that journal every 3 s, without leaving here.
- The customer roster
- It does not leave here. It lives in this CRM’s own database and neither te-api nor Logto ever read it; the only thing that travels about a customer is what is signed inside their credential.
Local configuration
- Organisation
- ww51qgtvpc9h
- Name
- Banco Demo, S.A.
- Domain
- bank.demo-te.com
- did:web published
- did:web:bank.demo-te.com
- Official numbers
- +34 918 40 22 47 · +34 900 30 11 22
- Brand
- the default palette · set it in Settings
- te-api (issuing)
- https://te-api.idp.tripleenable.com
- te-api (verification)
- https://te-api.idp.tripleenable.com
One installation, one organisation
- Where it comes from
- From this installation’s own settings row, written on the Settings screen. The request cannot change it: the Host header decides nothing here, which is what makes the answer to “whose screen is this?” the same on every request.
- To serve a second company
- Publish the application a second time with a different configuration. It is the same image: what changes is the environment, its domain and its database. Nothing is shared, so nothing one company does can reach the other.
- The DID document
- /.well-known/did.json is always composed with the declared domain, so its id is the same DID whatever the request says. It answers 404 while te-api holds no key: an organisation that has not switched on issuing has no issuer identity to publish.
Events pushed to this CRM
- Webhook URL
- https://bank.demo-te.com/api/webhooks/te-apiRegister it in the console, under Credentials → Webhook.
- Signing secret
- declared · every delivery is checked against it
- Received
- 81 in total, 0 refusedlast one 16 Oct, 01:07
Interface language
- Who chooses
- Whoever is looking at the screen, from the sidebar. It is stored in the crm_locale cookie and applies to this browser only: it is not an environment variable, so changing it needs neither a rebuild nor a redeploy.
- Active language
- en · English
- Fallback
- English. A key with no translation is shown in English; the key name is never painted on screen.
The CRM database
- Connection
- It answers.
- Customers of this organisation
- 3
What te-api says
- organizationId
- ww51qgtvpc9h
- legalName
- Banco Demo, S.A.
- did
- did:web:bank.demo-te.com
- token scopes
- credentials:issue verifications:request webhooks:manage
- types it can issue
- cliente (max. 365 d), kyc (max. 365 d)