Testing & Deployment

9 min

Prepare Your Service

What You Need

Item	Purpose
Key cabinet API documentation	Define inventory, user, permission and custody operations
Non-production cabinet environment	Test without affecting production users or keys
Cabinet API credentials	Let your service access the cabinet with the required permissions
Seven HTTPS endpoints	Receive the proposed KMI operations from Sine
KMI API key	Authenticate Sine requests to your service; use a separate key per customer integration
Customer externalId	Select the correct cabinet configuration for each request
Test key groups and keys	Exercise inventory sync, access and returns
Synthetic visitor data	Exercise lifecycle operations without real personal data
Sine test site	Configure and test the integration when generic KMI is available

Store real credentials in a secret manager or another approved secret store. Use synthetic values in fixtures, and do not include API keys, visitor PINs or unredacted personal data in shared logs.

Proposed Sine Configuration

Once generic KMI is available, a Sine administrator would configure the following:

Setting	Proposed value
Verify endpoint	HTTPS URL of your Verify operation
Resources endpoint	HTTPS URL of your Resources operation
Keys endpoint	HTTPS URL of your Keys operation
Provision endpoint	HTTPS URL of your Provision operation
Activate endpoint	HTTPS URL of your Activate operation
Check-return endpoint	HTTPS URL of your Check-return operation
Deprovision endpoint	HTTPS URL of your Deprovision operation
KMI API key	Customer-specific secret your service uses to authenticate Sine
External ID	Customer or cabinet configuration identifier understood by your service
Key groups	Groups returned by your Resources endpoint
Dynamic asset type	Sine's destination for the synchronised key options

For example, the URLs could be paths under https://integration.example.com/kmi/, but each address would be configured separately. The exact Sine configuration controls, private connectivity options and availability have not yet been defined.

Your service, not Sine, stores and uses the cabinet API credentials. Protect the endpoint URLs and API key according to your organisation's security requirements.

Test Your Endpoints

Authentication and Validation

For every operation:

Send a valid POST request with the configured KMI API key and a JSON body.

Confirm that missing or invalid API keys are rejected.

Confirm that invalid JSON, missing required fields and unsupported field types are rejected.

Fuzz field types, lengths and encodings, and confirm malformed input fails safely.

Send a valid customer key with another customer's externalId and confirm your service returns 403 without accessing that cabinet.

Confirm that responses and logs do not expose secrets, visitor PINs or unnecessary personal data.

The Implementation Guide contains proposed request and response examples. The configured API key is sent as the Authorization header value in this proposal.

Operation Contract Tests

Operation	Cases to cover	Proposed successful result
Verify	Valid configuration, invalid credentials, unavailable cabinet	200, SUCCESS
Resources	Available groups, no groups, failed lookup	200, top-level keyGroups
Keys	Selected groups, overlapping groups, multiple cabinet pages, genuinely empty inventory, failed or incomplete retrieval	200, SUCCESS and complete data array
Provision	Valid visit, missing contact, invalid key, duplicate request, uncertain creation	201, PROVISIONED and non-empty user ID and password
Activate	Correct user and keys, missing user, permission failure, repeated request	200, ACTIVATED
Check-return	All returned, outstanding keys, empty request array, missing or ambiguous custody data	200, SUCCESS and top-level unreturnedKeyIds
Deprovision	Existing access, empty key array, already-removed access, cabinet failure, repeated request	200, DEPROVISIONED

Check exact field names and types, not only the HTTP status. For failures, return a non-success status and a safe error response. Do not return an empty successful inventory or custody result when your service could not determine the real state.

Inventory Safety Tests

Return keys from each selected group and confirm IDs remain strings, including leading zeroes.

Return one key in multiple groups and confirm your service returns it only once.

Make the cabinet API return multiple pages and confirm your service includes all of them.

Fail a later page and confirm your service returns an error, not a partial success.

Return a genuinely empty inventory and confirm the receiving environment treats it as an empty snapshot.

Test key IDs at and beyond the site's expected identifier-length limit, including any stable ID mapping your service uses.

The proposed Sine behaviour reconciles the successful snapshot and can remove keys that are absent from it. Test this only with dedicated non-production data.

Test the Visitor Lifecycle

When the generic framework is available, run end-to-end tests using a Sine test site, a test cabinet and synthetic visitor details.

Scenario	Proposed behaviour to verify
Key groups are selected	Sine calls Keys and exposes the returned keys as form options
Visitor selects no keys	Provision is not requested
Visitor supplies neither email nor mobile	Provision is not requested
Visitor supplies mobile but no email	Provision can be requested; no credential email is sent
Pass awaits approval	Provision prepares the user; Activate waits for acceptance
Pass is accepted or checked in	Activate is called and credential email is attempted when an email address is available
Provisioned pass is rejected	Deprovision is requested without waiting for the sign-out grace period
Provision fails	A handled cabinet failure is recorded and does not by itself reject check-in
Activation or email fails	A completed check-in is not rolled back
Check-out reports outstanding keys	A reminder may be sent if the visitor has an email address
Check-out reports no outstanding keys	No reminder is expected; delayed deprovision is still scheduled
A return check fails or keys remain outstanding	Deprovision is still attempted after the proposed grace period

The proposed grace delay is 15 minutes, based on the existing key-cabinet lifecycle. Actual task execution can occur later. Confirm this timing and the other lifecycle assumptions when the external framework is finalised.

Check both the Sine activity and cabinet state. A completed check-in is not proof that the cabinet user was provisioned, activated or sent credentials.

Failure and Recovery Tests

Simulate cabinet authentication failures, permission errors, timeouts and unavailable services.

Simulate a timeout after a cabinet user was created. Reconcile the outcome before retrying Provision.

Confirm that the stored externalId/visitId to keyUserId mapping supports later operations, which do not include visitId.

Repeat Activate and Deprovision and verify that they are safe to repeat.

Return ambiguous custody data and confirm it is not presented as a confirmed physical return.

Verify that the site has a process for recovering keys that remain outstanding after cabinet access ends.

Confirm that support staff can identify the customer, operation, visit and failure using redacted diagnostics.

The generic framework's timeout, retry and delivery guarantees are not yet defined. Do not assume exactly-once delivery or automatic retries.