Sandbox testing checklist
Use synthetic data and your institution's sandbox credential. Keep the request references and acceptance counts so your Teria administrator can help confirm the processing results.
| Scenario | Expected result |
|---|---|
| Valid credential used for connection verification | 200, with the authorised Customer Account, canonical institution and sandbox environment. Direct institutions receive null organisation and connection metadata. |
| One valid standalone outcome | 202, one accepted event, then a processed outcome in integration status. |
| Same outcome sent again | 202 with a duplicate count; no additional attempt. |
| Several distinct outcomes in one batch | Accepted counts match the events submitted. |
| Same ID twice within one batch | 400; correct the duplicate entry before retrying. |
| Existing V3 event ID with changed content | 409; original observation remains immutable. |
| Optional legacy scope assertion does not match the credential | 403; no events accepted. |
| Credential from another environment | Authentication rejected by the API deployment. |
| Direct institution with no organisation or connection fields | Uses the same V3 payload and receives normal acceptance. |
Caller supplies account_id or institution_id in the batch |
400; account and originating institution are derived from the credential. |
| Unknown destination or switch ID | 400 with field-level detail; obtain the enabled ID from Teria. |
| Timeout followed by later success | Two immutable observations with different event IDs and the same attempt ID. |
| Success followed by reversal | A new reversal observation under the same attempt. |
| Out-of-order and delayed delivery | Original occurrence times retained; historical outcomes reconstructed. |
| Network outage or lost response | Buffer preserved; retry unchanged events after recovery; duplicates handled safely. |
| Optional start and transaction-received observations | Accepted alongside outcomes without being required for outcomes-only reporting. |
| Paused telemetry access | New submissions blocked; resume using the same credential after access is restored. |
| Credential rotation | Replacement works; old credential stops working after confirmed cutover or the 24-hour overlap. |
| Revoked credential | New requests rejected; new credential needed to restore access. |
When testing scope or access failures, coordinate the institution changes with your Teria administrator. Do not revoke a credential that another integration is still using. Use a new event ID only for a new observation, not to force a retry past a content conflict.
The Postman examples preserve generated IDs and timestamps after the first Send. Clear the relevant collection payload variable to start a new deliberate test, and keep repeated Send calls unchanged when testing deduplication. Do not rerun stored examples after the seven-day event-age window.
Complete onboarding
Ask your Teria administrator to confirm the first batch was accepted and the first outcome was processed. Record the current integration status and last activity. Credential issuance or a successful connection check alone does not establish a working end-to-end integration.
Production onboarding uses a separate environment and fresh credentials. Sandbox tests do not submit live payments or promote sandbox data into production.