feat(openapi): add bank bridge methods #519
Conversation
WalkthroughAdds Payment Service User (PSU) management to v3: documents endpoints and schemas; introduces client SDK docs; adds Go component/operation models and enums; implements client methods in v3.go for PSU deletion, forwarding, link create/update, listing connections/link attempts, and deleting connectors/connections, with async task responses and cursor-based listings. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
participant App
participant V3Client
participant API
rect rgba(220,240,255,0.4)
note over App,V3Client: Create Link for PSU (connector)
App->>V3Client: CreateLinkForPaymentServiceUser(psuID, connectorID, body)
V3Client->>API: POST /v3/payment-service-users/{psuID}/connectors/{connectorID}/links
alt 201 Created
API-->>V3Client: { attemptID, link }
V3Client-->>App: V3CreateLinkForPaymentServiceUserResponse
else 4XX/5XX
API-->>V3Client: Error payload
V3Client-->>App: V3ErrorResponse
end
end
sequenceDiagram
autonumber
participant App
participant V3Client
participant API
participant Tasks as Task API
rect rgba(240,230,255,0.4)
note over App,API: Delete PSU Connector (async)
App->>V3Client: DeletePaymentServiceUserConnector(psuID, connectorID)
V3Client->>API: DELETE /v3/payment-service-users/{psuID}/connectors/{connectorID}
alt 202 Accepted
API-->>V3Client: { data: { taskID } }
V3Client-->>App: taskID
App->>Tasks: GET /tasks/{taskID}
Tasks-->>App: status (pending/completed/failed)
else 4XX/5XX
API-->>V3Client: Error payload
V3Client-->>App: V3ErrorResponse
end
end
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Possibly related PRs
Suggested reviewers
Poem
Tip 🔌 Remote MCP (Model Context Protocol) integration is now available!Pro plan users can now connect to remote MCP servers from the Integrations page. Connect with popular remote MCPs such as Notion and Linear to add more context to your reviews and chats. ✨ Finishing Touches
🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
CodeRabbit Configuration File (
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #519 +/- ##
=======================================
Coverage 66.72% 66.73%
=======================================
Files 761 761
Lines 39729 39729
=======================================
+ Hits 26510 26513 +3
+ Misses 11836 11834 -2
+ Partials 1383 1382 -1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
| <h3 id="list-all-connections-for-a-payment-service-user-parameters">Parameters</h3> | ||
|
|
||
| |Name|In|Type|Required|Description| | ||
| |---|---|---|---|---| | ||
| |paymentServiceUserID|path|string|true|The payment service user ID| | ||
|
|
There was a problem hiding this comment.
🛠️ Refactor suggestion
Add pagination query params to PSU connections list.
This list endpoint returns a cursor object but does not declare pageSize/cursor query params. Align with other list endpoints to avoid client confusion and SDK gaps.
Apply this doc fix:
|Name|In|Type|Required|Description|
|---|---|---|---|---|
|paymentServiceUserID|path|string|true|The payment service user ID|
+|pageSize|query|integer(int64)|false|The number of items to return|
+|cursor|query|string|false|Parameter used in pagination requests. Set to the value of next for the next page of results. Set to the value of previous for the previous page of results. No other parameters can be set when this parameter is set.|📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| <h3 id="list-all-connections-for-a-payment-service-user-parameters">Parameters</h3> | |
| |Name|In|Type|Required|Description| | |
| |---|---|---|---|---| | |
| |paymentServiceUserID|path|string|true|The payment service user ID| | |
| <h3 id="list-all-connections-for-a-payment-service-user-parameters">Parameters</h3> | |
| |Name|In|Type|Required|Description| | |
| |---|---|---|---|---| | |
| |paymentServiceUserID|path|string|true|The payment service user ID| | |
| |pageSize|query|integer(int64)|false|The number of items to return| | |
| |cursor|query|string|false|Parameter used in pagination requests. Set to the value of next for the next page of results. Set to the value of previous for the previous page of results. No other parameters can be set when this parameter is set.| |
🤖 Prompt for AI Agents
In docs/api/README.md around lines 2469 to 2474, the PSU connections list
parameters table is missing pagination query params; add two rows to the table
for pageSize and cursor with Name=pageSize, In=query, Type=integer (or string if
other docs use string), Required=false, Description="Number of items to return
(optional pagination size)" and Name=cursor, In=query, Type=string,
Required=false, Description="Cursor for next page (optional)"; ensure formatting
matches the existing markdown table and aligns with other list endpoints in the
docs.
| <h3 id="list-all-connections-for-a-payment-service-user-on-a-connector-parameters">Parameters</h3> | ||
|
|
||
| |Name|In|Type|Required|Description| | ||
| |---|---|---|---|---| | ||
| |paymentServiceUserID|path|string|true|The payment service user ID| | ||
| |connectorID|path|string|true|The connector ID| | ||
|
|
There was a problem hiding this comment.
Add pagination params to PSU connections and link-attempts list (connector-scoped).
Both endpoints return cursors but don’t declare pageSize/cursor. Please add them (and optionally V3QueryBuilder body) to match list patterns elsewhere.
Apply this doc fix in both parameter tables:
|Name|In|Type|Required|Description|
|---|---|---|---|---|
|paymentServiceUserID|path|string|true|The payment service user ID|
|connectorID|path|string|true|The connector ID|
+|pageSize|query|integer(int64)|false|The number of items to return|
+|cursor|query|string|false|Parameter used in pagination requests. Set to the value of next for the next page of results. Set to the value of previous for the previous page of results. No other parameters can be set when this parameter is set.|Also applies to: 2742-2748
🤖 Prompt for AI Agents
In docs/api/README.md around lines 2679-2685 (and also apply the same change at
lines 2742-2748), the PSU connections and link-attempts connector-scoped
parameter tables are missing pagination parameters; add rows for pageSize
(query|integer|optional|number of items per page) and cursor
(query|string|optional|opaque cursor for pagination) and, to match other list
endpoints, optionally add a V3QueryBuilder request body description if this
endpoint supports body-based query filters; ensure the table columns (Name, In,
Type, Required, Description) are populated consistently with other list
endpoints in the document.
| > 202 Response | ||
|
|
||
| ```json | ||
| { | ||
| "data": { | ||
| "taskID": "string" | ||
| } | ||
| } | ||
| ``` |
There was a problem hiding this comment.
Fix formatting: stray spaces and “Unknown” meaning for 202.
There’s a double-space in the example title and the responses table shows Meaning “Unknown” instead of an RFC link, which breaks consistency.
Apply:
-> 202 Response
+> 202 Response
...
-|202 |Unknown|Accepted|[V3PaymentServiceUserDeleteConnectionResponse](#schemav3paymentserviceuserdeleteconnectionresponse)|
+|202|[Accepted](https://tools.ietf.org/html/rfc7231#section-6.3.3)|Accepted|[V3PaymentServiceUserDeleteConnectionResponse](#schemav3paymentserviceuserdeleteconnectionresponse)|Also applies to: 2877-2879
🤖 Prompt for AI Agents
In docs/api/README.md around lines 2863-2871 and also 2877-2879, fix the
formatting: remove the stray double-space in the example status/title (change
"202 Response" to "202 Response") and update the Responses table entry that
currently shows Meaning "Unknown" to the proper RFC reference link or text
(e.g., "See RFC 7231 (Accepted)") to match other status code rows; ensure
spacing and markdown formatting remain consistent with surrounding entries.
| | Name | Value | | ||
| | ------------------------------ | ------------------------------ | | ||
| | `V3ConnectionStatusEnumActive` | ACTIVE | | ||
| | `V3ConnectionStatusEnumError` | ERROR | |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Document semantics of each enum value and future-proof guidance
Add brief descriptions to clarify lifecycle states and note behavior for unknown values (e.g., whether the client rejects them via JSON unmarshalling).
If UnmarshalJSON rejects unknown values, call that out explicitly.
-## Values
+## Values
@@
-| Name | Value |
-| ------------------------------ | ------------------------------ |
-| `V3ConnectionStatusEnumActive` | ACTIVE |
-| `V3ConnectionStatusEnumError` | ERROR |
+| Name | Value | Description |
+| ------------------------------ | ------ | ------------------------------------ |
+| `V3ConnectionStatusEnumActive` | ACTIVE | Connection is established and usable. |
+| `V3ConnectionStatusEnumError` | ERROR | Connector reported an error; not usable until resolved. |
+
+### Notes
+- Unknown values: If the SDK’s `UnmarshalJSON` rejects unknown strings, SDK upgrades are required before new server-side statuses can be consumed.To confirm unknown-value behavior:
🏁 Script executed:
#!/bin/bash
# Inspect the enum's UnmarshalJSON implementation
rg -n -C3 'type\s+V3ConnectionStatusEnum\b' pkg/client/models/components && \
rg -n -C5 'UnmarshalJSON\(\[\]byte\)\s*error' pkg/client/models/componentsLength of output: 672
Update documentation for V3ConnectionStatusEnum values and unknown‐value behavior
The enum docs should include descriptions for each value and accurately reflect how unknown strings are handled (there is no custom UnmarshalJSON, so unknown values are accepted without error).
• File: pkg/client/docs/models/components/v3connectionstatusenum.md
• Lines: 6–9
## Values
-| Name | Value |
-| ------------------------------ | ------------------------------ |
-| `V3ConnectionStatusEnumActive` | ACTIVE |
-| `V3ConnectionStatusEnumError` | ERROR |
+| Name | Value | Description |
+| ------------------------------ | ------ | ------------------------------------------------------------ |
+| `V3ConnectionStatusEnumActive` | ACTIVE | Connection is established and usable. |
+| `V3ConnectionStatusEnumError` | ERROR | Connector reported an error; not usable until resolved. |
+
+### Notes
+- Unknown values: The SDK does **not** implement a custom `UnmarshalJSON` for this enum. Any unrecognized status strings in the JSON payload will be unmarshalled into the `V3ConnectionStatusEnum` type as-is (without error). Clients should include fallback logic to handle unexpected values. 📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| | Name | Value | | |
| | ------------------------------ | ------------------------------ | | |
| | `V3ConnectionStatusEnumActive` | ACTIVE | | |
| | `V3ConnectionStatusEnumError` | ERROR | | |
| ## Values | |
| | Name | Value | Description | | |
| | ------------------------------ | ------ | ------------------------------------------------------------ | | |
| | `V3ConnectionStatusEnumActive` | ACTIVE | Connection is established and usable. | | |
| | `V3ConnectionStatusEnumError` | ERROR | Connector reported an error; not usable until resolved. | | |
| ### Notes | |
| - Unknown values: The SDK does **not** implement a custom `UnmarshalJSON` for this enum. Any unrecognized status strings in the JSON payload will be unmarshalled into the `V3ConnectionStatusEnum` type as-is (without error). Clients should include fallback logic to handle unexpected values. |
🤖 Prompt for AI Agents
In pkg/client/docs/models/components/v3connectionstatusenum.md around lines 6 to
9, the table currently only lists enum names and values; update it to include a
short description for each value (e.g., ACTIVE: connection established and
healthy; ERROR: connection has encountered an error) and add a note clarifying
that the type does not implement a custom UnmarshalJSON so unknown string values
are accepted without error rather than being rejected. Ensure the table rows are
updated with descriptions and add one sentence after the table about
unknown-value behavior.
| | `Error` | **string* | :heavy_minus_sign: | N/A | | ||
| | `Metadata` | map[string]*string* | :heavy_minus_sign: | N/A | |
There was a problem hiding this comment.
Fix broken Markdown type rendering for Error and normalize map type formatting.
**string* renders incorrectly (unbalanced asterisks). Also consider using code formatting for map types to avoid italic glitches.
Proposed diff:
-| `Error` | **string* | :heavy_minus_sign: | N/A |
-| `Metadata` | map[string]*string* | :heavy_minus_sign: | N/A |
+| `Error` | *string* | :heavy_minus_sign: | N/A |
+| `Metadata` | `map[string]string` | :heavy_minus_sign: | N/A |If the Go model uses map[string]*string, then prefer:
-| `Metadata` | map[string]*string* | :heavy_minus_sign: | N/A |
+| `Metadata` | `map[string]*string` | :heavy_minus_sign: | N/A |📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| | `Error` | **string* | :heavy_minus_sign: | N/A | | |
| | `Metadata` | map[string]*string* | :heavy_minus_sign: | N/A | | |
| | `Error` | *string* | :heavy_minus_sign: | N/A | | |
| | `Metadata` | `map[string]string` | :heavy_minus_sign: | N/A | |
🤖 Prompt for AI Agents
In pkg/client/docs/models/components/v3paymentserviceuserconnection.md around
lines 13 to 14, the Markdown table cell for `Error` has unbalanced asterisks
causing italic rendering and the map type for `Metadata` is not code-formatted;
fix by replacing the malformed `**string*` with a proper inline code token
`string` (or `code`-wrapped as `string`) and normalize the map type to use
inline code formatting exactly as `map[string]*string` so both types render
correctly and avoid italic glitches.
| ## ListPaymentServiceUserConnections | ||
|
|
||
| List all connections for a payment service user | ||
|
|
||
| ### Example Usage | ||
|
|
||
| ```go | ||
| package main | ||
|
|
||
| import( | ||
| "context" | ||
| "github.com/formancehq/payments/pkg/client" | ||
| "os" | ||
| "log" | ||
| ) | ||
|
|
||
| func main() { | ||
| ctx := context.Background() | ||
|
|
||
| s := client.New( | ||
| "https://api.example.com", | ||
| client.WithSecurity(os.Getenv("FORMANCE_AUTHORIZATION")), | ||
| ) | ||
|
|
||
| res, err := s.Payments.V3.ListPaymentServiceUserConnections(ctx, "<id>") | ||
| if err != nil { | ||
| log.Fatal(err) | ||
| } | ||
| if res.V3PaymentServiceUserConnectionsCursorResponse != nil { | ||
| // handle response | ||
| } | ||
| } | ||
| ``` | ||
|
|
||
| ### Parameters | ||
|
|
||
| | Parameter | Type | Required | Description | | ||
| | -------------------------------------------------------- | -------------------------------------------------------- | -------------------------------------------------------- | -------------------------------------------------------- | | ||
| | `ctx` | [context.Context](https://pkg.go.dev/context#Context) | :heavy_check_mark: | The context to use for the request. | | ||
| | `paymentServiceUserID` | *string* | :heavy_check_mark: | The payment service user ID | | ||
| | `opts` | [][operations.Option](../../models/operations/option.md) | :heavy_minus_sign: | The options for this request. | | ||
|
|
||
| ### Response | ||
|
|
||
| **[*operations.V3ListPaymentServiceUserConnectionsResponse](../../models/operations/v3listpaymentserviceuserconnectionsresponse.md), error** |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Docs show cursor-based responses but omit pagination params in requests.
These three sections return CursorResponse types, but the request signatures in the docs don’t expose typical pageSize/cursor query params. This risks confusing SDK users about how to fetch subsequent pages.
- ListPaymentServiceUserConnections
- ListPaymentServiceUserConnectionsFromConnectorID
- ListPaymentServiceUserLinkAttemptsFromConnectorID
Action options:
- If the generated operation requests really accept
pageSize/cursor, document them in “Parameters” and the example usage (like other list endpoints). - If pagination is not supported, consider switching the response model away from the cursor wrapper or clearly state that only a single page is returned and
cursor.nextwill be empty.
Run the script to confirm the actual request structs and their fields:
If these structs include PageSize *int64 or Cursor *string, I can push a doc patch to add the parameters and update the examples accordingly. Otherwise, we should adjust the response type or add an explanatory note under each section.
Also applies to: 2244-2290, 2298-2344
🏁 Script executed:
#!/bin/bash
# Inspect request types for the three endpoints to see if pageSize/cursor exist.
set -euo pipefail
rg -nP "type\s+V3ListPaymentServiceUserConnectionsRequest\b.*\{.*" -C3 --no-heading pkg/client/models/operations || true
rg -nP "type\s+V3ListPaymentServiceUserConnectionsFromConnectorIDRequest\b.*\{.*" -C6 --no-heading pkg/client/models/operations || true
rg -nP "type\s+V3ListPaymentServiceUserLinkAttemptsFromConnectorIDRequest\b.*\{.*" -C6 --no-heading pkg/client/models/operations || trueLength of output: 4171
Clarify pagination support for cursor-based responses
The request structs for the following endpoints do not include any pageSize or cursor fields, yet their responses use cursor wrappers. To avoid confusing SDK users, update the docs to explicitly state pagination isn’t supported (only a single page is returned and cursor.next will always be empty) or switch to a non-cursor response model:
• pkg/client/docs/sdks/v3/README.md – ListPaymentServiceUserConnections (lines 2032–2076)
• pkg/client/docs/sdks/v3/README.md – ListPaymentServiceUserConnectionsFromConnectorID (lines 2244–2290)
• pkg/client/docs/sdks/v3/README.md – ListPaymentServiceUserLinkAttemptsFromConnectorID (lines 2298–2344)
Suggested doc patch:
### Response
- **[*operations.V3ListPaymentServiceUserConnectionsResponse](…cursorresponse.md), error**
+ **[*operations.V3ListPaymentServiceUserConnectionsResponse](…cursorresponse.md), error**
+
+ _Note: This operation does not support pagination parameters. Only a single page is returned and `cursor.next` will always be empty._Repeat similar notes for the other two sections.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| ## ListPaymentServiceUserConnections | |
| List all connections for a payment service user | |
| ### Example Usage | |
| ```go | |
| package main | |
| import( | |
| "context" | |
| "github.com/formancehq/payments/pkg/client" | |
| "os" | |
| "log" | |
| ) | |
| func main() { | |
| ctx := context.Background() | |
| s := client.New( | |
| "https://api.example.com", | |
| client.WithSecurity(os.Getenv("FORMANCE_AUTHORIZATION")), | |
| ) | |
| res, err := s.Payments.V3.ListPaymentServiceUserConnections(ctx, "<id>") | |
| if err != nil { | |
| log.Fatal(err) | |
| } | |
| if res.V3PaymentServiceUserConnectionsCursorResponse != nil { | |
| // handle response | |
| } | |
| } | |
| ``` | |
| ### Parameters | |
| | Parameter | Type | Required | Description | | |
| | -------------------------------------------------------- | -------------------------------------------------------- | -------------------------------------------------------- | -------------------------------------------------------- | | |
| | `ctx` | [context.Context](https://pkg.go.dev/context#Context) | :heavy_check_mark: | The context to use for the request. | | |
| | `paymentServiceUserID` | *string* | :heavy_check_mark: | The payment service user ID | | |
| | `opts` | [][operations.Option](../../models/operations/option.md) | :heavy_minus_sign: | The options for this request. | | |
| ### Response | |
| **[*operations.V3ListPaymentServiceUserConnectionsResponse](../../models/operations/v3listpaymentserviceuserconnectionsresponse.md), error** | |
| ### Response | |
| **[*operations.V3ListPaymentServiceUserConnectionsResponse](../../models/operations/v3listpaymentserviceuserconnectionsresponse.md), error** | |
| _Note: This operation does not support pagination parameters. Only a single page is returned and `cursor.next` will always be empty._ |
🧰 Tools
🪛 markdownlint-cli2 (0.17.2)
2042-2042: Hard tabs
Column: 1
(MD010, no-hard-tabs)
2043-2043: Hard tabs
Column: 1
(MD010, no-hard-tabs)
2044-2044: Hard tabs
Column: 1
(MD010, no-hard-tabs)
2045-2045: Hard tabs
Column: 1
(MD010, no-hard-tabs)
🤖 Prompt for AI Agents
In pkg/client/docs/sdks/v3/README.md around lines 2032–2076, the
ListPaymentServiceUserConnections doc shows a cursor-wrapped response but the
request has no pageSize/cursor parameters; update the documentation to clarify
that pagination is not supported (only a single page is returned and cursor.next
will always be empty) or replace the response example with a non-cursor response
model; apply the same clarification or response-model change to the two other
sections noted (ListPaymentServiceUserConnectionsFromConnectorID at ~2244–2290
and ListPaymentServiceUserLinkAttemptsFromConnectorID at ~2298–2344) so SDK
users aren’t misled about cursor-based pagination.
| TaskID string `json:"taskID"` | ||
| } |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Double-check JSON property spelling: "taskID" vs "taskId" across the spec
Generated tag uses taskID. If the OpenAPI uses taskId, clients will fail to deserialize. Please verify the casing in the OpenAPI and server payloads for consistency.
Run from repo root:
🏁 Script executed:
#!/bin/bash
# Scan OpenAPI/spec files for taskID vs taskId to ensure consistent casing
set -euo pipefail
# Look for common spec locations; fall back to repo-wide search
fd -t f -e yml -e yaml -e json --search-path . | rg -nP -S '\btaskID\b|\btaskId\b' -f - || true
echo ""
echo "Occurrences of taskID/taskId in generated client (sanity check):"
rg -nP -S '\btaskID\b|\btaskId\b' pkg/client | sed -n '1,200p'Length of output: 3765
Align taskId Casing Across Generated Client
It’s critical that the JSON property and path-parameter names for the Task ID match the OpenAPI spec exactly—mismatches like taskID vs. taskId will cause client-side deserialization failures. Our grep results show mixed usage:
• In component response models (all use json:"taskID"):
- pkg/client/models/components/v3forwardbankaccountresponse.go:8
- pkg/client/models/components/v3paymentserviceuserdeleteresponse.go:8
- pkg/client/models/components/v3paymentserviceuserdeleteconnectorresponse.go:8
- pkg/client/models/components/v3uninstallconnectorresponse.go:8
- pkg/client/models/components/v3reversepaymentinitiationresponse.go:8
- pkg/client/models/components/v3paymentserviceuserdeleteconnectionresponse.go:8
- pkg/client/models/components/v3retrypaymentinitiationresponse.go:8
- pkg/client/models/components/v3initiatepaymentresponse.go:11
- pkg/client/models/components/v3forwardpaymentserviceuserbankaccountresponse.go:8
- pkg/client/models/components/v3approvepaymentinitiationresponse.go:8
• In operation-models (pathParam tags use lowercase taskId):
- pkg/client/models/operations/getconnectortask.go:13 (
name=taskId) - pkg/client/models/operations/getconnectortaskv1.go:15 (
name=taskId)
• In V3 client methods/URLs (use uppercase in path):
- pkg/client/v3.go:12431
"/v3/tasks/{taskID}"
Please reconcile all of these to the exact casing defined in the OpenAPI spec (most likely taskId). Failing to do so will break both request URL generation and response unmarshalling.
Affected files and suggested changes:
- pkg/client/models/components/*Response.go (change
json:"taskID"→json:"taskId") - pkg/client/models/operations/*.go (ensure
pathParam:"...name=taskId"matches spec) - pkg/client/v3.go (update path template to
"/v3/tasks/{taskId}") - pkg/client/docs/sdks/**/README.md (update examples and tables to
taskId)
Example diff for a component model:
--- a/pkg/client/models/components/v3paymentserviceuserdeleteresponse.go
+++ b/pkg/client/models/components/v3paymentserviceuserdeleteresponse.go
@@ -5,7 +5,7 @@
type V3PaymentServiceUserDeleteResponse struct {
- TaskID string `json:"taskID"`
+ TaskID string `json:"taskId"`
}After making these edits, please re-verify against your OpenAPI spec with a corrected search command:
#!/bin/bash
set -euo pipefail
echo "Spec occurrences of 'taskId':"
rg -n '"taskId"\s*:' -- '**/*.yaml' '**/*.yml' '**/*.json' || true
echo ""
echo "Spec occurrences of 'taskID':"
rg -n '"taskID"\s*:' -- '**/*.yaml' '**/*.yml' '**/*.json' || trueThis will confirm the canonical casing and ensure full consistency across client code and documentation.
🤖 Prompt for AI Agents
In pkg/client/models/components/v3paymentserviceuserdeleteresponse.go around
lines 8-9, the JSON tag uses `json:"taskID"` which mismatches the OpenAPI spec
casing; change the struct tag to `json:"taskId"`. Also scan and update all
component response models to `json:"taskId"`, ensure operation models' pathParam
names use `taskId`, update any v3 client path templates (e.g.
"/v3/tasks/{taskID}" → "/v3/tasks/{taskId}"), and fix SDK docs/examples to use
`taskId`; after edits re-run the provided grep commands against the OpenAPI spec
to confirm canonical casing and consistency.
| type V3ListPaymentServiceUserConnectionsRequest struct { | ||
| // The payment service user ID | ||
| PaymentServiceUserID string `pathParam:"style=simple,explode=false,name=paymentServiceUserID"` | ||
| } |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Pagination inputs appear missing for a cursor-based list.
The response type is a cursor wrapper, but the request has no query params (e.g., cursor, pageSize). If the API supports paginating subsequent pages, these should exist in the request model. Please confirm the OpenAPI spec intentionally omits them; otherwise, add query parameters so clients can request next pages.
Run to check whether any v3 list ops expose cursor/pageSize query params and whether docs mention them:
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "Search for cursor/pageSize query params in operations:"
rg -nP --type=go -C2 'queryParam:".*cursor|queryParam:".*page(Size)?' pkg/client/models/operations || true
echo -e "\nSearch for cursor mention in docs (if present):"
fd -t f -a 'docs' 2>/dev/null | rg -n 'cursor|pageSize' -n || true
echo -e "\nInspect this operation’s docs pages if they exist:"
fd -t f -a 'v3listpaymentserviceuserconnectionsrequest.md' 2>/dev/null || true
fd -t f -a 'v3listpaymentserviceuserconnectionsresponse.md' 2>/dev/null || trueLength of output: 20947
Add missing pagination parameters to V3ListPaymentServiceUserConnectionsRequest
The cursor-wrapped response implies the API supports pagination, but the request model only defines the PaymentServiceUserID path parameter and omits the pageSize and cursor query parameters. All other V3List* operations include these fields. Please update pkg/client/models/operations/v3listpaymentserviceuserconnections.go to match the pattern, for example:
type V3ListPaymentServiceUserConnectionsRequest struct {
// The payment service user ID
PaymentServiceUserID string `pathParam:"style=simple,explode=false,name=paymentServiceUserID"`
+ // The number of items to return
+ PageSize *int64 `queryParam:"style=form,explode=true,name=pageSize"`
+ // Parameter used in pagination requests. Set to the value of next for the next page of results. No other parameters can be set when this parameter is set.
+ Cursor *string `queryParam:"style=form,explode=true,name=cursor"`
}This will allow clients to request subsequent pages consistently.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| type V3ListPaymentServiceUserConnectionsRequest struct { | |
| // The payment service user ID | |
| PaymentServiceUserID string `pathParam:"style=simple,explode=false,name=paymentServiceUserID"` | |
| } | |
| type V3ListPaymentServiceUserConnectionsRequest struct { | |
| // The payment service user ID | |
| PaymentServiceUserID string `pathParam:"style=simple,explode=false,name=paymentServiceUserID"` | |
| // The number of items to return | |
| PageSize *int64 `queryParam:"style=form,explode=true,name=pageSize"` | |
| // Parameter used in pagination requests. Set to the value of next for the next page of results. No other parameters can be set when this parameter is set. | |
| Cursor *string `queryParam:"style=form,explode=true,name=cursor"` | |
| } |
🤖 Prompt for AI Agents
In pkg/client/models/operations/v3listpaymentserviceuserconnections.go around
lines 9 to 12, the request struct only includes the path param but is missing
pagination query parameters; add optional Cursor and PageSize fields to the
V3ListPaymentServiceUserConnectionsRequest struct (use pointer types so they are
optional), annotate them with queryParam tags (name=cursor and name=pageSize)
matching the other V3List* request patterns, and keep the existing
PaymentServiceUserID pathParam unchanged so clients can request paged results
consistently.
| type V3ListPaymentServiceUserConnectionsFromConnectorIDRequest struct { | ||
| // The payment service user ID | ||
| PaymentServiceUserID string `pathParam:"style=simple,explode=false,name=paymentServiceUserID"` | ||
| // The connector ID | ||
| ConnectorID string `pathParam:"style=simple,explode=false,name=connectorID"` | ||
| } |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Likely missing pagination query params for cursor traversal.
As with the other list operations, there are no query params for cursor/pageSize, which limits clients to the first page. Verify the OpenAPI definition and add them if supported so generators expose pagination inputs.
Script to spot any existing v3 list ops that already model cursor/pageSize:
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "Check for v3 list requests with query params:"
rg -nP --type=go -C2 'type\s+V3.*List.*Request|queryParam:' pkg/client/models/operations || true
echo -e "\nSearch for 'pageSize' and 'cursor' across v3 components/operations:"
rg -n 'pageSize|cursor' pkg/client/models || trueLength of output: 42002
Add pagination parameters to V3ListPaymentServiceUserConnectionsFromConnectorIDRequest
The V3ListPaymentServiceUserConnectionsFromConnectorIDRequest struct currently only defines the two required path parameters and cannot be paged. All other v3 “List” operations include pageSize and cursor query params to support cursor-based traversal (e.g. V3ListAccountsRequest, V3ListPoolsRequest) . To align this endpoint with the rest of the API surface:
Apply the following diff after you’ve confirmed your OpenAPI spec supports these params on
GET /v3/payment-service-user-connections/{paymentServiceUserID}/connectors/{connectorID}:
pkg/client/models/operations/v3listpaymentserviceuserconnectionsfromconnectorid.go
type V3ListPaymentServiceUserConnectionsFromConnectorIDRequest struct {
// The payment service user ID
PaymentServiceUserID string `pathParam:"style=simple,explode=false,name=paymentServiceUserID"`
// The connector ID
ConnectorID string `pathParam:"style=simple,explode=false,name=connectorID"`
+ // The number of items to return per page
+ PageSize *int64 `queryParam:"style=form,explode=true,name=pageSize"`
+ // Cursor for pagination. Use the `next` or `previous` value from the prior response.
+ Cursor *string `queryParam:"style=form,explode=true,name=cursor"`
}• Verify in your OpenAPI definition that this operation defines pageSize and cursor as query parameters.
• If it’s missing, add them to the spec and regenerate the client.
• Otherwise, regenerate and confirm these fields appear in the generated code.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| type V3ListPaymentServiceUserConnectionsFromConnectorIDRequest struct { | |
| // The payment service user ID | |
| PaymentServiceUserID string `pathParam:"style=simple,explode=false,name=paymentServiceUserID"` | |
| // The connector ID | |
| ConnectorID string `pathParam:"style=simple,explode=false,name=connectorID"` | |
| } | |
| type V3ListPaymentServiceUserConnectionsFromConnectorIDRequest struct { | |
| // The payment service user ID | |
| PaymentServiceUserID string `pathParam:"style=simple,explode=false,name=paymentServiceUserID"` | |
| // The connector ID | |
| ConnectorID string `pathParam:"style=simple,explode=false,name=connectorID"` | |
| // The number of items to return per page | |
| PageSize *int64 `queryParam:"style=form,explode=true,name=pageSize"` | |
| // Cursor for pagination. Use the `next` or `previous` value from the prior response. | |
| Cursor *string `queryParam:"style=form,explode=true,name=cursor"` | |
| } |
| type V3ListPaymentServiceUserLinkAttemptsFromConnectorIDRequest struct { | ||
| // The payment service user ID | ||
| PaymentServiceUserID string `pathParam:"style=simple,explode=false,name=paymentServiceUserID"` | ||
| // The connector ID | ||
| ConnectorID string `pathParam:"style=simple,explode=false,name=connectorID"` | ||
| } |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Cursor-based listing without query params may prevent fetching next pages.
Given the cursor-shaped response, missing query params (cursor, pageSize) likely prevents clients from traversing pages. Please verify the OpenAPI spec; if pagination inputs exist in the backend, add them to the operation definition so the generator includes them.
Use this script to compare other link-attempts list ops for pagination knobs:
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "Look for query params on link attempt list operations:"
rg -nP --type=go -C2 'type\s+V3.*LinkAttempts.*Request|queryParam:' pkg/client/models/operations || true
echo -e "\nSearch for 'pageSize' and 'cursor' across repo:"
rg -n 'pageSize|cursor' -g '!**/vendor/**' || trueLength of output: 266860
Add pagination query parameters to V3ListPaymentServiceUserLinkAttemptsFromConnectorIDRequest
The V3ListPaymentServiceUserLinkAttemptsFromConnectorIDRequest struct is missing the standard pageSize and cursor query parameters that all other V3 “list” operations include. Without these, clients cannot traverse beyond the first page. Please:
• Update the OpenAPI spec for this operation to include the pageSize and cursor query parameters (matching style/form, explode=true).
• Regenerate the client so these fields appear in the request model.
• In pkg/client/models/operations/v3listpaymentserviceuserlinkattemptsfromconnectorid.go, add the following fields to the struct:
type V3ListPaymentServiceUserLinkAttemptsFromConnectorIDRequest struct {
// The payment service user ID
PaymentServiceUserID string `pathParam:"style=simple,explode=false,name=paymentServiceUserID"`
// The connector ID
ConnectorID string `pathParam:"style=simple,explode=false,name=connectorID"`
+ // The number of items to return
+ PageSize *int64 `queryParam:"style=form,explode=true,name=pageSize"`
+ // Parameter used in pagination requests. Set to the value of next for the next page of results.
+ // Set to the value of previous for the previous page of results. No other parameters can be set when this parameter is set.
+ Cursor *string `queryParam:"style=form,explode=true,name=cursor"`
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| type V3ListPaymentServiceUserLinkAttemptsFromConnectorIDRequest struct { | |
| // The payment service user ID | |
| PaymentServiceUserID string `pathParam:"style=simple,explode=false,name=paymentServiceUserID"` | |
| // The connector ID | |
| ConnectorID string `pathParam:"style=simple,explode=false,name=connectorID"` | |
| } | |
| type V3ListPaymentServiceUserLinkAttemptsFromConnectorIDRequest struct { | |
| // The payment service user ID | |
| PaymentServiceUserID string `pathParam:"style=simple,explode=false,name=paymentServiceUserID"` | |
| // The connector ID | |
| ConnectorID string `pathParam:"style=simple,explode=false,name=connectorID"` | |
| // The number of items to return | |
| PageSize *int64 `queryParam:"style=form,explode=true,name=pageSize"` | |
| // Parameter used in pagination requests. Set to the value of next for the next page of results. | |
| // Set to the value of previous for the previous page of results. No other parameters can be set when this parameter is set. | |
| Cursor *string `queryParam:"style=form,explode=true,name=cursor"` | |
| } |
🤖 Prompt for AI Agents
In
pkg/client/models/operations/v3listpaymentserviceuserlinkattemptsfromconnectorid.go
around lines 9 to 14, the request struct is missing the standard pagination
query parameters; update the OpenAPI spec for this operation to add query
parameters pageSize (integer) and cursor (string) with style=form and
explode=true, then regenerate the client so the model is updated, and finally
add the corresponding fields to
V3ListPaymentServiceUserLinkAttemptsFromConnectorIDRequest (pageSize int32 and
cursor string) annotated as query params matching
style=form,explode=true,name=pageSize/name=cursor.
No description provided.