# RudderTyper v2 Sends Tracking Plan Property Names


{{< announcement >}}
[RudderTyper v2]({{< ref "dev-tools/rudder-cli/ruddertyper-v2.md" >}}) is in **Public Beta** as part of RudderStack's Early Access Program, where we work with early users and customers to test new features and get feedback before making them generally available.
{{< /announcement >}}

[Rudder CLI]({{< ref "dev-tools/rudder-cli/" >}}) v0.24.0 fixes the RudderTyper v2 TypeScript generator so that event property keys sent to RudderStack match the property names in your [Tracking Plan]({{< ref "data-governance/tracking-plans/" >}}).

Previously, the TypeScript generator camelCased property names for the generated interfaces, and those camelCased keys were also what your application sent. A plan defining `product_id` produced events carrying `productId`. Kotlin and Swift were never affected.

## What changed

Generated TypeScript interfaces still use camelCase field names, so **your existing code keeps compiling and needs no changes**. What changed is the payload: RudderTyper now maps the keys back to your Tracking Plan's names just before handing the event to the SDK.

```typescript
// Your code, unchanged
typer.trackOrderCompleted({ productId: "sku-1024" });
```

```json
// What RudderStack now receives
{ "event": "Order Completed", "properties": { "product_id": "sku-1024" } }
```

This applies to `track`, `page`, `identify`, and `group`, and holds at every level of the payload, including nested objects, arrays of objects, and properties typed as a custom type with variants.

## Who is affected

Only TypeScript projects using RudderTyper v2 whose Tracking Plans define property names that aren't already camelCase, such as `snake_case` or `kebab-case`.

If your plan's property names are already camelCase, nothing changes for you.

## Before you upgrade

{{< warning >}}
This changes the property names in the events your application sends. Review the downstream effects before rolling out.
{{< /warning >}}

- **Warehouse columns**: events start landing in columns named after your Tracking Plan properties. Expect new columns alongside the existing camelCased ones, and plan for how you want to reconcile historical data.
- **Downstream destinations**: any destination mapping, transformation, or dashboard that referenced the camelCased property names needs updating to the Tracking Plan names.
- **Identity stitching**: if any of the affected properties feed [Profiles]({{< ref "profiles/" >}}) identity stitching, confirm the stitching keys still resolve after the change.
- **Remove any key-renaming workaround**: if you worked around this by intercepting `track` and renaming keys before sending, remove it in the same change as the upgrade. RudderTyper now does that mapping itself, so leaving the workaround in place renames the keys twice and puts camelCase back on the wire.

Your events also stop violating your Tracking Plan, which may change the volume of violations reported for the affected sources.

## Get started

Upgrade [Rudder CLI]({{< ref "dev-tools/rudder-cli/installation.md" >}}) to v0.24.0 or later and regenerate your bindings:

```bash
rudder-cli typer generate --tracking-plan-id <your-plan-id> --platform typescript
```

| Guide | Description |
| :---- | :---- |
| [RudderTyper v2]({{< ref "dev-tools/rudder-cli/ruddertyper-v2.md" >}}) | Overview of RudderTyper v2, its features, and limitations |
| [RudderTyper v2 Command Reference]({{< ref "dev-tools/rudder-cli/ruddertyper-v2-command-reference.md" >}}) | Naming conventions, platform options, and command parameters |
| [RudderTyper v2 Walkthrough Guide]({{< ref "dev-tools/rudder-cli/ruddertyper-v2-walkthrough.md" >}}) | Step-by-step tutorial to generate and use type-safe bindings |

<br />