Vale edits of partner streams doc (#2607)

markzegarelli · web-flow · commit 407b1115caa1 · 2022-03-17T09:20:31.000-07:00
diff --git a/src/partners/streams.md b/src/partners/streams.md
@@ -1,11 +1,11 @@
 ---
-title: Building a Stream
+title: Build a Stream
 ---
 
 > info ""
-> The Developer Center currently only supports the [Subscription](/docs/partners/subscriptions) component in _Developer Preview_. Include [your information here](https://airtable.com/shrj3BkHMhdeaPYWt) and we'll contact you once _Streams_ are made available!
+> The Developer Center currently only supports the [Subscription](/docs/partners/subscriptions) component in _Developer Preview_. Include [your information here](https://airtable.com/shrj3BkHMhdeaPYWt) and Segment will contact you once _Streams_ are made available!
 
-Streams enable you to send data to our mutual customers from your web services in realtime.
+Streams enable you to send data to mutual customers from your web services in realtime.
 
 # Building a Stream
 
@@ -19,33 +19,36 @@ Customers can find their write key in the source settings and regenerate it as n
 
 ![](images/s_8E933880F61B29168308B8A8203AE878319289A26E8E2054D0824C7A53E43DD4_1479162638952_file.png)
 
-*Important*: We are working on an OAuth solution to reduce friction for customers. Partner Streams submitted through the developer center *will* be required to support this OAuth as it comes available.
+> warning ""
+> Segment working on an OAuth solution to reduce friction for customers. Partner Streams submitted through the developer center *will* be required to support this OAuth as it comes available.
 
 ## The Segment Spec
 
-To learn about the semantics of the five supported API calls, and the semantic event names and properties we recognize, read the Segment [Spec](https://segment.com/docs/connections/spec).
+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).
 
 The spec is a critical component of preserving semantics between sources and destinations. If you break the spec, you are breaking the promise of Segment, which is grounds for removal from the catalog.
 
-*Important*: If there are any events you send that match existing events from our spec that you are not adhering to (eg. sending "Purchase" instead of "Order Completed" or "install" instead of "Application Installed"), we will reject your application.
+> info "" 
+> If any events you send to Segment match, but do not adhere to, existing events from the Segment Spec (for example, sending "Purchase" instead of "Order Completed" or "install" instead of "Application Installed"), Segment will reject your application.
 
-If there is something unique about your tool that requires specific data points that are not included in the spec, [get in touch](https://segment.com/help/contact/). We love partner suggestions for augmentations to the spec!
+If there is something unique about your tool that requires specific data points that are not included in the spec, [get in touch](https://segment.com/help/contact/){:target="_blank"}.
 
 ## Sending data
 
-To send events to Segment you should post events directly to the [Segment HTTP API](https://segment.com/docs/connections/sources/catalog/libraries/server/http-api/#track). You may use a Segment [library](https://segment.com/docs/connections/sources/catalog/) to do so. The HTTP API has a couple of basic requirements.
+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 a Segment [library](/docs/connections/sources/catalog/) to do so. The HTTP API has a couple of basic requirements.
 
 Beyond the Spec, there are a few additional requirements for partner Streams.
 
 ### `userId`
 
-Each call sent to Segment must contain a  `userId`. The `userId` is what allows us to identify each unique user. This value should be stored by your tool when you receive an event from Segment.
+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.
 
 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.
 
-> **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.**
+> info ""
+>  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.
 
-If you have your own unique identifier you use in your tool, we recommend passing that along as a context property in the event for QA purposes. For example:
+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:
 
 ```json
     "type": "track",
@@ -60,7 +63,7 @@ If you have your own unique identifier you use in your tool, we recommend passin
 
 ### `integration`
 
-Each call should contain a `context.integration` object in the call body that identifies your tool (i.e., 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 us. Once Streams are supported in the Developer Center, this will be rendered for you and will be validated as part of the QA process.
+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.
 
 This should be part of the `context` top-level object and will look like:
 
@@ -77,22 +80,23 @@ This should be part of the `context` top-level object and will look like:
 
 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.
 
-The write key is required in the header of every call to identify the customer whose data we're receiving. See the [authentication section](https://segment.com/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, we will reject track calls from your tool.
+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.
 
 **Rate limits and batching**
-There is no hard rate limit at which point Segment will drop your data. However, to avoid processing delays, we ask partners to send requests at a maximum rate of 50 requests per second.
+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.
 
-If you want to batch requests to the HTTP endpoint, refer to the batching documentation [here](https://segment.com/docs/connections/sources/catalog/libraries/server/http-api/#import). The suggested maximum rate includes any batch requests.
+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.
 
 ## Regional Segment
 Segment offers customers the option to lead on data residency by providing regional infrastructure in both the Europe and the United States.
-We recommend you enable the user to the Segment [endpoint](https://segment.com/docs/guides/regional-segment/#server-side-and-project-sources) to send data to for the given writeKey.
+
+Segment recommends you enable the user to the Segment [endpoint](/docs/guides/regional-segment/#server-side-and-project-sources) to send data to for the given writeKey.
 
 # Process
 
 ## Plan
 
-If you have not already, contact review your timeline and resourcing plan. Include which events your source will be sending to Segment to ensure they are properly specified. We are onboarding new sources as quickly as we can, but you should only commence building once you receive approval from Segment.
+If you have not already, contact review your timeline and resourcing plan. Include which events your source will be sending to Segment to ensure they are properly specified. Segment onboards new sources as quickly as possible, but you should only commence building once you receive approval from Segment.
 
 ## Build
 
@@ -101,7 +105,7 @@ All three of these steps should be completed before you begin testing:
 
 - Following the guidelines above, format your outbound webhook to Segment's HTTP API.
 - Add a field in your settings UI where customers can input their Segment write key.
-- Write docs for your source — you'll need to have separate docs for your source ([example](https://segment.com/docs/connections/sources/catalog/cloud-apps/drip/)) and integration.
+- Write docs for your source — you'll need to have separate docs for your source ([example](/docs/connections/sources/catalog/cloud-apps/drip/)) and integration.
 
 ## Testing
 
