The Crossbeam API negotiates authentication using OAuth 2.0. If you are looking to integrate the Crossbeam API with an existing application or service, follow the standards for that architecture or ecosystem for OAuth 2.0 authorization using these URLs:
\nAuthorization URL: https://auth.crossbeam.com/authorize?audience=https://api.getcrossbeam.com
Access Token URL: https://auth.crossbeam.com/oauth/token
Before you begin, you will need to create Application in Crossbeam; see the Custom section of https://app.crossbeam.com/integrations or see our help docs, found here.
If you want to get started quickly to kick the tires, see our section on Getting Started with Postman below.
\nOAuth scopes define the permissions your application will request from Crossbeam. For example, you might want to be able to access data about your partnerships, read report data, or be able to read and update threads.
\nOur documentation for each endpoint includes which scope(s) is required in order to use the endpoint. Here is some base information about choosing a scope value:
\nAt a minimum, openid
The scopes for the endpoints you'd like this token to have access to. For example, if you only want to access /v1/partners, the scope would be openid read:partnerships
For reference, here is a full list of scopes that our API accepts:
\nopenid
read:partnerships
read:reports
read:populations
write:activity-timeline
Access tokens are only valid for 24 hours. In order to stay authenticated, you may request a Refresh Token.
\nTo do so, add offline_access to your list of scopes when authenticating. For example, if you only want to access /v1/partners, the scope would be openid read:partnerships offline_access. Y
In order to exchange a refresh_token for a new access_token, below is a sample cURL. See the 1. Create an Application section below to understand how to obtain a client_id and client_secret.
curl --request POST \\\n --url 'https://auth.crossbeam.com/oauth/token' \\\n --header 'content-type: application/x-www-form-urlencoded' \\\n --data grant_type=refresh_token \\\n --data 'client_id=YOUR_CLIENT_ID' \\\n --data client_secret=YOUR_CLIENT_SECRET \\\n --data refresh_token=YOUR_REFRESH_TOKEN\n\nMost of our endpoints require 2 headers in order to be authorized. The first is the Authorization header containing the OAuth token. For example
Authorization: Bearer eyJhb....
The second header is used to tell our backend which organization you want to access data for. A Crossbeam user can belong to 1 or more organizations. You can obtain a list of organizations the user belongs to via the /v0.1/users/me endpoint. You can then extract the uuid field for the organization whose data you wish to access and provide this in the Xbeam-Organization header. For example:
Xbeam-Organization: 02fde942-c7cd-4f12-9d4e-07ee8a57c8c6
We have an example of how a 3rd party application might interact with the REST API to retrieve tokens. Please note that this source code is provided as-is and is not intended for production use.
\n\nFor quick access to see your data, you can use Postman with this collection. Note that you must use the desktop application, not the web application, which you can download here.
\nIf you'd prefer to watch this tutorial, a demo is available here. Otherwise continue reading.
\nLog in to Crossbeam and visit https://app.crossbeam.com/integrations, where you will see a section to create a custom integration. Click Create Integration:
Integration name: Choose whatever name you'd like to identify this app
\nIntegration description: Optionally write a description for your app
\nCallback URL: Set this to https://oauth.pstmn.io/v1/callback
Allowed Origins: Leave this value blank
\nClick Create and once the app has been created, click View. Copy the values for Client ID and Client Secret, you'll need these in the next section.
At the top of these docs, click Run in Postman:
![](\"https://s3.amazonaws.com/assets.getcrossbeam.com/postman/img/run-in-postman.png\")
\n\nThis will clone our Postman resources into your Postman app.
\nNext, select the Crossbeam environment as your active environment:
![](\"https://s3.amazonaws.com/assets.getcrossbeam.com/postman/img/select-environment.png\")
\n\nFinally, we'll edit the Crossbeam API collection to enter your Client ID and Secret which you got from the previous step. The Edit functionality can be found as shown:
![](\"https://s3.amazonaws.com/assets.getcrossbeam.com/postman/img/edit-collection.png\")
\n\nClick on the Variables tab, where you will see variables for client_id and client_secret. Set the Current Value for these variables to the values you copied from the previous section and then click Update.
Note: There are other variables in this section which we are not using right now, but will be useful later. In particular, the scope variable will control what resources your tokens have access to.
Rate limits are defined in our security policy and are subject to change with our own discretion.
\nA webhook is one way to subscribe to events and receive information in near real time. The Crossbeam Webhook sends signal information to the endpoint you provide. For more information on signals, see the Understanding Signals section in /v1/signals/\\\\\\\\*. Webhooks are an enterprise only feature.
For a detailed walk-through of the installation process through the Crossbeam UI, check out the documentation in the Crossbeam Help Center.
\nThe endpoint on the receiving end of a webhook is typically public. This means there are some extra steps to ensure the messages are actually coming from Crossbeam.
\nValidate the HMAC Signature. When setting up your webhook in the Crossbeam UI, Crossbeam will provide you with a secret key. Every request from Crossbeam will include the header X-Crossbeam-Signature-256. This is a base64 encoded string you can use to verify the contents of the message. Using your secret key, hash the contents of the body with the timestamp in X-Crossbeam-Timestamp appended and compare that value to the value in X-Crossbeam-Signature-256. See the example code for a more precise understanding.
Validate the X-Crossbeam-Timestamp header is \"recent\". In this case, the standard for \"recent\" is \"within the past 300 seconds\"
Use an endpoint that is random and difficult to guess
\nCrossbeam will retry the request several times for certain status codes (408, 429, 500, 502, 503, and 504). After that, a missed message can be retrieved via the rest API.
Please respond with a successful status code: likely either 200 or 201. There is no need to respond with anything in the body.
\nThis is a minimal Flask app that receives a request and verifies it in the way Crossbeam expects you to.
\nfrom flask import Flask, request, abort\nimport hmac\nimport hashlib\nimport time\nimport base64\napp = Flask(__name__)\n# Shared secret key (received in the Crossbeam UI)\nWEBHOOK_SECRET = b\"111122223333secret\"\n# Allowed timestamp drift (in seconds)\nMAX_TIMESTAMP_AGE = 300 # 5 minutes\ndef verify_signature_and_timestamp(request):\n \"\"\"Verify the request signature and timestamp header.\"\"\"\n received_signature = request.headers.get(\"X-Crossbeam-Signature-256\")\n received_timestamp = request.headers.get(\"X-Crossbeam-Timestamp\")\n if not received_signature or not received_timestamp:\n return False, \"Missing required headers\"\n try:\n received_timestamp = int(received_timestamp)\n except ValueError:\n return False, \"Invalid timestamp format\"\n now = int(time.time())\n if abs(now - received_timestamp) > MAX_TIMESTAMP_AGE:\n return False, \"Timestamp too old or too new\"\n # Build the signed payload string: \"body+timestamp\"\n signed_data = f\"{request.data.decode()}{received_timestamp}\".encode()\n computed_hmac = hmac.new(WEBHOOK_SECRET, signed_data, hashlib.sha256).digest()\n # Crossbeam's signature is base64 encoded\n computed_signature = base64.b64encode(computed_hmac).decode()\n if not hmac.compare_digest(received_signature, computed_signature):\n return False, \"Invalid signature\"\n return True, \"Valid\"\n@app.route(\"/webhook/61e68950-415c-4618-84a2-7bffdc6588ad\", methods=[\"POST\"])\ndef webhook():\n # Validate the request\n is_valid, message = verify_signature_and_timestamp(request)\n if not is_valid:\n print(message)\n abort(403)\n payload = request.get_json()\n # now you can trust the payload is from Crossbeam and process it!\n # for now, we just print it\n print(payload)\n return {}, 200\nif __name__ == \"__main__\":\n app.run(host=\"0.0.0.0\", port=5000, debug=True)\n\nThis route returns your user profile information as well as which organization(s) you belong to.
\nThis is the first endpoint you should inspect before others, as it will provide you the proper value to use in the XBeam-Organization header.
Subsequent calls to routes after this requires an XBeam-Organization header provided. The valid values to use here are the organization.uuid in each item in authorizations.
This route returns all of the users that belong to an organization. The authorized user must exist in the organization that this call is made for.
\n:id - This is the UUID for the organization that you are searching for users of.
This route returns your partners' information, including any tags that are set on the partner by the users of the organization.
\nread:partnershipsThis route returns your partner's information, as matched by the ID, including any tags that are set on the partner by the users of the organization
\nread:partnershipsThis route returns your partner's information, as matched by the ID, including any tags that are set on the partner by the users of the organization
\nread:partnershipsThis route returns all of your populations.
\nread:populationsThis route returns population with an ID matching the ID included in the path.
\nread:populationsThis route returns the populations that your partners have chosen to share with you.
\nread:partnershipsThis route returns the population that a partner has chosen to share with you that matches the ID passed in the path.
\nread:partnershipsThis route will return all the Reports you have created.
\nread:reportsThis route returns all of your account records from your own populations.
\nlimit : How many records to return. Default if not provided is 25. Maximum is 1000.cursor: As described in the pagination section, use this to get the next page of records.Pagination is controlled with the cursor query parameter. Within the pagination property, you find a map with the following:
next_href : this value contains the URL needed for the next page of results. It includes the cursor and any other query parameters the endpoint was called with.next_cursor: this value contains the cursor to use to get the next page of results. In most cases, you should rely on next_hrefhas_more: indicates if there are more records to page through. A value offalse is the only definitive way to know there are no more records.Inside of pagination is a next_href property. If this exists, that means there are more records to retrieve. Once it returns null, you have reached the end of the result set.
read:reportsThis route returns all of your account records from your own populations.
\nlimit : How many records to return. Default if not provided is 1000. Maximum is 1000.
cursor: As described in the pagination section, use this to get the next page of records.
Pagination is controlled with the cursor query parameter. Within the pagination property, you find a map with the following:
next_href : this value contains the URL needed for the next page of results. It includes the cursor and any other query parameters the endpoint was called with.
next_cursor: this value contains the cursor to use to get the next page of results. In most cases, you should rely on next_href
has_more: indicates if there are more records to page through. A value offalse is the only definitive way to know there are no more records.
Inside of pagination is a has_more property. If this is true, that means there are more records to retrieve. Once it returns false, you have reached the end of the result set for now, and should try again later until more results are returned.
read:reportsNumber of logs to fetch at once, max is 1000
\n","type":"text/plain"},"key":"limit","value":"500"},{"disabled":true,"description":{"content":"Cursor to pass if provided
\n","type":"text/plain"},"key":"cursor","value":"MTIzNDU="}],"variable":[]}},"response":[{"id":"3a9eb268-fff6-4a3d-92d3-e104e8954d9d","name":"/v1/audit-logs","originalRequest":{"method":"GET","header":[{"key":"Connection","value":"keep-alive"},{"key":"Accept","value":"application/json"},{"key":"Xbeam-Organization","value":""}],"url":{"raw":"https://api.crossbeam.com/v1/audit-logs?limit=500","protocol":"https","host":["api","crossbeam","com"],"path":["v1","audit-logs"],"query":[{"key":"limit","value":"500","description":"Number of logs to fetch at once, max is 1000"},{"key":"cursor","value":"MTIzNDU=","description":"Cursor to pass if provided","disabled":true}]}},"status":"OK","code":200,"_postman_previewlanguage":"json","header":[{"key":"Server","value":"nginx/1.19.3"},{"key":"Date","value":"Tue, 30 Mar 2021 14:38:58 GMT"},{"key":"Content-Type","value":"application/json; charset=utf-8"},{"key":"Content-Length","value":"1533"},{"key":"Connection","value":"keep-alive"},{"key":"Access-Control-Allow-Origin","value":"https://app.xbeam.dev1"},{"key":"Access-Control-Allow-Credentials","value":"true"}],"cookie":[],"responseTime":null,"body":"{\n \"data\": [\n {\n \"email\": \"bruce@wayne.com\",\n \"previous_state\": \"Robin was made your partner\",\n \"ip_address\": \"192.168.1.2\",\n \"type\": \"Sidekick Management\",\n \"users_impacted\": [\"robin@wayne.com\"],\n \"action\": \"Delete\",\n \"timestamp\": \"2024-04-30T22:50:11.919+00:00\",\n \"user\": \"Bruce Wayne\",\n \"metadata\": \"Robin is no longer your partner\",\n \"partners_impacted\": [\"Krypton\"]\n }\n ],\n \"pagination\": {\n \"next_cursor\": \"eyJ1dWlkIjoiMDM5Y2QxNWQtY2M5Ny00YmFkLWFjNTctZjFlMTVmMDdlZWM0IiwidGltZXN0YW1wIjoiMjAyNC0wNC0zMFQyMjo1MDoxMS45MTkrMDA6MDAifQ==\",\n \"has_more\": true,\n \"next_href\": \"https://api.crossbeam-dev.com/v1/audit-logs?limit=1&cursor=eyJ1dWlkIjoiMDM5Y2QxNWQtY2M5Ny00YmFkLWFjNTctZjFlMTVmMDdlZWM0IiwidGltZXN0YW1wIjoiMjAyNC0wNC0zMFQyMjo1MDoxMS45MTkrMDA6MDAifQ==\"\n }\n}"}],"_postman_id":"d90a27ae-0f87-4fb5-9d00-3935783c780a"},{"name":"/v1/records/accounts/search","id":"21ee830c-fbd8-4ef8-918d-0f7d02185dc7","protocolProfileBehavior":{"disableBodyPruning":true},"request":{"method":"GET","header":[{"key":"Connection","value":"keep-alive"},{"key":"Accept","value":"application/json"},{"key":"Xbeam-Organization","value":""}],"url":"https://api.crossbeam.com/v1/records/accounts/search?domain=crossbeam.com","description":"This route returns all of your account records from your own data sources, searching by the record's domain and company name.
\nread:reportsThis route accepts one of two query parameters:
\nterm: Fuzzy prefixed based matching: \"wayne\" matches both \"wayne.enterprises.com\" and \"Wayne Enterprises\"
record_id: Exact matching based on record_id
domain: Exact matching based on domain
opportunity_id: Exact matching for accounts associated with the given opportunity
contact_id: Exact matching for accounts associated with the given contact
This route returns all of your lead records from your own populations.
\nlimit : How many records to return. Default if not provided is 25. Maximum is 1000.cursor: As described in the pagination section, use this to get the next page of records.Pagination is controlled with the cursor query parameter. Within the pagination property, you find a map with the following:
next_href : this value contains the URL needed for the next page of results. It includes the cursor and any other query parameters the endpoint was called with.next_cursor: this value contains the cursor to use to get the next page of results. In most cases, you should rely on next_hrefhas_more: indicates if there are more records to page through. A value offalse is the only definitive way to know there are no more records.Inside of pagination is a next_href property. If this exists, that means there are more records to retrieve. Once it returns null, you have reached the end of the result set.
read:reportsThis route returns all of your lead records from your own data sources, searching by the record's email address.
\nread:reportsThis route accepts one of two query parameters:
\nterm: Fuzzy prefixed based matching: \"Alfred\" matches both \"alfred@wayne.enterprises.com\" and \"alfred@wayne.manor.com\"record_id: Exact matching based on record_idemail: Exact matching based on domainThe overlaps endpoints deliver the most valuable data in Crossbeam: the overlaps between you and your partners! This section serves as an introduction to the concept of overlaps, an explanantion of the fields returned by the endpoint and an explanation of how pagination and bookmarking works for these endpoints.
An overlap is a pair of records that match between your records and your partner's record. A match can occur in many ways, but the simplest to understand is when the website on a record in your system exactly matches the website on a record in your partner's system.
\nFor example, if you have an Account in your Salesforce with the following fields:
\nName: Wayne Inc.
Website wayne.enterprises
Account Id: 002K5000002fEhvIAE
And your partner has an Account in their Salesforce with these fields:
\nName: Wayne Enterprises
Website wayne.enterprises
Account Id: 0015Y00002agDTKQA2
These records will be an overlap in Crossbeam (assuming you have the requisite data synced and shared in Crossbeam).
\nThis overlap will be returned by the GET /v1/overlaps/accounts endpoint since your partner's record is an account.
A subset of the properties returned for that overlap are shown below:
\n{\n \"record_id\": \"002K5000002fEhvIAE\",\n \"record_name\": \"Wayne Inc.\",\n \"record_website\": \"wayne.enterprises\",\n \"crossbeam_record_id\": \"297d66ea-ca5c-9a98-93f0-a9205b7bbbee\",\n \"partner_record_id\": \"0015Y00002agDTKQA2\",\n \"partner_record_name\": \"Wayne Enterprises\",\n \"partner_record_website\": \"wayne.enterprises\",\n \"partner_record_company_type\": \"Customer\",\n \"partner_record_country\": \"USA\",\n \"partner_record_industry\": \"Retail\",\n \"partner_record_employees\": 1000,\n \"partner_crossbeam_record_id\": \"85253548-752b-5a76-f987-77f0d9ed85dd\"\n}\n\nNotice, all properties that relate to your partner's data are prefixed with partner_. If it doesn't have partner_, it is data from your side of the overlap.
There are two fields in the above JSON not yet mentioned: crossbeam_record_id and partner_crossbeam_record_id. These fields are the unique identifier Crossbeam generates for the record on each side of the overlap. Combining the two crosbeam_records_id's yields a unique identifier of the overlap across all organizations in Crossbeam. It is possible for two different overlaps to share a record_id, since that ID is coming from external systems, and from different organizations. It is possible for two different overlaps to share a crossbeam_record_id since it is possible for a record to overlap with more than one of your partners! Only with a combination of crossbeam_record_id and partner_crossbeam_record_id can you uniquely identify an overlap across Crossbeam customers!
Pagination is controlled with the cursor query parameter. Within the pagination property, you find a map with the following:
next_href : this value contains the URL needed for the next page of results. It includes the cursor and any other query parameters the endpoint was called with.
next_cursor: this value contains the cursor to use to get the next page of results. In most cases, you should rely on next_href
has_more: indicates if there are more records to page through. A value offalse is the only definitive way to know there are no more records.
To bookmark this endpoint, the next_cursor can be stored after a full sync. If you use it on a later run, the endpoint will return all overlaps that have changed since your last run. Note there are many things that can cause an overlap to change. Things like:
A value in the record changed
\nA data sharing rule changed
\nA record was deleted
\nA record was created
\nAll of these things are covered by the endpoint!
\nThe order the records are returned is not something you can rely on -- the cursor will return what has changed since your last full run of the records, but it won't be in the order they were updated.
\nWhile has_more is true, retrieve additional results using the URL inside next_href. Once has_more is false, you can save the next_href. The next time you call this endpoint, use that URL and you will only get records that are new, updated, or deleted!
is_deleted:Overlaps that have been deleted will be marked with an \"is_deleted\": true flag. These records may have been unshared, removed from a CRM, or moved populations. If you are syncing overlaps to another system, you will need to make sure the record still exists in the other system before deleting it.
limit : How many records to return. Default if not provided is 25. Maximum is 1000.
population-ids[]: Which of your own populations to include in the overlaps. Can be used multiple times for multiple populations e.g. ?population-ids[]=1&population-ids[]=42
partner-id: Limits the results to overlaps with a specific partner
cursor: As described in the pagination section, use this to get the next records.
If you have a stored cursor and want to change the query parameters for your next call, using that cursor will NOT accurately track changes! However, the endpoint will still return results.
\nYou need to restart with no cursor to start accurately tracking changes with your new query params.
\nread:reportsThis route returns all records of yours that overlap with a partner's accounts. Your side of the overlap is not necessarily an account. It also provides corresponding information about that partner, such as their organization information and their populations in which your record was matched.
\nEach call returns a top-level items array described in the example below. It also returns a top-level pagination object which gives you information about how to collect all the information via pagination.
This endpoint can be bookmarked using the cursor returned in pagination. See /v1/overlaps/* above for more information.
limit : How many records to return. Default if not provided is 25. Maximum is 1000.
population-ids[]: Which of your own populations to include in the overlaps. Can be used multiple times for multiple populations e.g. ?population-ids[]=1&population-ids[]=42
partner-id: Limits the results to overlaps with a specific partner
cursor: As described in the pagination section, use this to get the next records.
If you have a stored cursor and want to change the query parameters for your next call, using that cursor will NOT accurately track changes! However, the endpoint will still return results.
\nYou need to restart with no cursor to start accurately tracking changes with your new query params.
\nread:reportsThis route returns all records of yours that match the given search term and that overlap with a partner's account. It also provides corresponding information about that partner, such as their organization information and their populations in which your record was matched.
\nThis endpoint is not paged.
\nread:reportsterm : Fuzzy prefixed based matching: \"wayne\" matches both \"wayne enterprises\" and \"wayne manor\"
record_id: Exact matching based on record_id
domain: Exact matching based on domain
partner-population-ids[]: Which of your partner's populations to include in the overlaps. Can be used multiple times for multiple populations e.g. ?partner-population-ids[]=1&partner-population-ids[]=42
partner-id: Limits the results to overlaps with a specific partner
This route returns all records of yours that overlap with a partner's leads. Your side of the overlap is not necessarily a lead. It also provides corresponding information about that partner, such as their organization information and their populations in which your record was matched.
\nEach call returns a top-level items array described in the example below. It also returns a top-level pagination object which gives you information about how to collect all the information via pagination.
This endpoint can be bookmarked using the cursor returned in pagination. See /v1/overlaps/ above for more information.
limit : How many records to return. Default if not provided is 25. Maximum is 1000.
population-ids[]: Which of your own populations to include in the overlaps. Can be used multiple times for multiple populations e.g. ?population-ids[]=1&population-ids[]=42
partner-id: Limits the results to overlaps with a specific partner
cursor: As described in the pagination section, use this to get the next records.
If you have a stored cursor and want to change the query parameters for your next call, using that cursor will NOT accurately track changes! However, the endpoint will still return results.
\nYou need to restart with no cursor to start accurately tracking changes with your new query params.
\nread:reportsThis route returns all records of yours that match the given search term and that overlap with a partner's lead. It also provides corresponding information about that partner, such as their organization information and their populations in which your record was matched.
\nThis endpoint is not paged.
\nread:reportsterm : Fuzzy prefixed based matching: \"Alfred\" matches both \"alfred@wayne.enterprises.com\" and \"alfred@wayne.manor.com\"
record_id: Exact matching based on record_id
email: Exact matching based on email
partner-population-ids[]: Which of your partner's populations to include in the overlaps. Can be used multiple times for multiple populations e.g. ?partner-population-ids[]=1&partner-population-ids[]=42
partner-id: Limits the results to overlaps with a specific partner
A signal is a data point or behavioral indicator that suggests an opportunity, risk, or next step.
\nSignals help teams act on what's happening across the ecosystem.
\nThe signals we currently have are based directly off of changes in your partners' CRM data. Specifically, changes in opportunity data. When one of your partners opens or closes a deal, Crossbeam generates a signal.
\nThe signals visible to you through your partners' sharing settings are exposed in these signals endpoints.
\nYour partner needs to be syncing and sharing the following fields:
\nDeal open date
\nDeal close date
\nDeal is closed
\nDeal is won
\nThe signals endpoint returns shared data about the partner deal record the signal occurred on and relevant data about the signal itself.
\nevent_id - a unique identifier of the signal
event_type - what caused the signal to happen
triggered_at - the time the signal event occurred
record_name - the name of the record in your CRM the signal relates to
record_type - is your own record an account or lead (this is redundant on the endpoint, but is included to match the body sent by the webhook)
record_id - the ID of the record in your CRM the signal relates to
populations and partner_populations - a list of the Crossbeam populations this record was in at the time just after the signal occurred. For example, if your partner had an account in an \"Open Opportunities\" population and closed a deal on that account causing it to now fit the definition of \"Customers\" only, partner_populations would include \"Customers\" and not \"Open Opportunities\"
partner_name - the name of the partner involved in this signal
partner_id - the ID (uuid) of the partner involved in this signal
partner_data - a map with shared data on the partner's deal that caused this signal. Can include fields is_closed, is_won, open_date, close_date, stage, name
See the examples for realistic responses and to understand the response schema.
\nPagination is controlled with the cursor query parameter. Within the pagination property, you find a map with the following:
next_href : this value contains the URL needed for the next page of results. It includes the cursor and any other query parameters the endpoint was called with.
next_cursor: this value contains the cursor to use to get the next page of results. In most cases, you should rely on next_href
has_more: indicates if there are more records to page through. A value of false is the only definitive way to know there are no more records.
To bookmark this endpoint, the next_cursor can be stored after a full sync.
This bookmark simply tracks signals that have been created since the last sync: it returns all new signals. If \"partner deal name\" has changed since the last call, that signal will NOT be returned in a subsequent call with the bookmark.
\nread:reportsThis route returns all signals the where your side of the overlap is an account.
\nEach call returns a top-level items array described in the example below. It also returns a top-level pagination object which gives you information about how to collect all the information via pagination.
This endpoint can be bookmarked using the cursor returned in pagination. See /v1/signals/* above for more information.
limit : how many records to return. The fefault if not provided is 25. The maximum is 1000.
record_id: only include signals on this specific record. Can be used multiple times for multiple records e.g. ?record_id=\"abc123\"&record_id=\"def456\"
population_id: only include signals on records which are a part of the provided population. Note that in the populations field in the response we show all populations that record is included in, regardless of this filter. Can be used multiple times for multiple populations e.g. ?population_id=1&population_id=42
partner_id: limits the results to signals involving a specific partner. Can be used multiple times for multiple partners e.g. ?partner_id=10&partner_id=100
partner_population_id: only include signals involving a specific partner population. Note that in the partner_populations field in the response we show all partner populations that record is included in, regardless of this filter. Can be used multiple times for multiple populations e.g. ?partner_population_id=11&population_id=43
triggered_at[gt|gte|lt|lte|eq]: uses left-hand side style operators to get filter signals based on the provided triggered_at. The parameter should be a datetime: \"2025-10-15T14:59:06.347Z\". Example:
triggered_at[lt]=\"2025-10-15T00:00:00.000Z\" retrieves signals triggered before October 15 of 2025 in UTC.
cursor: As described in the pagination section, use this to get the next records
read:reportsThis route returns all signals the where your side of the overlap is an lead.
\nEach call returns a top-level items array described in the example below. It also returns a top-level pagination object which gives you information about how to collect all the information via pagination.
This endpoint can be bookmarked using the cursor returned in pagination. See /v1/signals/\\* above for more information.
limit : how many records to return. The fefault if not provided is 25. The maximum is 1000.
record_id: only include signals on this specific record. Can be used multiple times for multiple records e.g. ?record_id=\"abc123\"&record_id=\"def456\"
population_id: only include signals on records which are a part of the provided population. Note that in the populations field in the response we show all populations that record is included in, regardless of this filter. Can be used multiple times for multiple populations e.g. ?population_id=1&population_id=42
partner_id: limits the results to signals involving a specific partner. Can be used multiple times for multiple partners e.g. ?partner_id=10&partner_id=100
partner_population_id: only include signals involving a specific partner population. Note that in the partner_populations field in the response we show all partner populations that record is included in, regardless of this filter. Can be used multiple times for multiple populations e.g. ?partner_population_id=11&population_id=43
triggered_at[gt|gte|lt|lte|eq]: uses left-hand side style operators to get filter signals based on the provided triggered_at. The parameter should be a datetime: \"2025-10-15T14:59:06.347Z\". Example:
triggered_at[lt]=\"2025-10-15T00:00:00.000Z\" retrieves signals triggered before October 15 of 2025 in UTC.
cursor: As described in the pagination section, use this to get the next records
read:reportsReturns own-direction deal signals as per-overlap rows: one signal per partner overlap on your open/closed-won deals. Each row carries a unique signal_id and a shared event_id (group by event_id to reconstruct the aggregated shape). Bookmarked/paginated with a cursor. Requires the read:reports scope.
\nlimit : how many records to return. The default if not provided is 25. The maximum is 1000.
record_id: only include signals on this specific record. Can be used multiple times for multiple records e.g. ?record_id=\"abc123\"&record_id=\"def456\"
population_id: only include signals on records which are part of the provided population. Note that the populations field in the response shows all populations that record is included in, regardless of this filter. Can be used multiple times e.g. ?population_id=1&population_id=42
partner_id: limits the results to signals involving a specific partner. Can be used multiple times e.g. ?partner_id=10&partner_id=100
partner_population_id: only include signals involving a specific partner population. Can be used multiple times e.g. ?partner_population_id=11&partner_population_id=43
event_type: only include signals of this type. Valid values: own_deal_opened, own_deal_closed_won. Can be used multiple times e.g. ?event_type=own_deal_opened&event_type=own_deal_closed_won
triggered_at[gt|gte|lt|lte|eq]: uses left-hand side style operators to filter signals based on the provided triggered_at. The parameter should be a datetime: \"2025-10-15T14:59:06.347Z\". Example: triggered_at[lt]=\"2025-10-15T00:00:00.000Z\" retrieves signals triggered before October 15 of 2025 in UTC.
cursor: As described in the pagination section, use this to get the next records.
read:reports