You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: src/partners/sources.md
+68-1Lines changed: 68 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -22,7 +22,74 @@ Before you begin, you need access to the Developer Portal. To access the Develop
22
22
23
23
4. Select the **Catalog info** tab and add relevant metadata and catalog information for your source.
24
24
25
-
The code for your source should follow the format of Segment's [HTTP API](/docs/connections/sources/catalog/libraries/server/http-api/).
25
+
## Understanding the integration
26
+
27
+
To complete the source set up flow, the customer will need to input the Segment write key for this source in your integrations settings UI. This will enable your tool to route customer data back to Segment correctly.
28
+
29
+
To send events to Segment you should post events directly to the [Segment HTTP API](/docs/connections/sources/catalog/libraries/server/http-api/#track). You may use any server-side Segment [library](/docs/connections/sources/catalog/) to do so.
30
+
31
+
## The Segment Spec
32
+
33
+
Building your source will require defining the event data that you send to Segment. Segment's spec is a critical component of preserving semantics between sources and destinations.
34
+
35
+
If you break the spec, you are breaking the promise of Segment, which is grounds for removal from the catalog. To learn about the semantics of the five supported API calls, and the semantic event names and properties Segment recognizes, read the [Segment Spec](/docs/connections/spec).
36
+
37
+
Within the Spec, there are a few requirements for partner Streams worth pointing out.
38
+
39
+
### `userId`
40
+
41
+
Each call sent to Segment must contain a `userId`. The `userId` is what allows Segment to identify each unique user. This value should be stored by your tool when you receive an event from Segment.
42
+
43
+
For example, you might receive an `identify` call with a `userId` and `traits` about that user. If that user is sent an email and opens that email, you would want to send an `Email Opened` event back to Segment with that same `userId` . The `userId` should be part of the call body as a top-level object.
44
+
45
+
> info ""
46
+
> For Customers, it's critical that the `userId` be consistent across all data flowing through Segment — this has significant implications for Segment billing (based on unique Monthly Tracked Users) and usefulness of data in integrations/warehouses. Passing back the `userId` value sent from Segment into your tool should be the default behavior of your track calls. If you're not a destination, make sure that you're using the customer's internal database ID, not your tool's ID.
47
+
48
+
If you have your own unique identifier you use in your tool, Segment recommends passing that along as a context property in the event for QA purposes. For example:
Each call should contain a `context.integration` object in the call body that identifies your tool (for example where the call is coming from). Use the slugified name for your tool, and `1.0.0` as the initial version — if you're unsure of your integration slug, contact Segment support. Once Streams are supported in the Developer Center, this will be rendered for you and will be validated as part of the QA process.
64
+
65
+
This should be part of the `context` top-level object and will look like:
66
+
67
+
```json
68
+
"context": {
69
+
"integration": {
70
+
"name": "your-tool",
71
+
"version": "1.0.0"
72
+
}
73
+
}
74
+
```
75
+
76
+
### `writeKey`
77
+
78
+
Each call must contain a `writeKey`. Segment provides this `writeKey` to customers in the settings panel for each of their sources. As mentioned in the set up flow description above, customers will need to save their Segment write key in your UI in order authenticate calls being made by your tool.
79
+
80
+
The write key is required in the header of every call to identify the customer whose data Segment receives. See the [authentication section](/docs/connections/sources/catalog/libraries/server/http-api/#authentication) of the HTTP API docs for more detail. If you do not include a customer write key in the call header, Segment will reject track calls from your tool.
81
+
82
+
**Rate limits and batching**
83
+
There is no hard rate limit at which point Segment will drop your data. However, to avoid processing delays, Segment asks partners to send requests at a maximum rate of 50 requests per second.
84
+
85
+
If you want to batch requests to the HTTP endpoint, refer to the batching documentation [here](/docs/connections/sources/catalog/libraries/server/http-api/#import). The suggested maximum rate includes any batch requests.
86
+
87
+
## Regional Segment
88
+
89
+
Segment offers customers the option to lead on data residency by providing [regional infrastructure](/docs/guides/regional-segment) in both the Europe and the United States. In order for your source to be available in an EU workspace, you will need to provide the ability for the Segment user to post their data to the EU ingestion endpoint:
0 commit comments