About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not lab validation. Check the stated versions and your own requirements before making changes.
Choose an integration method that the customer's system can support, then define the tenant identity, permitted operations, data boundary and failure behaviour. A private tunnel, signed token or separate folder does not by itself prove that the integration can access only the correct customer's information.
Use APIs for appropriate interactive exchanges, controlled file transfers for batches and private connectivity where the application's requirements justify it. Do not turn the choice into a universal rule: compatibility, support ownership and the actual security controls decide what is suitable.
Start with the business transaction
Record what is sent, which system is authoritative, how quickly it must arrive and what should happen when delivery fails. Name the customer and ISV owners for both the business outcome and the technical integration.
For an illustrative order import, a transport success might mean only that a file reached the upload service. It does not prove that every order was accepted, that duplicates were handled correctly or that downstream processing completed. Define separate states and the evidence needed to reconcile them.
Our recommended integration record includes the tenant identifier, endpoint, credential owner, allowed operations, data format, expected volume, timeout/retry policy and reconciliation method. Use synthetic data for the initial tests.
API identity is not the same as tenant permission
OWASP's REST Security Cheat Sheet discusses transport protection, access control, API keys and JWT validation. Distinguish the credential format from the permission decision. An opaque API key and a JWT are not interchangeable mechanisms.
For a JWT-based design, use the relevant supported library and protocol guidance to validate the signature and expected claims, including issuer, audience and validity times. A valid token still needs an application decision about which tenant, objects and operations it authorises. Do not trust a caller-supplied tenant identifier without that binding.
OWASP's 2023 API risks distinguish object-level authorisation, property-level authorisation and unrestricted resource consumption. Include controlled negative tests for cross-tenant object access and fields the integration should not read or change. Keep rate and resource limits active in production.
Define reliable webhook handling
A webhook receiver needs to verify the sender using that provider's documented scheme and handle legitimate retries without duplicating a business operation. A signature check alone does not define replay protection or processing idempotency.
Stripe's webhook documentation provides a specific example: its signature verification uses the raw request body; signed timestamps help reject stale replayed payloads; event identifiers help recognise duplicate deliveries. Those details are Stripe-specific. Another sender may require a different verification scheme.
Our recommendation is to separate receipt, verification, processing and reconciliation in the integration design. Record which identifier represents a delivery and which identifies the underlying business event. Test duplicate delivery and recovery from a partially completed operation using safe fixtures. Do not invent a generic “retry signature” protocol.
Private connectivity needs explicit boundaries
For a site-to-site connection, document the permitted source and destination ranges, services, routing ownership and access policy. Consider overlapping customer address ranges during design. Decide how the chosen platform separates customer routes and how changes are reviewed.
One tunnel per customer can be an implementation choice, but tunnel count is not proof of isolation. A shared gateway can serve separated customer connections, while a dedicated tunnel can still expose an overbroad network path. Validate the actual routing and policy behaviour for the vendor platform before relying on it.
Private transport also does not replace application authentication and authorisation. Restrict the reachable service and its operations to what the integration needs. Agree who manages credentials, certificates or tunnel keys and how both sides are notified of changes.
These are requirements to test against the chosen network product, not a configuration recipe. No VPN commands or live network tests are supplied here.
File drops need processing rules as well as permissions
Give the customer a scoped transfer location and access rights. A folder name or object prefix is not an access-control policy by itself; verify the actual platform permissions. Avoid allowing one customer to list or download another customer's files or processing results.
Agree file naming, completion signalling, maximum size, expected format and acknowledgement. Plan validation before accepting the file into business processing. Define the handling of rejected, duplicate and partially uploaded files, along with retention and access to diagnostic results.
Our recommendation is to separate untrusted incoming material from accepted processing output and bound the resources used by parsing. The required malware and content controls depend on the formats and threat assessment. Do not treat an upload success message as evidence that the data is safe or valid.
Choose the route and its acceptance tests
| Need | Candidate route | Acceptance evidence |
|---|---|---|
| Interactive supported service interface | HTTPS API | Correct tenant, permissions, response and failure behaviour |
| Scheduled bulk exchange | Controlled file transfer | Complete delivery, validation and record reconciliation |
| Required private protocol path | Approved private connectivity | Scoped reachability plus application access checks |
For every route, test an allowed transaction, an unauthorised attempt, a duplicate and a controlled failure. Keep test volume bounded. Confirm that alerts identify the responsible team without exposing unnecessary customer content.
Define credential revocation and exit handling at onboarding. A retired customer integration should not retain access merely because its scheduled job stopped running.
Software vendor hosting is the relevant service area for discussing these requirements. No specific integration feature or security guarantee is claimed for NetLeverage.
Sources and limits
- OWASP REST Security Cheat Sheet, accessed 14 November 2026.
- OWASP API Security Top 10 2023, accessed 14 November 2026.
- Stripe webhook documentation, accessed 14 November 2026; a provider-specific example, not a universal implementation.
The checklists are editorial recommendations. No credentials, network configuration, production transactions or security tests were changed or executed for this article. Follow the current documentation for the actual integration products.
Learning notes
Transport security and tenant authorisation solve different problems. Retries require deliberate duplicate handling. Successful delivery is only one stage in proving that the intended business exchange completed correctly.
This article was originally published on .