Signing flow

Not implemented yet. There is currently no signing flow a relying party can integrate against. This page records the status and the intended shape so you can plan; it is not an integration guide.

Current status

Signing is selected with signature_type=SIGNING when a session is created. That value is accepted by validation and then rejected:

curl -X POST https://<backend-host>/relying-party/v1/session \
  -u "$COMPLYONCE_CLIENT_ID:$COMPLYONCE_CLIENT_SECRET" \
  -H 'Content-Type: application/json' \
  -d '{
    "redirect_uri": "https://portal.example.com/auth/callback",
    "state": "xr7Kp2mQ9vB4nL1s",
    "signature_type": "SIGNING",
    "code_challenge": "E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM",
    "code_challenge_method": "S256"
  }'

{
  "errorCode": "not_implemented",
  "defaultTranslation": "SIGNING is not supported yet",
  "resultMessageLangCode": "en",
  "payload": null
}

The response status is 501. Nothing further in the flow is reachable, so there is no callback to prepare for and no signed result to handle.

When it lands, signing is expected to reuse the authentication flow rather than introduce a separate one — the same QR page, the same pairing-code confirmation, the same authorization code redeemed on the back channel. The differences would be that you supply what is to be signed when the session is created, the phone shows the document details instead of a bare login prompt, and the token response returns a signature and a signed container instead of just a subjectId.

This is a design intention, not a contract. Field names, the container format, and how the document is transferred are all unsettled. Do not build against it.

If you need signing now

Talk to ComplyOnce before making commitments to your own users. There is an older, push-notification-based signing endpoint (POST /relying-party/v1/create-signing-request) that predates this flow: it requires a vaultId for the user — which the login flow no longer returns, now that logins hand back a per-relying-party subjectId instead — involves no QR code, and delivers the result by calling back to a URL you provide. It now authenticates with client_id / client_secret like the rest of the API — the legacy relying_party.token it used to take has been removed, and the name shown on the user's phone comes from your registered name instead. It is still deliberately not documented here as an integration path, because it is not the direction this API is going and integrating against it now means migrating later.

Signing flow

Current status

Intended shape

If you need signing now