Partner API Testing: A Matrix for Delegated Authority and Revocation

Partner API testing must prove whose authority is being used

A partner API often combines several identities: the platform, the partner application, the customer who authorised access and the user or service performing an operation. A valid credential does not automatically establish that every requested action is permitted. Useful testing follows the relationship between those identities, the delegated scope, the target object and the current authorisation state.

This guide provides a practical matrix for fintech teams assessing partner APIs. It focuses on delegated authority, customer separation, consent changes and offboarding rather than repeating a general API vulnerability checklist. The examples are fictional and assume explicit authorisation, designated partner accounts and synthetic records. They do not authorise testing a real partner’s infrastructure or accessing another customer’s data.

Our fintech penetration testing service examines API boundaries in the context of the product. The fintech API scope guide provides a broader starting point. Here the key question is specific: can the integration perform only the operations that the correct customer has delegated, for the correct resources, for as long as that authority remains valid?

Write down the delegation chain

Identify the legal and technical parties involved. A platform may host several partners, each serving multiple customers. A customer administrator may authorise an integration while individual users perform operations through it. The API may use a service credential plus a customer context, or a delegated token with claims. Document the actual model rather than assuming every integration follows the same OAuth pattern.

For each link in the chain, ask what it proves. A client credential may identify the partner application but not the customer’s permission for a particular account. A customer identifier may select a context without establishing ownership. A scope may permit a category of operation while object-level rules still restrict the target. The assessment should distinguish these layers because a failure at one can be hidden by correct behaviour at another.

Create a compact authority map showing the acting service, represented customer, permitted operations, relevant objects and source of the grant. Include where the decision is enforced and how changes propagate. Mark assumptions that require confirmation. This map becomes the basis for test cases and prevents the team from treating every successful authenticated request as authorised by definition.

Prepare two partners and two customer boundaries

A useful synthetic setup usually needs more than one partner and more than one customer. Two partners with similar capabilities help test partner separation. Two customers with different grants help test customer boundaries. Add roles or scopes only where they correspond to actual product behaviour. The objective is deliberate contrast, not a large collection of interchangeable accounts.

Document which partner is connected to which customer and what each grant permits. Prepare objects owned by each customer and, where relevant, objects accessible through a limited delegation. Use stable test identifiers and an owner who can reset the grants. Keep credentials in the agreed secure channel rather than in the general coverage spreadsheet.

Confirm that the environment represents the relevant enforcement paths. A mock partner may be sufficient for some API checks but may omit real authorisation or callback behaviour. A sandbox can provide safe transaction handling while differing from production configuration. State those differences and agree what conclusions the assessment can support.

Include an owner-operated path for granting, reducing and revoking access. Those lifecycle actions are central to delegated authority testing. If they are unavailable, record the coverage limit before starting. Do not simulate revocation only by deleting a local credential if the actual platform grant remains active; that would test a different condition.

Establish the permitted operation before testing the denial

For each material scope, execute a legitimate synthetic operation using the intended partner and customer relationship. Record the grant, object, operation and observed result. This positive control confirms that the integration is correctly configured. Without it, a negative test may be rejected simply because the credential never had access to the service at all.

Then vary one important boundary: a different customer, a different partner, a narrower scope or an object outside the grant. Keep the other conditions as comparable as possible. This makes the result interpretable and helps the team identify which enforcement point is responsible. A case that changes several unrelated inputs at once may be useful for exploration but is weaker evidence for a specific conclusion.

Inspect the business effect, not only the HTTP status. An accepted asynchronous request may later fail, and an error response may arrive after a state change has occurred. Agree how the owner will verify authoritative state for write operations. For read operations, use synthetic data sufficient to demonstrate the boundary without collecting unnecessary content.

Record the expected result before execution. If the owner cannot explain whether a partner should access an object, the assessment has found a requirements question rather than yet demonstrating a technical vulnerability. Resolve that question or preserve it explicitly. Testing cannot replace the product owner’s responsibility to define the intended authority model.

Test operation scope separately from object ownership

A partner may have permission to read records but not create, modify or delete them. Another may be permitted to initiate an operation but not approve it. Identify these distinctions in the API contract and the actual product rules. The assessment should verify that sensitive functions enforce the intended authority even when the requesting application is otherwise recognised.

The OWASP API guidance on function-level authorisation provides a useful reference for this boundary. In a fintech partner integration, the relevant finding should identify the specific operation and delegated authority affected. A broad statement that “the API lacks authorisation” is less useful than a precise account of which grant permitted an unintended action.

Object ownership remains a separate check. A partner with a valid read scope should not automatically read every customer’s object. Examine the relationship among the credential, customer context and requested object. Include indirect resources such as export jobs, status handles and generated documents where they are part of the scoped integration.

Check whether administrative or support routes share the same API surface. An operation intended only for platform staff may be reachable through a common gateway, but reachability alone does not establish a defect. The useful test verifies whether the partner’s authority is correctly constrained at the service performing the action. Keep the conclusion tied to observed behaviour.

Review the authorisation flow without assuming OAuth solves everything

Where OAuth is used, review the flow against the current product implementation and the IETF OAuth 2.0 Security Best Current Practice. That document covers modern threats and safeguards around authorisation flows and tokens. It is a technical reference, not proof that an application using OAuth has correct customer-level permissions or sound business logic.

Identify the registered client, redirect handling, requested scopes and the customer context bound to the grant. Ask how the platform prevents an authorisation response from being associated with the wrong initiating session or customer. Use the provider’s supported test environment and documented process. Do not infer that a custom flow is safe or unsafe solely from its appearance.

Inspect token and credential handling within the agreed scope. Determine where credentials are stored, which services receive them and how they are renewed or revoked. Avoid placing them in general logs or reports during the assessment. The finding evidence should demonstrate the relevant control without unnecessarily reproducing a usable secret.

Keep provider-specific semantics explicit. For example, Stripe’s Connect OAuth reference describes its own supported parameters and account relationships. Those details should not be generalised to every fintech platform. Use the actual provider documentation and record the version or relevant configuration context for the integration being assessed.

A delegated-authority testing matrix

Use a matrix that combines partner identity, customer relationship, operation, object and grant state. Do not attempt every possible combination without prioritisation. Select cases that exercise distinct enforcement paths and business consequences. A well-reasoned sample with clear limits is more useful than an enormous matrix that cannot be completed within the engagement.

For each case, specify the expected observation and the evidence source. A denial at the gateway may be sufficient for one read case, while a write case needs final-state confirmation. Include any documented propagation window for lifecycle changes. Otherwise the team may confuse a designed delay, an unexpected persistence and a test timing error.

Record cases that could not be completed and why. Missing test grants, unavailable provider sandboxes or unrepresentative mocks can materially limit confidence. The final report should show those boundaries. A provider should not label an integration comprehensively tested when the central delegation lifecycle was never exercised.

Verify offboarding across current access, renewal and background work

Revocation is not always a single action. The platform may disable a grant, invalidate renewal, retain a short-lived credential or stop a background job through a separate mechanism. The assessment should identify the intended behaviour for each relevant path and then observe it. Avoid assuming that removing a connection from the user interface proves that every downstream operation has stopped.

Prepare a controlled before-and-after sequence. Establish a permitted synthetic operation, revoke or reduce the grant through the owner’s approved process, then check the relevant access paths at agreed intervals. Include scheduled work and event delivery where they are within scope. Record timing and distinguish current access from the ability to obtain future credentials.

Check what happens to stored data. Revoking access may prevent new retrieval while the partner retains previously received information under the applicable agreement. That is a separate data-lifecycle question, not necessarily an API enforcement defect. The report should distinguish technical access termination from contractual retention and deletion obligations.

Test reauthorisation as a fresh decision where relevant. A new grant should not silently inherit unintended authority from an old connection merely because the same partner name appears. The exact expected behaviour depends on the product. Document it and verify the relationships among customer, partner, scopes and retained configuration rather than assuming a universal implementation.

Include callbacks and webhook subscriptions in the authority model

Partner integrations often receive asynchronous events after the initiating API operation. Identify who may create or change a subscription, which customer it belongs to, which events it receives and where delivery occurs. A correct read API does not establish that event delivery respects the same customer boundary. Treat subscription configuration and event content as part of the integration scope where relevant.

Use synthetic events and a controlled receiver. Verify the intended customer and event context without sending sensitive production data to a test endpoint. Determine how the platform authenticates delivery and how the receiver validates it, using the actual provider’s documentation. Avoid assuming that a familiar header name or shared secret pattern works identically across services.

Check lifecycle interactions. What happens to subscriptions when a customer revokes a partner, changes permissions or closes an account? Does the receiver continue to get events that exceed the current grant? The expected behaviour should be documented, including any legitimate final notifications. The test should distinguish an intentional lifecycle event from continued unauthorised data delivery.

Observe downstream effects as well as receipt. A duplicate or delayed event may trigger a business action at the partner. That may require a separate integration test with clear ownership. The API assessment should identify the boundary and avoid claiming that delivery authentication alone proves the safety of the partner’s processing logic.

Make partner activity attributable

Ask whether the audit record can identify the partner application, represented customer, relevant user or service, operation, object and result. These fields may be distributed across systems, but the organisation should be able to correlate them for the scoped workflow. A log containing only a generic platform service account can make investigation difficult even when the underlying action was legitimate.

Review the distinction between the authenticated caller and the represented principal. In a delegated operation, both can matter. The record should not misleadingly imply that the customer directly performed an action that a partner service initiated. The appropriate representation depends on the system, but it should support an accurate reconstruction of responsibility.

Use correlation identifiers carefully. They help connect requests, jobs and events, but they should not expose secrets or become an alternative access token. Agree how evidence will be collected and redacted. A useful report can show the relationship between records without publishing full credentials or unnecessary customer content.

If visibility is incomplete, state the limitation and its practical consequence. The assessment may demonstrate an operation but be unable to attribute it across every downstream service. That is different from proving that no audit record exists. Ask the owner to confirm the relevant sources before drawing a broad logging conclusion.

Describe the exact boundary that failed

A strong partner API finding identifies the legitimate grant, the unintended operation or object, the controlled evidence and the business effect. For example, a read-only synthetic partner may be able to change a specified setting for the connected customer. The report should not inflate that observation into unrestricted platform compromise unless the authorised evidence actually supports that conclusion.

Separate configuration mistakes from enforcement defects where the evidence allows. An overbroad grant approved by the customer is different from an API ignoring a narrow grant. Both may warrant action, but the owners and remediation differ. If the assessment cannot establish the cause, describe the observed behaviour and the investigation needed rather than guessing.

Include the lifecycle and environment context. A finding observed before a documented propagation period ends may need a different interpretation from one persisting afterward. A sandbox configuration may differ from production. State what was tested and what remains unverified. Precision helps the engineering team reproduce the issue and the business owner assess the actual exposure.

Recommend the required control outcome and acceptance cases. The implementation may involve centralised authority checks, better grant binding or corrected event filtering, depending on the system. The report should avoid prescribing a fashionable architecture without evidence. The useful question is whether the corrected service enforces the intended partner, customer, operation and lifecycle boundaries.

Retest positive and negative authority cases together

Repeat the demonstrated negative case after the fix and confirm that the legitimate integration still works. A blanket denial can remove the original weakness while breaking a customer’s required workflow. Use the same authority relationships and equivalent synthetic objects, with the current version and setup recorded. Revalidate prerequisites rather than assuming that the old grants still mean the same thing.

Check relevant adjacent routes within the agreed retest scope. A direct read endpoint, export job and event subscription may share a business boundary but use different enforcement code. The retest should state which paths were observed and which remain outside the check. Do not use one corrected response to imply complete integration assurance.

Preserve revocation and reauthorisation cases as regression candidates. Partner relationships change over time, so lifecycle correctness matters as much as initial onboarding. A small set of well-defined synthetic cases can help the product team detect regressions during future releases. The penetration test should leave those expectations clearer than it found them.

Use precise closure states. Verified correction, partial correction, implementation reviewed and risk accepted are not interchangeable. The report should say what evidence supports the status and identify any residual limit. This keeps procurement, engineering and risk teams aligned when they discuss whether the issue is actually closed.

Reassess authority when the integration changes

A partner integration can change without adding a new endpoint. A broader scope, new customer role, altered token lifetime or additional event type can change the authority boundary materially. Ask the product team to identify those changes in release planning. The existing test matrix provides a useful starting point: select the rows whose assumptions changed and add cases for any new relationship. This is more focused than repeating an identical generic API checklist after every release.

Maintain an owner for the integration contract and its security expectations. If product documentation says one thing while the implementation does another, resolve the discrepancy before the next assessment. A test cannot reliably judge delegated authority when the intended grant is ambiguous. Record decisions about scope expansion, retained data and offboarding so that developers, partner managers and security reviewers use the same model.

During an assessment, preserve changes to grants and configuration in the evidence timeline. If a customer permission is modified while a case is running, re-establish the prerequisites before interpreting the result. This avoids attributing a temporary setup inconsistency to the API or dismissing a real failure as a mysterious test problem. Clear change context makes the final evidence more reproducible and the remediation discussion more efficient.

Prepare the partner API scope before sharing secrets

For an initial proposal, describe the partner types, customer model, authorisation flow, scopes, API operations, event delivery and offboarding process. Identify available sandboxes and whether synthetic partner grants can be created. Explain which financial effects must remain disabled and who can verify final state. These inputs are more useful than sending an API key before the scope is understood.

Use the fintech scoping brief or contact Atlant Security to discuss the integration. Agree the NDA and secure exchange route before providing sensitive documentation, credentials or logs. The proposal should identify the delegated-authority questions, required test inputs and the evidence that will support acceptance.

This guide was reviewed on 25 October 2026. It provides practical assessment recommendations, not a complete OAuth conformance test or a guarantee that every partner risk is covered. A useful partner API assessment makes the authority chain observable: who is acting, for whom, on which object, with which permission and under which current grant. That is the foundation for evidence that the product team can act on.