# 👉 Custom Authorization Header Support in Android & iOS SDKs

**URL:** <https://community.transifex.com/t/custom-authorization-header-support-in-android-ios-sdks/5088>\
**Category:** What's new?\
**Tags:** transifex-native\
**Created:** [December 18, 2025, 2:31pm UTC](https://community.transifex.com/t/custom-authorization-header-support-in-android-ios-sdks/5088 "2025-12-18T14:31:53Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![maria](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.transifex.com/maria/32/1132_2.png) [@maria](https://community.transifex.com/u/maria)\
**Post date:** [December 18, 2025, 2:31pm UTC](https://community.transifex.com/t/custom-authorization-header-support-in-android-ios-sdks/5088/1 "2025-12-18T14:31:53Z")

</div>

We’re excited to introduce a new improvement to the Transifex Mobile SDKs for **Android and iOS** , making SDK initialization more flexible and giving developers full control over authentication headers.

### 💡 What’s New

Both Android and iOS SDKs now support:

- **A builder-style initialization API**

- **Overriding the default `Authorization` HTTP header** with a custom header key

- **Ensuring the `Authorization` header is completely omitted** when a custom header is configured

This makes it easier to integrate the SDK in environments where the standard `Authorization` header cannot be used.

* * *

### 📱 Android SDK

On Android, a new **`TxNative.Initializer`** class has been introduced.

Key updates:

- SDK initialization is now performed using a **fluent builder pattern**

- Optional configuration (including a custom authorization header key) can be set before calling `init()`

- The previous `TxNative.init()` method is still available, but **deprecated**

When a custom authorization header key is specified:

- The authentication token is sent **only** via the custom header

- The default `Authorization` header is **not included** in requests

* * *

### 🍏 iOS SDK

On iOS, the SDK introduces a new **`TXNativeBuilder`** for initialization.

Key updates:

- SDK initialization now follows a **builder pattern**

- Existing initialization methods are **deprecated** in favor of the builder

- The builder allows **overriding the authorization HTTP header key**

As with Android:

- When a custom header is configured, the SDK **does not send** the `Authorization` header

- Only the custom header is used for authentication

* * *

### ✅ Why This Matters

These changes allow teams to:

- Comply with strict security or networking policies

- Avoid issues with infrastructure that restricts the `Authorization` header

- Adopt a cleaner, more extensible SDK initialization flow

This enhancement provides greater flexibility while maintaining backward compatibility. Let us know what you think of this improvement in the comments below!