ScotiaConnect integrations are predominantly file-based. sFTP exchange of payment-origination files and reporting deliveries covers the majority of commercial use cases, because it matches the reconciliation and audit disciplines already in place at most treasury teams. REST endpoints exist for selected balance and transaction lookup scenarios under partner agreements. This reference covers the endpoint families, the authentication model, the rate limits and the typical onboarding timeline for each path.
The reason sFTP dominates ScotiaConnect integration work is audit alignment. A file that arrives in a landing directory with a deterministic name, a known checksum and an ack response reproduces cleanly for audit review. A REST call that returns a balance and then expires from a cache does not, unless the consuming system explicitly persists both request and response. Commercial clients with long-standing reconciliation practices tend to prefer the file model, even when a REST option is available.
REST is introduced where the latency or scale of file exchange does not fit the workflow. Intraday balance lookup on an active cash-positioning desk, transaction-detail retrieval in a treasury-workstation drill-down, and certain payment-status checks are all natural fits. Canadian payment-system expectations managed through the Bank of Canada Lynx calendar also shape which lookup patterns make sense as REST versus file exchange.
ScotiaConnect REST endpoints use OAuth 2.0 client credentials for service-to-service authentication, with mutual TLS on partner endpoints. sFTP integrations use client-owned SSH keys rotated on a schedule set by the client. Credential hygiene is a client responsibility under the partner agreement.
OAuth client credentials cover the service-to-service REST pattern. A client application exchanges a client identifier and a client secret for a short-lived access token, and every subsequent request carries the token in the Authorization header. Token lifetimes are short enough that a leaked token has a bounded blast radius, long enough that token refresh is not the dominant cost in a high-throughput integration. Mutual TLS is layered on top for partner endpoints where the additional transport-layer identity proof is valued.
sFTP uses public-key authentication with client-owned SSH keys. The client generates the key pair, shares the public half with the service desk during onboarding and rotates the key pair on the cadence chosen by their security team. Quarterly and annual rotations are the most common choices among commercial clients; regulated-industry segments tend to rotate more frequently.
Rate limits are documented in the partner onboarding package and are enforced server-side. A client that exceeds the steady-state limit receives standard throttling responses; a client that exceeds the burst allowance briefly receives the same responses for the duration of the burst. Clients integrating high-throughput treasury-workstation lookups should size their scheduling so that steady-state remains below the published limit, using the burst allowance only for genuine peaks rather than as an expected operating point.
Onboarding runs faster for sFTP than for REST. A standard sFTP path covers landing-directory provisioning, SSH key exchange, one or more test-file round-trips, an ack-file validation step, and production cut-over with parallel running. REST adds partner-agreement review, scoped-credential provisioning, staging-environment certification of each endpoint the partner plans to use, and production cut-over with monitored volume ramp. See data exports for the reporting side of the same integration path.
| Endpoint family | Auth model | Rate limit | Typical onboarding |
|---|---|---|---|
| sFTP payment origination | SSH public key | File-volume based | 2-3 weeks |
| sFTP reporting delivery | SSH public key | File-volume based | 2-3 weeks |
| REST balance lookup | OAuth 2.0 client credentials + mTLS | Tens of req/sec per partner | 4-6 weeks |
| REST transaction lookup | OAuth 2.0 client credentials + mTLS | Tens of req/sec per partner | 4-6 weeks |
| REST payment status | OAuth 2.0 client credentials + mTLS | Tens of req/sec per partner | 4-6 weeks |
Yes, for specific partners and specific endpoints. REST endpoints exist for balance and transaction lookup under partner agreements. File-based sFTP remains the majority use case for commercial clients, because it aligns with existing reconciliation and audit practice.
REST is introduced where the latency or scale of file exchange does not fit the workflow, typically in active cash-positioning desks and treasury-workstation drill-down scenarios.
ScotiaConnect REST endpoints use OAuth 2.0 client credentials for service-to-service authentication, with mutual TLS layered on top for partner endpoints. sFTP integrations use client-owned SSH keys rotated on a schedule set by the client.
Credential hygiene is a client responsibility under the partner agreement, with rotation cadence and storage practices documented on the client side.
Rate limits on ScotiaConnect REST endpoints are set per partner agreement. Typical commercial partners run at tens of requests per second with a short burst allowance above the steady-state limit. Limits are documented in the partner onboarding package.
Steady-state sizing should stay below the published limit, with the burst allowance reserved for genuine peaks rather than used as an expected operating point.
sFTP onboarding typically runs two to three weeks, covering directory provisioning, key exchange, test-file validation and production cut-over. REST onboarding runs four to six weeks because of partner-agreement review, scoped-credential provisioning and end-to-end certification.
The biggest onboarding lever on the client side is readiness: finalized credentials, finalized endpoint list and a staged test environment will shorten the timeline more than any single change on the bank side.