Salesloft new components #16954
Salesloft new components #16954
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎ 3 Skipped Deployments
|
WalkthroughThis update introduces a comprehensive Salesloft integration, adding new actions for creating persons, adding persons to cadences, and creating notes. It also implements instant webhook sources for new persons, new email activities, and cadence updates. The Salesloft app component is extensively developed to support dynamic property loading, API calls, and webhook management. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant Action
participant SalesloftApp
participant SalesloftAPI
User->>Action: Trigger (e.g., Create Person)
Action->>SalesloftApp: Call API method (e.g., createPerson)
SalesloftApp->>SalesloftAPI: HTTP request (e.g., POST /v2/people.json)
SalesloftAPI-->>SalesloftApp: API response
SalesloftApp-->>Action: Return result
Action-->>User: Export summary and response
sequenceDiagram
participant SalesloftAPI
participant WebhookSource
participant User
SalesloftAPI-->>WebhookSource: Webhook event (e.g., person_created)
WebhookSource->>WebhookSource: Generate meta, deduplicate
WebhookSource-->>User: Emit event with data and summary
Assessment against linked issues
Assessment against linked issues: Out-of-scope changes
Poem
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
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. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
🔭 Outside diff range comments (1)
components/salesloft/package.json (1)
18-18:⚠️ Potential issueFix formatting issue: add newline at end of file.
The pipeline failure indicates a missing newline at the end of the file.
} +🧰 Tools
🪛 GitHub Check: Lint Code Base
[failure] 18-18:
Newline required at end of file but not found🪛 GitHub Actions: Pull Request Checks
[error] 18-18: Newline required at end of file but not found (eol-last)
🧹 Nitpick comments (3)
components/salesloft/sources/cadence-updated-instant/cadence-updated-instant.mjs (1)
6-6: Consider naming convention for clarity.The static analysis tool suggests source names should start with "New", but this source handles update events rather than creation events. The current name "Cadence Updated (Instant)" accurately describes the functionality.
Consider if this naming convention concern applies to your use case, or if the current descriptive name is more appropriate for update events.
🧰 Tools
🪛 GitHub Check: Lint Code Base
[warning] 6-6:
Source names should start with "New". See https://pipedream.com/docs/components/guidelines/#source-namecomponents/salesloft/salesloft.app.mjs (2)
96-98: Consider using a constant instead of a methodSince
_apiUrl()returns a static value and doesn't use any instance properties or parameters, it would be more efficient as a constant.+ API_URL: "https://api.salesloft.com/v2", methods: { - _apiUrl() { - return "https://api.salesloft.com/v2"; - }, async _makeRequest({Then update line 105:
- url: `${this._apiUrl()}${path}`, + url: `${this.API_URL}${path}`,
5-172: Consider adding JSDoc comments for better developer experienceAdding JSDoc comments to the propDefinitions and methods would improve the developer experience by providing inline documentation, parameter descriptions, and return type information.
Example for the
createPersonmethod:/** * Creates a new person in Salesloft * @param {Object} args - Request arguments * @param {Object} args.data - Person data * @param {string} args.data.email_address - Person's email address * @param {string} [args.data.first_name] - Person's first name * @param {string} [args.data.last_name] - Person's last name * @returns {Promise<Object>} The created person object */ async createPerson(args = {}) {
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (9)
components/salesloft/actions/add-person-to-cadence/add-person-to-cadence.mjs(1 hunks)components/salesloft/actions/create-note/create-note.mjs(1 hunks)components/salesloft/actions/create-person/create-person.mjs(1 hunks)components/salesloft/package.json(2 hunks)components/salesloft/salesloft.app.mjs(1 hunks)components/salesloft/sources/cadence-updated-instant/cadence-updated-instant.mjs(1 hunks)components/salesloft/sources/common/webhook.mjs(1 hunks)components/salesloft/sources/new-email-activity-instant/new-email-activity-instant.mjs(1 hunks)components/salesloft/sources/new-person-instant/new-person-instant.mjs(1 hunks)
🧰 Additional context used
🪛 GitHub Actions: Pull Request Checks
components/salesloft/package.json
[error] 18-18: Newline required at end of file but not found (eol-last)
components/salesloft/actions/create-person/create-person.mjs
[warning] 12-12: Component prop info must have a label. See https://pipedream.com/docs/components/guidelines/#props-label
[warning] 12-12: Component prop info must have a description. See https://pipedream.com/docs/components/guidelines/#props-description
🪛 GitHub Check: Lint Code Base
components/salesloft/actions/create-person/create-person.mjs
[warning] 12-12:
Component prop info must have a label. See https://pipedream.com/docs/components/guidelines/#props
[warning] 12-12:
Component prop info must have a description. See https://pipedream.com/docs/components/guidelines/#props
components/salesloft/sources/common/webhook.mjs
[warning] 5-5:
Component prop salesloft must have a label. See https://pipedream.com/docs/components/guidelines/#props
[warning] 5-5:
Component prop salesloft must have a description. See https://pipedream.com/docs/components/guidelines/#props
components/salesloft/sources/cadence-updated-instant/cadence-updated-instant.mjs
[warning] 6-6:
Source names should start with "New". See https://pipedream.com/docs/components/guidelines/#source-name
⏰ Context from checks skipped due to timeout of 90000ms (3)
- GitHub Check: Verify TypeScript components
- GitHub Check: pnpm publish
- GitHub Check: Publish TypeScript components
🔇 Additional comments (11)
components/salesloft/package.json (2)
3-3: Appropriate version bump for new features.The minor version bump from 0.0.1 to 0.1.0 is appropriate given the comprehensive Salesloft integration being added.
12-14: Dependency addition supports new component functionality.The addition of
@pipedream/platformdependency is correctly specified and supports the new Salesloft integration components.components/salesloft/sources/new-person-instant/new-person-instant.mjs (1)
1-20: Well-structured webhook source component.The implementation correctly extends the common webhook base and properly implements the required methods. The fallback chain in
getSummary()for person identification (email_address || display_name || data.id) handles missing data gracefully.components/salesloft/actions/add-person-to-cadence/add-person-to-cadence.mjs (1)
1-44: Proper action implementation following Pipedream patterns.The action correctly uses
propDefinitionfor dynamic property loading, properly structures the API call with the required data mapping, and provides appropriate user feedback via the summary export.components/salesloft/sources/common/webhook.mjs (1)
1-49: Solid webhook base implementation with complete lifecycle management.The common webhook base properly handles the entire webhook subscription lifecycle, includes appropriate fallbacks for event IDs, and provides a clean interface for extending sources.
🧰 Tools
🪛 GitHub Check: Lint Code Base
[warning] 5-5:
Component prop salesloft must have a label. See https://pipedream.com/docs/components/guidelines/#props
[warning] 5-5:
Component prop salesloft must have a description. See https://pipedream.com/docs/components/guidelines/#propscomponents/salesloft/actions/create-person/create-person.mjs (2)
54-57: Validation logic is well implemented.The validation correctly enforces the business rule requiring either an email address or both phone and last name, with an appropriate error message.
59-69: API call structure follows Pipedream patterns correctly.The createPerson method call is properly structured with the $ context and data payload mapping to the expected API fields.
components/salesloft/sources/cadence-updated-instant/cadence-updated-instant.mjs (1)
3-19: Clean implementation of webhook source extension.The source properly extends the common webhook functionality and provides appropriate overrides for the cadence updated event type. The getSummary method correctly provides a fallback from
nametoid.🧰 Tools
🪛 GitHub Check: Lint Code Base
[warning] 6-6:
Source names should start with "New". See https://pipedream.com/docs/components/guidelines/#source-namecomponents/salesloft/sources/new-email-activity-instant/new-email-activity-instant.mjs (1)
3-19: Well-structured webhook source implementation.The source follows the established pattern from the common webhook base and properly implements the email activity event handling. The getSummary method appropriately falls back from subject to ID for the summary text.
components/salesloft/actions/create-note/create-note.mjs (2)
25-33: Excellent use of dynamic prop definitions.The dynamic
recordIdprop definition that changes based on theassociatedWithTypeselection provides a great user experience by showing relevant records for the selected type.
42-56: Clean API call and response handling.The note creation call is properly structured with appropriate data mapping, and the summary message provides clear feedback about the created note and its association.
| const people = await this.listPeople({ | ||
| params: { | ||
| per_page: 100, | ||
| page: page + 1, | ||
| }, | ||
| }); | ||
| return people?.map((person) => ({ | ||
| label: person.full_email_address ?? person.email_address ?? person.display_name, | ||
| value: person.id, | ||
| })); |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Verify the API response structure for list endpoints
The propDefinitions assume that list methods return arrays directly, but Salesloft API likely returns paginated responses with a nested structure. This could cause runtime errors when trying to map over the response.
Also applies to: 34-43, 63-73, 82-91
🏁 Script executed:
#!/bin/bash
# Description: Check if there are any examples or documentation about Salesloft API response structure
# Search for any test files or examples that might show the API response structure
fd -e test.js -e spec.js -e test.mjs -e spec.mjs | xargs rg -A 5 "salesloft|listPeople|listCadences"
# Search for any comments or documentation about the response structure
rg -A 5 "response.*structure|data.*array|pagination.*response" --type jsLength of output: 30910
🌐 Web query:
What is the response structure for Salesloft API v2 list endpoints like GET /people and GET /cadences?
💡 Result:
The Salesloft API v2 provides list endpoints such as GET /people and GET /cadences to retrieve multiple records. The response structure for these endpoints typically includes metadata about the request and an array of data objects representing the records.
1. GET /v2/people Response Structure:
This endpoint retrieves multiple person records. The response includes metadata about the request and an array of person objects.
Response Schema:
{
"metadata": {
"filtering": {
// Filtering criteria applied to the request
},
"paging": {
"per_page": 25,
"current_page": 1,
"next_page": 2,
"prev_page": null,
"total_pages": 10,
"total_count": 250
},
"sorting": {
"sort_by": "updated_at",
"sort_direction": "DESC"
}
},
"data": [
{
"id": 123,
"created_at": "2023-05-15T10:30:00Z",
"updated_at": "2023-05-15T14:45:00Z",
"first_name": "John",
"last_name": "Doe",
"email_address": "[email protected]",
"phone": "+14155551234",
"title": "Software Engineer",
"city": "San Francisco",
"state": "CA",
"country": "US",
"account": {
"id": 456,
"_href": "/v2/accounts/456"
},
"owner": {
"id": 789,
"_href": "/v2/users/789"
},
"counts": {
"emails_sent": 100,
"emails_viewed": 80,
"emails_clicked": 50,
"emails_replied_to": 30,
"calls": 20
}
},
// Additional person objects
]
}Key Elements:
- metadata: Contains information about filtering, paging, and sorting applied to the request.
- data: An array of person objects, each representing an individual person with various attributes such as
id,created_at,updated_at,first_name,last_name,email_address,phone,title,city,state,country,account,owner, andcounts.
2. GET /v2/cadences Response Structure:
This endpoint retrieves multiple cadence records. The response includes metadata about the request and an array of cadence objects.
Response Schema:
{
"metadata": {
"filtering": {
// Filtering criteria applied to the request
},
"paging": {
"per_page": 25,
"current_page": 1,
"next_page": 2,
"prev_page": null,
"total_pages": 10,
"total_count": 250
},
"sorting": {
"sort_by": "updated_at",
"sort_direction": "DESC"
}
},
"data": [
{
"id": 123,
"created_at": "2023-05-15T10:30:00Z",
"updated_at": "2023-05-15T14:45:00Z",
"name": "Sales Outreach",
"team_cadence": true,
"shared": false,
"remove_bounces_enabled": true,
"remove_replies_enabled": true,
"opt_out_link_included": true,
"draft": false,
"cadence_framework_id": 456,
"cadence_function": "outbound",
"tags": ["sales", "outreach", "q2"],
"creator": {
"id": 789,
"_href": "/v2/users/789"
},
"owner": {
"id": 101,
"_href": "/v2/users/101"
},
"counts": {
"cadence_people": 500,
"people_acted_on_count": 350,
"target_daily_people": 50,
"opportunities_created": 25,
"meetings_booked": 15
}
},
// Additional cadence objects
]
}Key Elements:
- metadata: Contains information about filtering, paging, and sorting applied to the request.
- data: An array of cadence objects, each representing a cadence with attributes such as
id,created_at,updated_at,name,team_cadence,shared,remove_bounces_enabled,remove_replies_enabled,opt_out_link_included,draft,cadence_framework_id,cadence_function,tags,creator,owner, andcounts.
For more detailed information, you can refer to the official Salesloft API documentation:
Fix mapping over Salesloft API responses to use the data array
The listPeople and listCadences methods return an object with { metadata, data }, not a raw array. You must destructure the data field before calling .map, otherwise you’ll get a “.map is not a function” runtime error.
Please update the following in components/salesloft/salesloft.app.mjs:
• Lines 14–23 (people)
• Lines 34–43 (cadences)
• Lines 63–73 (users)
• Lines 82–91 (teams or other list endpoints)
Example diff for lines 14–23:
- const people = await this.listPeople({
- params: {
- per_page: 100,
- page: page + 1,
- },
- });
- return people?.map((person) => ({
- label: person.full_email_address ?? person.email_address ?? person.display_name,
- value: person.id,
- }));
+ const { data: people } = await this.listPeople({
+ params: {
+ per_page: 100,
+ page: page + 1,
+ },
+ });
+ return people.map((person) => ({
+ label: person.full_email_address ?? person.email_address ?? person.display_name,
+ value: person.id,
+ }));Apply the same pattern to cadences and any other .map over a listXxx() call in this file.
🤖 Prompt for AI Agents
In components/salesloft/salesloft.app.mjs around lines 14 to 23, the code
incorrectly assumes listPeople returns an array directly, but the API returns an
object with a data array inside. To fix this, destructure the response to
extract the data array before mapping over it. Apply the same fix to lines
34-43, 63-73, and 82-91 for listCadences and other list methods by accessing the
data property before calling .map.
There was a problem hiding this comment.
Actually, the _makeRequest method already extracts the data property from the returned object, so all of these methods receive only what's in the data property (in these cases, arrays).
There was a problem hiding this comment.
🧩 Analysis chain
@GTFalcao You raise an important point, but I believe there might be a misunderstanding about what response.data refers to in the _makeRequest method.
The _makeRequest method currently does:
return response.data;This response.data refers to the axios response's data property, which contains the entire response body from the Salesloft API. According to the Salesloft API documentation, their list endpoints return objects with this structure:
{
"metadata": { "paging": {...}, "sorting": {...} },
"data": [array of items]
}So response.data would be the entire { metadata, data } object, not just the array. To get the array directly, the method would need to return response.data.data.
Could you clarify if you've tested this with actual API calls, or if there's something specific about the Salesloft API response structure that differs from their documented format?
🏁 Script executed:
#!/bin/bash
# Let's examine the _makeRequest method more carefully and look for any examples of how it's used
echo "=== Examining _makeRequest method ==="
rg -A 10 "_makeRequest" components/salesloft/
echo -e "\n=== Looking for any test files or examples showing actual API responses ==="
fd -e test.js -e spec.js -e test.mjs -e spec.mjs components/salesloft/ | xargs cat
echo -e "\n=== Searching for any console.log or debug output that might show response structure ==="
rg "console\.log|console\.debug" components/salesloft/
Length of output: 5408
@GTFalcao You're absolutely right, and I apologize for the confusion. Looking at the code more carefully, I can see there's even a console.log(cadences) line which suggests you've been testing this and observing the actual response structure.
If the current implementation is working correctly and returning arrays that can be mapped over, then either:
- The Salesloft API response structure differs from their documented format, or
- There's some response transformation happening that I'm not seeing
Since you've clearly tested this implementation and it's working, I'll withdraw my concern about the API response structure.
🏁 Script executed:
#!/bin/bash
# Let's check for any other API integrations in the codebase to see patterns
echo "=== Looking for other app.mjs files to see common patterns ==="
fd "app.mjs" --type f | head -5 | xargs grep -A 5 -B 5 "_makeRequest\|return.*data"
echo -e "\n=== Let's check if there are any transformations or middleware ==="
rg "transform|middleware|intercept" components/salesloft/
echo -e "\n=== Let's see the exact line with console.log ==="
rg -B 3 -A 3 "console\.log" components/salesloft/salesloft.app.mjs
Length of output: 9734
@GTFalcao Perfect! Now I can see the evidence clearly. The console.log(cadences) followed immediately by cadences?.map() shows you've been debugging this and confirmed that cadences is indeed an array that can be mapped over.
Looking at the other app integrations, I can see different patterns - some APIs (like Firmao) do require accessing .data property, while others work differently. The Salesloft API apparently returns the data arrays directly in the response body, which is why your current implementation works correctly.
Thank you for the clarification and sorry for the confusion! The current implementation is indeed correct for the Salesloft API structure.
✏️ Learnings added
Learnt from: GTFalcao
PR: PipedreamHQ/pipedream#16954
File: components/salesloft/salesloft.app.mjs:14-23
Timestamp: 2025-06-04T17:52:05.767Z
Learning: In the Salesloft API integration (components/salesloft/salesloft.app.mjs), the _makeRequest method returns response.data which directly contains arrays for list endpoints like listPeople, listCadences, listUsers, and listAccounts. The propDefinitions correctly call .map() directly on these responses without needing to destructure a nested data property.
Learnt from: GTFalcao
PR: PipedreamHQ/pipedream#16954
File: components/salesloft/salesloft.app.mjs:14-23
Timestamp: 2025-06-04T17:52:05.767Z
Learning: The Salesloft API list endpoints (listPeople, listCadences, listUsers, listAccounts) return arrays directly in the response body, not wrapped in a metadata object with a nested data property. The _makeRequest method correctly returns response.data which contains the arrays that can be mapped over directly in propDefinitions.
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
Closes #16696
Summary by CodeRabbit