Adopt Intercom API 2.16 - #73
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c51bf713b9
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| } | ||
|
|
||
| // SearchActivityLogs searches admin activity logs. | ||
| func (s *AdminsService) SearchActivityLogs(ctx context.Context, params *gen.SearchActivityLogsParams, request gen.SearchActivityLogsJSONRequestBody) (*gen.SearchActivityLogsResponse, error) { |
There was a problem hiding this comment.
For downstream module users, SearchActivityLogs cannot be called normally because both its request parameters are types from internal/generated/intercom, which Go's internal-package rule prevents consumers from importing or constructing directly. The same leak affects the newly added conversation, ticket, Fin, team, WhatsApp, and other wrappers; expose root-package aliases or hand-shaped SDK types instead so these operations form a usable public API.
AGENTS.md reference: AGENTS.md:L24-L26
Useful? React with 👍 / 👎.
| func (s *AdminsService) ListActivityLogEventTypes(ctx context.Context, params *gen.ListActivityLogEventTypesParams) (*gen.ListActivityLogEventTypesResponse, error) { | ||
| return s.client.generated.ListActivityLogEventTypesWithResponse(ctx, params) |
There was a problem hiding this comment.
When Intercom returns a valid 401, 429, or 5xx response, ListActivityLogEventTypesWithResponse returns the generated response with a nil Go error, so this public method also reports nil error instead of applying the SDK's normal error mapping. This forwarding pattern is repeated across several newly added methods; parse the success payload and pass non-success statuses through parseErrorResponse/the response helpers rather than exposing the generated response directly.
AGENTS.md reference: AGENTS.md:L24-L26
Useful? React with 👍 / 👎.
| } | ||
| params := &gen.GetCustomObjectInstancesByExternalIdParams{ExternalId: externalID} | ||
| res, err := s.client.generated.GetCustomObjectInstancesByExternalIdWithResponse(ctx, customObjectType, params) | ||
| res, err := s.client.generated.GetCustomObjectInstancesByIdWithResponse(ctx, customObjectType, externalID, nil) |
There was a problem hiding this comment.
When an external ID differs from the Intercom-assigned instance ID, this now sends it to the by-ID route (/custom_object_instances/{type}/{id}), whose operation is explicitly defined as fetching by ID in spec/intercom.openapi.yaml:14576-14577. Existing GetByExternalID callers will therefore receive a 404 or potentially retrieve an unrelated instance instead of querying by external_id; retain an external-ID lookup request independently of the removed generated helper.
Useful? React with 👍 / 👎.
1 participant
Summary
Adopts Intercom API 2.16 and regenerates the pinned OpenAPI client.
Validation
make pre-pushgo vet ./...make generate-checkv0.2.0govulncheck(no vulnerabilities found)go test ./...go test -run TestGeneratedOperationsAreAccountedFor .