Remove accounts/{account_id} from all endpoints#29
Conversation
📝 WalkthroughWalkthroughThis PR removes the Changes
Sequence Diagram(s)(omitted — changes are spec/path renames without multi-component runtime control-flow) Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (8)
specs/contacts.openapi.yml (1)
81-219:⚠️ Potential issue | 🟠 MajorAlign SDK samples with accountless API endpoints.
The cURL samples now use
/api/contacts(accountless), but all SDK examples still requireaccount_id/accountIdparameters and account-scoped API calls across all languages (Node.js, PHP, Python, Ruby, .NET, Java). Update the SDK samples to use accountless endpoints, or add explicit notes that SDKs have not yet implemented accountless operations.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@specs/contacts.openapi.yml` around lines 81 - 219, SDK examples still call account-scoped endpoints while the cURL samples use the accountless /api/contacts; update the SDK snippets so they either call the accountless SDK methods or explicitly note accountless support is missing. Specifically, change usages like Node's MailtrapClient + client.contacts.create, Python's client.contacts_api.contacts.create (mt.CreateContactParams), PHP's MailtrapGeneralClient->contacts->createContact (CreateContact::init), Ruby's Mailtrap::ContactsAPI.new(account_id, ...) and contacts.create, .NET's Account(...).Contacts().Create (CreateContactRequest), and Java's client.contactsApi().contacts().createContact/CreateContactRequest to their accountless equivalents if the SDK supports them, or add a short comment in each language saying "Accountless endpoints not yet supported by SDK; use account-scoped calls or the /api/contacts HTTP endpoint" so the samples align with the new accountless API behavior.specs/sandbox.openapi.yml (2)
78-163:⚠️ Potential issue | 🟠 MajorAlign SDK samples with the accountless Sandbox API.
The cURL examples document
/api/inboxeswithout account path parameters, but all SDK samples (Node.js, PHP, Python, Ruby, .NET, Java) still require and useACCOUNT_ID,accountId, oraccount_idparameters with account-scoped SDK methods. Update all SDK code samples to use accountless endpoints, or add explicit comments documenting the SDK limitation and noting that samples will be updated once the Mailtrap SDKs support the accountless API.Per coding guidelines: "Use official Mailtrap SDKs for language-specific code examples in x-codeSamples; if SDK doesn't support a method, use GitBook generation or add a comment noting SDK limitations."
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@specs/sandbox.openapi.yml` around lines 78 - 163, The SDK samples wrongly pass ACCOUNT_ID to account-scoped methods while the cURL sandbox endpoints are accountless; for each sample (Node: client.testing.inboxes.getList, PHP: MailtrapSandboxClient->inboxes()->getList, Python: client.testing_api.inboxes.get_list, Ruby: Mailtrap::InboxesAPI.list, .NET: Account(...).Inboxes().GetAll, Java: client.testingApi().inboxes().getInboxes(accountId)) either remove the account argument and call the accountless SDK method if the language SDK now supports an accountless testing/inboxes call, or—if the SDK lacks accountless support—leave the existing call but add a brief inline comment stating “SDK does not yet support accountless Sandbox endpoints; sample uses account-scoped method as a temporary workaround” so docs match the cURL examples until SDKs are updated.
1930-1991:⚠️ Potential issue | 🟠 MajorUpdate response examples that still expose
/api/accounts/{account_id}paths.The documented endpoint paths are accountless (e.g.,
/api/inboxes/{inbox_id}/messages/{message_id}), but response examples still return account-scoped links like/api/accounts/16297/inboxes/.... These must be updated to match the endpoint definitions so generated docs don't contradict the API.Example update pattern
- html_path: /api/accounts/16297/inboxes/17002/messages/2323/body.html - txt_path: /api/accounts/16297/inboxes/17002/messages/2323/body.txt - raw_path: /api/accounts/16297/inboxes/17002/messages/2323/body.raw - download_path: /api/accounts/16297/inboxes/17002/messages/2323/body.eml - html_source_path: /api/accounts/16297/inboxes/17002/messages/2323/body.htmlsource + html_path: /api/inboxes/17002/messages/2323/body.html + txt_path: /api/inboxes/17002/messages/2323/body.txt + raw_path: /api/inboxes/17002/messages/2323/body.raw + download_path: /api/inboxes/17002/messages/2323/body.eml + html_source_path: /api/inboxes/17002/messages/2323/body.htmlsourceAlso applies to: 2094-2223, 2343-2448, 2555-2670, 4225-4307, 4389-4462
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@specs/sandbox.openapi.yml` around lines 1930 - 1991, The response example for the operation '/api/inboxes/{inbox_id}/messages/{message_id}' (and other similar ops listed) incorrectly includes account-scoped links like "/api/accounts/16297/..." — update the example values (html_path, txt_path, raw_path, download_path, html_source_path, etc.) to use accountless paths that match the documented endpoint (e.g. start with "/api/inboxes/{inbox_id}/messages/{message_id}/...") so examples align with the operation definition; apply the same change to the other affected blocks referenced (lines ~2094-2223, 2343-2448, 2555-2670, 4225-4307, 4389-4462) to ensure all returned link fields use the accountless URL pattern.specs/account-management.openapi.yml (3)
20-27:⚠️ Potential issue | 🟡 MinorRemove the stale “Account ID is required” guidance.
Line 23 still tells users Account Management endpoints require an Account ID, which directly contradicts the new account-less routes.
Suggested wording
- The Account ID is required when working with Account Management endpoints. + Account-scoped endpoints infer the account from the API token. - To find your Account ID, you can either: - - Use the endpoint below to list your accounts, or - - Find it in the UI under [Account Settings](https://mailtrap.io/account-management) + Use the endpoint below to list the accounts available to your API token.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@specs/account-management.openapi.yml` around lines 20 - 27, The description under the "Accounts" section (x-page-title: Accounts / name: Accounts) still says "The Account ID is required..." — remove that stale sentence and update the paragraph to reflect the new account-less routes: delete the line stating Account ID is required and replace it with a brief note that some Account Management endpoints no longer require an Account ID and direct users to list accounts or the UI for legacy flows; ensure the updated text keeps the existing links and the two bullets ("Use the endpoint below..." and "Find it in the UI...") intact and consistent with the new behavior.
191-260:⚠️ Potential issue | 🟠 MajorUpdate SDK examples to match account-less endpoint design, or add SDK limitation notes.
The cURL samples use token-scoped routes without
account_idin the path (e.g.,GET /api/account_accesses), but all SDK examples still requireaccount_idin constructors or method calls. Either update the SDK examples if the SDKs now support account-less calls, or add explicit comments noting that the SDKs currently requireaccount_iddespite the API being token-scoped. Per the coding guidelines, document SDK limitations when methods are not yet supported.Affected operations:
listAccountAccesses(lines 191–260),deleteAccountAccessById(lines 320–380),bulkUpdatePermissions(lines 431–524),getPermissionsResources(lines 609–660),getCurrentBillingUsage(lines 873–933).🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@specs/account-management.openapi.yml` around lines 191 - 260, The SDK examples for listAccountAccesses, deleteAccountAccessById, bulkUpdatePermissions, getPermissionsResources, and getCurrentBillingUsage still show passing account_id but the API now supports token-scoped (account-less) endpoints; update each code sample block: if the SDKs have been updated to support account-less calls, remove the accountId/constructor parameter and switch to the token-scoped method signatures (e.g., call listAccountAccesses() without accountId); otherwise, add a short explicit note/comment in each example stating "SDK currently requires account_id parameter; API supports token-scoped endpoints — update pending" so readers know this is an SDK limitation.
48-49:⚠️ Potential issue | 🟠 MajorDocument account selection mechanism for these endpoints or add explicit account_id parameter.
The OpenAPI curl examples for
/api/account_accesses,/api/permissions/resources, and/api/billing/usagedo not show how to specify which account, yet all SDK examples universally require anaccount_idparameter. This creates ambiguity:
- How do direct REST API users specify the account (header, query param, or derived from token)?
- For organization-level tokens with access to multiple accounts, what is the deterministic behavior—first account, error, or aggregated data?
Align the curl examples with the actual REST API behavior, or add an explicit account_id query or path parameter to the OpenAPI spec with documented behavior for organization-level tokens.
Also applies to: 173-179, 596-600, 860-864
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@specs/account-management.openapi.yml` around lines 48 - 49, Document or add an explicit account selection mechanism for the endpoints /api/account_accesses, /api/permissions/resources, and /api/billing/usage: either (A) update each operation to include an explicit account_id parameter (query or path) and describe its semantics for org-level tokens (e.g., required when token is org-scoped; behavior: selects that account, errors if unauthorized), or (B) update the endpoint descriptions to state exactly how the account is determined from the token (e.g., derived from token when token is account-scoped; behavior for org-scoped tokens: returns aggregated data / first account / error — pick and document one). Ensure the chosen approach is reflected in the example curl snippets and SDK notes for the same endpoints so REST and SDK usage are consistent.specs/email-sending.openapi.yml (1)
75-170:⚠️ Potential issue | 🟠 MajorAlign SDK examples with the account-less cURL endpoints or add SDK limitation notes.
The cURL sample calls the account-less endpoint (
POST https://mailtrap.io/api/sending_domains), but all SDK samples still require account IDs:YOUR_ACCOUNT_ID,MAILTRAP_ACCOUNT_ID,accountId,account_id, orclient.Account(...). Either update the SDK samples to use token-only authentication if the SDKs support it, or add explicit SDK limitation notes explaining why account IDs are still required. Per coding guidelines, "if SDK doesn't support a method, use GitBook generation or add a comment noting SDK limitations."Affects lines 75–170 and also: 217–306, 331–420, 447–532, 563–670, 724–851, 905–997, 1025–1033, 1069–1077, 1122–1130, 1174–1182, 1226–1234.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@specs/email-sending.openapi.yml` around lines 75 - 170, The SDK examples currently require account IDs but the cURL example uses the account-less endpoint; update each language example (e.g., Node: MailtrapClient + client.sendingDomains.create, PHP: MailtrapSendingClient->domains(), Python: MailtrapClient.sending_domains_api.sending_domains.create, Ruby: SendingDomainsAPI.new, C#: client.Account(...).SendingDomains(), Java: client.sendingApi().domains().create) to either use token-only calls if the respective SDK supports the account-less POST /sending_domains endpoint, or otherwise add a clear SDK limitation note beside each example stating "SDK does not support account-less endpoint; account ID required" and keep the existing code; ensure the note is present for all affected blocks referenced in the review.specs/templates.openapi.yml (1)
44-109:⚠️ Potential issue | 🟠 MajorUpdate SDK code examples to match token-only cURL patterns or add SDK limitation notes.
The cURL examples use token-only authentication (e.g.,
curl ... -H "Api-Token: YOUR_API_KEY"), but most SDK samples still requireaccountId,account_id, or account-scoped constructors. This mismatch is systematic: 4 of 5 operations show the inconsistency (only thecreateEmailTemplateoperation's Node.js example uses token-only). Additionally, thecreateEmailTemplateoperation reveals incomplete migration—Node.js was updated to token-only, but PHP, Python, Ruby, .NET, and Java examples still require account parameters.Either:
- Update all SDK examples to remove account ID parameters (matching cURL), if the SDKs now support token-only operations, or
- Add explicit notes (per coding guidelines) documenting that current Mailtrap SDKs still require account IDs until they are updated to support token-only authentication.
Affects lines: 44–109, 145–248, 281–333, 366–435, 468–519
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@specs/templates.openapi.yml` around lines 44 - 109, The SDK examples in the email templates snippets still show account-scoped constructors/params (e.g., Node.js MailtrapClient({ token: "...", accountId: ... }), PHP MailtrapGeneralClient->emailTemplates($accountId), Python MailtrapClient(token=..., account_id=...), Ruby Mailtrap::EmailTemplatesAPI.new(YOUR_ACCOUNT_ID,...), C# client.Account(YOUR_ACCOUNT_ID).EmailTemplates(), and Java getAllTemplates(accountId)) which conflicts with the cURL token-only pattern; update each example to either (A) remove the accountId/account_id/account parameter so the snippet uses token-only auth consistently across Node.js, PHP, Python, Ruby, .NET, and Java, or (B) add a short explicit note next to each SDK example (per coding guidelines) stating that the current SDK requires an account ID and that token-only support is pending—apply the chosen approach for all affected snippets to keep examples consistent.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Outside diff comments:
In `@specs/account-management.openapi.yml`:
- Around line 20-27: The description under the "Accounts" section (x-page-title:
Accounts / name: Accounts) still says "The Account ID is required..." — remove
that stale sentence and update the paragraph to reflect the new account-less
routes: delete the line stating Account ID is required and replace it with a
brief note that some Account Management endpoints no longer require an Account
ID and direct users to list accounts or the UI for legacy flows; ensure the
updated text keeps the existing links and the two bullets ("Use the endpoint
below..." and "Find it in the UI...") intact and consistent with the new
behavior.
- Around line 191-260: The SDK examples for listAccountAccesses,
deleteAccountAccessById, bulkUpdatePermissions, getPermissionsResources, and
getCurrentBillingUsage still show passing account_id but the API now supports
token-scoped (account-less) endpoints; update each code sample block: if the
SDKs have been updated to support account-less calls, remove the
accountId/constructor parameter and switch to the token-scoped method signatures
(e.g., call listAccountAccesses() without accountId); otherwise, add a short
explicit note/comment in each example stating "SDK currently requires account_id
parameter; API supports token-scoped endpoints — update pending" so readers know
this is an SDK limitation.
- Around line 48-49: Document or add an explicit account selection mechanism for
the endpoints /api/account_accesses, /api/permissions/resources, and
/api/billing/usage: either (A) update each operation to include an explicit
account_id parameter (query or path) and describe its semantics for org-level
tokens (e.g., required when token is org-scoped; behavior: selects that account,
errors if unauthorized), or (B) update the endpoint descriptions to state
exactly how the account is determined from the token (e.g., derived from token
when token is account-scoped; behavior for org-scoped tokens: returns aggregated
data / first account / error — pick and document one). Ensure the chosen
approach is reflected in the example curl snippets and SDK notes for the same
endpoints so REST and SDK usage are consistent.
In `@specs/contacts.openapi.yml`:
- Around line 81-219: SDK examples still call account-scoped endpoints while the
cURL samples use the accountless /api/contacts; update the SDK snippets so they
either call the accountless SDK methods or explicitly note accountless support
is missing. Specifically, change usages like Node's MailtrapClient +
client.contacts.create, Python's client.contacts_api.contacts.create
(mt.CreateContactParams), PHP's MailtrapGeneralClient->contacts->createContact
(CreateContact::init), Ruby's Mailtrap::ContactsAPI.new(account_id, ...) and
contacts.create, .NET's Account(...).Contacts().Create (CreateContactRequest),
and Java's client.contactsApi().contacts().createContact/CreateContactRequest to
their accountless equivalents if the SDK supports them, or add a short comment
in each language saying "Accountless endpoints not yet supported by SDK; use
account-scoped calls or the /api/contacts HTTP endpoint" so the samples align
with the new accountless API behavior.
In `@specs/email-sending.openapi.yml`:
- Around line 75-170: The SDK examples currently require account IDs but the
cURL example uses the account-less endpoint; update each language example (e.g.,
Node: MailtrapClient + client.sendingDomains.create, PHP:
MailtrapSendingClient->domains(), Python:
MailtrapClient.sending_domains_api.sending_domains.create, Ruby:
SendingDomainsAPI.new, C#: client.Account(...).SendingDomains(), Java:
client.sendingApi().domains().create) to either use token-only calls if the
respective SDK supports the account-less POST /sending_domains endpoint, or
otherwise add a clear SDK limitation note beside each example stating "SDK does
not support account-less endpoint; account ID required" and keep the existing
code; ensure the note is present for all affected blocks referenced in the
review.
In `@specs/sandbox.openapi.yml`:
- Around line 78-163: The SDK samples wrongly pass ACCOUNT_ID to account-scoped
methods while the cURL sandbox endpoints are accountless; for each sample (Node:
client.testing.inboxes.getList, PHP: MailtrapSandboxClient->inboxes()->getList,
Python: client.testing_api.inboxes.get_list, Ruby: Mailtrap::InboxesAPI.list,
.NET: Account(...).Inboxes().GetAll, Java:
client.testingApi().inboxes().getInboxes(accountId)) either remove the account
argument and call the accountless SDK method if the language SDK now supports an
accountless testing/inboxes call, or—if the SDK lacks accountless support—leave
the existing call but add a brief inline comment stating “SDK does not yet
support accountless Sandbox endpoints; sample uses account-scoped method as a
temporary workaround” so docs match the cURL examples until SDKs are updated.
- Around line 1930-1991: The response example for the operation
'/api/inboxes/{inbox_id}/messages/{message_id}' (and other similar ops listed)
incorrectly includes account-scoped links like "/api/accounts/16297/..." —
update the example values (html_path, txt_path, raw_path, download_path,
html_source_path, etc.) to use accountless paths that match the documented
endpoint (e.g. start with "/api/inboxes/{inbox_id}/messages/{message_id}/...")
so examples align with the operation definition; apply the same change to the
other affected blocks referenced (lines ~2094-2223, 2343-2448, 2555-2670,
4225-4307, 4389-4462) to ensure all returned link fields use the accountless URL
pattern.
In `@specs/templates.openapi.yml`:
- Around line 44-109: The SDK examples in the email templates snippets still
show account-scoped constructors/params (e.g., Node.js MailtrapClient({ token:
"...", accountId: ... }), PHP MailtrapGeneralClient->emailTemplates($accountId),
Python MailtrapClient(token=..., account_id=...), Ruby
Mailtrap::EmailTemplatesAPI.new(YOUR_ACCOUNT_ID,...), C#
client.Account(YOUR_ACCOUNT_ID).EmailTemplates(), and Java
getAllTemplates(accountId)) which conflicts with the cURL token-only pattern;
update each example to either (A) remove the accountId/account_id/account
parameter so the snippet uses token-only auth consistently across Node.js, PHP,
Python, Ruby, .NET, and Java, or (B) add a short explicit note next to each SDK
example (per coding guidelines) stating that the current SDK requires an account
ID and that token-only support is pending—apply the chosen approach for all
affected snippets to keep examples consistent.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: be358c66-b7c2-410d-b8ea-e49ca3b5f15d
📒 Files selected for processing (5)
specs/account-management.openapi.ymlspecs/contacts.openapi.ymlspecs/email-sending.openapi.ymlspecs/sandbox.openapi.ymlspecs/templates.openapi.yml
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
specs/account-management.openapi.yml (1)
167-927:⚠️ Potential issue | 🟠 MajorSDK code samples are inconsistent with the updated cURL paths—spec change is ahead of SDK updates.
The cURL examples correctly use the new paths without
account_id(e.g.,https://mailtrap.io/api/account_accesses), but the Node.js, PHP, Python, Ruby, .NET (C#), and Java samples still require and passaccountIdto the client/SDK methods. As of 2026, the Mailtrap SDKs have not removed theaccountIdparameter from these operations—they still require it and target the original account-scoped paths.This creates a broken state:
- cURL users will call
/api/account_accesses(new path without account_id)- SDK users will still call paths that require account_id (old paths like
/api/accounts/{account_id}/account_accesses)Either revert the OpenAPI path changes to maintain consistency with the current SDKs, or wait until all six SDKs have been updated to match the new paths before merging this spec change. Verify SDK updates are complete before publishing these documentation changes to avoid broken examples.
Affected across all five operations:
/api/account_accessesGET/api/account_accesses/{account_access_id}DELETE/api/account_accesses/{account_access_id}/permissions/bulkPUT/api/permissions/resourcesGET/api/billing/usageGET🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@specs/account-management.openapi.yml` around lines 167 - 927, The SDK examples are inconsistent with the new top-level paths: cURL samples use the new account-less endpoints while SDK samples still pass accountId and target old account-scoped routes; fix by either reverting the path changes in the spec or updating all SDK code samples to call the new endpoints (remove accountId parameter usage) for the affected operationIds getAllUsersInAccount, deleteAccountAccessById, updateUserPermissions, getResources, and getAccountBillingUsage; ensure the Node.js/PHP/Python/Ruby/C#/Java snippets are edited to construct the client and call methods without accountId (or add a comment that SDKs must be updated), and do not merge until the six SDKs actually drop the accountId parameter and are verified.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Outside diff comments:
In `@specs/account-management.openapi.yml`:
- Around line 167-927: The SDK examples are inconsistent with the new top-level
paths: cURL samples use the new account-less endpoints while SDK samples still
pass accountId and target old account-scoped routes; fix by either reverting the
path changes in the spec or updating all SDK code samples to call the new
endpoints (remove accountId parameter usage) for the affected operationIds
getAllUsersInAccount, deleteAccountAccessById, updateUserPermissions,
getResources, and getAccountBillingUsage; ensure the
Node.js/PHP/Python/Ruby/C#/Java snippets are edited to construct the client and
call methods without accountId (or add a comment that SDKs must be updated), and
do not merge until the six SDKs actually drop the accountId parameter and are
verified.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: ce538978-8d19-475b-a6a3-2e89100296ba
📒 Files selected for processing (1)
specs/account-management.openapi.yml
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (3)
specs/sandbox.openapi.yml (2)
1930-1991:⚠️ Potential issue | 🟠 MajorThe message and attachment payload examples still point at removed
/api/accounts/...routes.These sections now document account-less endpoints, but their example payloads still return
html_path,txt_path,raw_path,download_path, and attachmentdownload_pathvalues under/api/accounts/{account_id}/.... After this PR, those example URLs become broken and contradict the new contract.Representative fix
- html_path: /api/accounts/16297/inboxes/17002/messages/2323/body.html - txt_path: /api/accounts/16297/inboxes/17002/messages/2323/body.txt - raw_path: /api/accounts/16297/inboxes/17002/messages/2323/body.raw - download_path: /api/accounts/16297/inboxes/17002/messages/2323/body.eml + html_path: /api/inboxes/17002/messages/2323/body.html + txt_path: /api/inboxes/17002/messages/2323/body.txt + raw_path: /api/inboxes/17002/messages/2323/body.raw + download_path: /api/inboxes/17002/messages/2323/body.emlAlso applies to: 2555-2670, 4225-4462
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@specs/sandbox.openapi.yml` around lines 1930 - 1991, The example response for the '/api/inboxes/{inbox_id}/messages/{message_id}' endpoint (and the similar blocks at the other ranges) still contains old account-scoped URLs; update the example values for html_path, txt_path, raw_path, download_path, html_source_path and any attachment download_path to use the new inbox-scoped routes (e.g. /api/inboxes/{inbox_id}/messages/{message_id}/...) or appropriate parameter placeholders ({inbox_id}, {message_id}) instead of /api/accounts/{account_id}/..., ensuring the example matches the documented path and do the same fix in the other two example sections referenced.
72-163:⚠️ Potential issue | 🟠 MajorAdd explicit notes to SDK samples indicating that the official SDKs still require
accountId/account_iddespite the REST paths now being token-scoped.The cURL endpoint has been updated to token-scoped (
/api/inboxes), but the Node.js, PHP, Python, Ruby, .NET, and Java SDK samples still showaccountId/account_idparameters because the current official SDKs have not yet been updated to support token-scoped sandbox operations. This mismatch will cause documentation inconsistency for users.Until the SDKs are updated to match the new REST API structure, add an inline comment to each SDK code sample (e.g.,
// Note: accountId is still required by the SDK) or note the SDK limitation in the operation description. This pattern repeats across all updated sandbox operations (inboxes, projects, messages, attachments).🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@specs/sandbox.openapi.yml` around lines 72 - 163, The SDK examples are inconsistent with the token-scoped cURL path because the official SDKs still require an accountId/account_id; update each SDK snippet (Node: MailtrapClient({ token: TOKEN, accountId: ACCOUNT_ID }) / client.testing.inboxes.getList, PHP: MailtrapSandboxClient->inboxes($accountId)->getList, Python: MailtrapClient(token=..., account_id=...) / client.testing_api.inboxes.get_list, Ruby: Mailtrap::Client.new(...) / Mailtrap::InboxesAPI.new(YOUR_ACCOUNT_ID,...), C#: mailtrapFactory.CreateClient().Account(YOUR_ACCOUNT_ID).Inboxes().GetAll(), Java: MailtrapClientFactory.createMailtrapClient(config).testingApi().inboxes().getInboxes(accountId)) to include a short inline note/comment stating that accountId/account_id is still required by the current SDKs (or add the same note in the operation description) until SDKs are updated to support token-scoped sandbox operations.specs/email-sending.openapi.yml (1)
63-172:⚠️ Potential issue | 🟠 MajorAdd comments to SDK samples clarifying that accountId is still required, or update the cURL URL to match.
The cURL sample uses a token-scoped endpoint (
https://mailtrap.io/api/sending_domains), but all SDK samples (Node.js, PHP, Python, Ruby, .NET, Java) still requireaccountId/account_id/YOUR_ACCOUNT_ID. The Mailtrap SDKs have not been updated to remove this requirement—they continue to use account-scoped endpoints. Either add an explicit comment above these SDK samples noting that SDKs still require the account ID parameter, or revert the cURL URL if the API contract still uses account-scoped routes. This same inconsistency repeats across the other changed operations in this file.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@specs/email-sending.openapi.yml` around lines 63 - 172, The SDK examples (MailtrapClient constructors and calls like client.sending_domains.create, MailtrapSendingClient->domains($accountId), SendingDomainsAPI/YOUR_ACCOUNT_ID, client.Account(...).SendingDomains(), client.sendingApi().domains().create(YOUR_ACCOUNT_ID, ...)) require an accountId but the cURL sample uses a token-scoped URL; fix by either updating the cURL URL to the account-scoped route used by the SDKs or add a one-line clarifying comment above each SDK sample stating "Note: these SDK examples require YOUR_ACCOUNT_ID/account_id and use account-scoped endpoints" so the examples are consistent; apply the same change to all similar operations in this file.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Outside diff comments:
In `@specs/email-sending.openapi.yml`:
- Around line 63-172: The SDK examples (MailtrapClient constructors and calls
like client.sending_domains.create, MailtrapSendingClient->domains($accountId),
SendingDomainsAPI/YOUR_ACCOUNT_ID, client.Account(...).SendingDomains(),
client.sendingApi().domains().create(YOUR_ACCOUNT_ID, ...)) require an accountId
but the cURL sample uses a token-scoped URL; fix by either updating the cURL URL
to the account-scoped route used by the SDKs or add a one-line clarifying
comment above each SDK sample stating "Note: these SDK examples require
YOUR_ACCOUNT_ID/account_id and use account-scoped endpoints" so the examples are
consistent; apply the same change to all similar operations in this file.
In `@specs/sandbox.openapi.yml`:
- Around line 1930-1991: The example response for the
'/api/inboxes/{inbox_id}/messages/{message_id}' endpoint (and the similar blocks
at the other ranges) still contains old account-scoped URLs; update the example
values for html_path, txt_path, raw_path, download_path, html_source_path and
any attachment download_path to use the new inbox-scoped routes (e.g.
/api/inboxes/{inbox_id}/messages/{message_id}/...) or appropriate parameter
placeholders ({inbox_id}, {message_id}) instead of
/api/accounts/{account_id}/..., ensuring the example matches the documented path
and do the same fix in the other two example sections referenced.
- Around line 72-163: The SDK examples are inconsistent with the token-scoped
cURL path because the official SDKs still require an accountId/account_id;
update each SDK snippet (Node: MailtrapClient({ token: TOKEN, accountId:
ACCOUNT_ID }) / client.testing.inboxes.getList, PHP:
MailtrapSandboxClient->inboxes($accountId)->getList, Python:
MailtrapClient(token=..., account_id=...) / client.testing_api.inboxes.get_list,
Ruby: Mailtrap::Client.new(...) / Mailtrap::InboxesAPI.new(YOUR_ACCOUNT_ID,...),
C#: mailtrapFactory.CreateClient().Account(YOUR_ACCOUNT_ID).Inboxes().GetAll(),
Java:
MailtrapClientFactory.createMailtrapClient(config).testingApi().inboxes().getInboxes(accountId))
to include a short inline note/comment stating that accountId/account_id is
still required by the current SDKs (or add the same note in the operation
description) until SDKs are updated to support token-scoped sandbox operations.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 47e123b5-dff9-4538-be0a-4b3b4f85d038
📒 Files selected for processing (2)
specs/email-sending.openapi.ymlspecs/sandbox.openapi.yml
4 participants
Motivation
There is no need to pass account_id. It can be extracted from the Api Token. API endpoints could be simplified.
Changes
accounts/{account_id}from endpointsHow to test
Summary by CodeRabbit