Generate missing onboarding keys

POST 
/v1/onboarding-cases/:case_id/key-generation-jobs

Asks the platform to create the requested keys in the AWS KMS account configured for your deployment, then register and verify each one on the case, so you do not have to register signing and encryption targets yourself. Signing keys are created as Ed25519 keys (ED25519_PH_SHA_512); the key-encryption key as a symmetric encrypt/decrypt key. The work runs in the background: the call returns 202 with the job, and you poll GET .../key-generation-jobs/{job_id}.

Required scope: connector:onboarding:artifacts:write.

Allowed states: AWAITING_BANK_ADMIN, BANK_CONFIGURING, NEEDS_CHANGES (otherwise 409).

Fields (all in data.attributes):

• idempotency_key (required, UUID): identifies this request. Resending the same key with the same body returns the existing job instead of creating a new one; the same key with a different body returns 409. There is no Idempotency-Key header on this operation.
• requirements_version (required): the version from GET .../key-requirements. If the catalogue has changed, the job is rejected with 422 (Key requirements changed. Refresh the page.).
• purposes (required, 1 to 4 unique values): the key purposes to generate, from BANK_ADMIN, CREATE_INTERBANK_TRANSFER_MAKER, APPROVE_INTERBANK_TRANSFER_CHECKER, ENCRYPT_TRANSFER_SOURCE_MESSAGE.

Existing keys are preserved. A purpose that already has a target you registered yourself is skipped and does not appear in the job's items. The job never rotates or replaces a key.

Allocation lifecycle. Each requested purpose gets an allocation (one entry in items) whose status moves through PENDING, CREATING (key created at the provider), CONFIGURING (key prepared and its public material read), REGISTERING (target registered on the case; target_id is set), VERIFYING (target verified) and READY. A failed step is retried automatically with increasing delays; after repeated failures the allocation becomes FAILED with retryable: true and a reason in error. To retry, create a new job (new idempotency_key) for that purpose: the existing allocation resumes where it stopped, and a second key is never created. CONFLICT means a different key was registered for the purpose while the job ran; that key is kept.

Limits: at most 30 new jobs per bank per hour (429 beyond that). If the platform key service is unavailable the call returns 503.

Request

Responses

202

Job accepted. Poll GET .../key-generation-jobs/{job_id} until every item is READY, FAILED or CONFLICT.

400

The request is malformed: invalid JSON syntax, an invalid path or query parameter, a missing required header such as Idempotency-Key, or a single field that fails its own format rule. Fix the request before retrying; retrying it unchanged fails again.

401

The bearer token is missing, malformed, expired, signed by an unknown key, or was not issued by the platform IAM for the Lyriq Connector. Obtain a new token and retry. See the Authentication section.

403

The token is valid but may not perform this request: it lacks the required scope, has no bank membership, needs an x-dan-bank-id header to choose between several memberships, names a bank in x-dan-bank-id it has no membership for, or the caller's bank is suspended or terminated. A new token with the same configuration fails the same way. See the Authentication section.

404

The resource does not exist, or it belongs to another bank. The Lyriq Connector does not distinguish the two cases, so resources of other banks are never disclosed.

409

The case is not editable, or idempotency_key was already used with a different body.

422

The request is invalid, for example requirements_version is out of date.

429

The request was refused because a rate limit was reached (code RATE_LIMITED). No Retry-After header is sent; retry with exponential backoff.

503

The request could not be served right now. Either the network is not fully operational (OUTBOUND_HALTED or READ_ONLY: mutations are refused while read endpoints keep working; OPERATIONAL_STATE_UNKNOWN: the state could not be determined), or a platform dependency is temporarily unavailable. No Retry-After header is sent; retry later with backoff. When retrying a mutation, reuse the same Idempotency-Key and body.